mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-15 20:52:05 +01:00
Move "nesting" section up into the OPS section
This commit is contained in:
parent
2444e6cc93
commit
7b4031dc0a
1 changed files with 30 additions and 30 deletions
|
@ -85,36 +85,7 @@ Strictly speaking, knowing just the hash algorithm would be sufficient to begin
|
||||||
|
|
||||||
Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature<OpenPGP Signature Packet>` successfully.
|
Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature<OpenPGP Signature Packet>` successfully.
|
||||||
|
|
||||||
(prefixed-signature)=
|
#### Nesting of one-pass signatures
|
||||||
### Prefixed signed message
|
|
||||||
|
|
||||||
A {term}`prefixed signed message` consists of {term}`signature packet(s)<signature packet>` followed by the message. For the verifier, processing one-pass signed and prefixed signed messages are equally convenient. However, on the signer's side, it takes more resources to generate a {term}`prefixed signed message`.
|
|
||||||
|
|
||||||
#### Structure
|
|
||||||
|
|
||||||
In this format, the signature packets are stored ahead of the message itself:
|
|
||||||
|
|
||||||
1. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These one or more packets contain the {term}`cryptographic signature` corresponding to the original data.
|
|
||||||
|
|
||||||
2. [**{term}`OpenPGP message`**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion.
|
|
||||||
|
|
||||||
```{figure} ../plain_svg/prefixed-signed-message.svg
|
|
||||||
:name: fig-prefixed-signed-message
|
|
||||||
:alt: Depicts the structure of a prefixed signed message. As an example, two signature packets lead a literal data packet. Arrows show, how the signatures hash algorithm field is inspected to start the hashing procedure.
|
|
||||||
|
|
||||||
Structure of a prefixed signed message.
|
|
||||||
```
|
|
||||||
|
|
||||||
Compared to a {term}`one-pass signed message`, there are no {term}`one-pass signature packets<One-pass Signature Packet>` in this format, and the (otherwise equivalent) {term}`signature packet(s)<signature packet>` are stored ahead of the signed data.
|
|
||||||
|
|
||||||
For verification, this is equally convenient as the one-pass signed message form.
|
|
||||||
|
|
||||||
However, when a signer creates a {term}`prefixed signed message`, the signed data must be processed twice:
|
|
||||||
|
|
||||||
- once reading it to calculate the cryptographic signature, and
|
|
||||||
- once more to store the data in the generated OpenPGP message, after the signature packet(s).
|
|
||||||
|
|
||||||
## Nesting of one-pass signatures
|
|
||||||
|
|
||||||
Signing a message using the one-pass mechanism involves prepending a *one-pass signature* (OPS) packet to the message and appending the corresponding signature, sandwiching the signed content.
|
Signing a message using the one-pass mechanism involves prepending a *one-pass signature* (OPS) packet to the message and appending the corresponding signature, sandwiching the signed content.
|
||||||
|
|
||||||
|
@ -159,3 +130,32 @@ Now, a message, where the signer attests an already signed message has the follo
|
||||||
`OPS₁ OPS₁ LIT("Hello World") SIG SIG`
|
`OPS₁ OPS₁ LIT("Hello World") SIG SIG`
|
||||||
|
|
||||||
While the inner signature is calculated over the usual plaintext `Hello World`, the outer signature is instead calculated over `OPS₁ Hello World SIG`.
|
While the inner signature is calculated over the usual plaintext `Hello World`, the outer signature is instead calculated over `OPS₁ Hello World SIG`.
|
||||||
|
|
||||||
|
(prefixed-signature)=
|
||||||
|
### Prefixed signed message
|
||||||
|
|
||||||
|
A {term}`prefixed signed message` consists of {term}`signature packet(s)<signature packet>` followed by the message. For the verifier, processing one-pass signed and prefixed signed messages are equally convenient. However, on the signer's side, it takes more resources to generate a {term}`prefixed signed message`.
|
||||||
|
|
||||||
|
#### Structure
|
||||||
|
|
||||||
|
In this format, the signature packets are stored ahead of the message itself:
|
||||||
|
|
||||||
|
1. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These one or more packets contain the {term}`cryptographic signature` corresponding to the original data.
|
||||||
|
|
||||||
|
2. [**{term}`OpenPGP message`**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion.
|
||||||
|
|
||||||
|
```{figure} ../plain_svg/prefixed-signed-message.svg
|
||||||
|
:name: fig-prefixed-signed-message
|
||||||
|
:alt: Depicts the structure of a prefixed signed message. As an example, two signature packets lead a literal data packet. Arrows show, how the signatures hash algorithm field is inspected to start the hashing procedure.
|
||||||
|
|
||||||
|
Structure of a prefixed signed message.
|
||||||
|
```
|
||||||
|
|
||||||
|
Compared to a {term}`one-pass signed message`, there are no {term}`one-pass signature packets<One-pass Signature Packet>` in this format, and the (otherwise equivalent) {term}`signature packet(s)<signature packet>` are stored ahead of the signed data.
|
||||||
|
|
||||||
|
For verification, this is equally convenient as the one-pass signed message form.
|
||||||
|
|
||||||
|
However, when a signer creates a {term}`prefixed signed message`, the signed data must be processed twice:
|
||||||
|
|
||||||
|
- once reading it to calculate the cryptographic signature, and
|
||||||
|
- once more to store the data in the generated OpenPGP message, after the signature packet(s).
|
||||||
|
|
Loading…
Reference in a new issue