mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-21 23:22: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.
|
||||
|
||||
(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).
|
||||
|
||||
## Nesting of one-pass signatures
|
||||
#### 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.
|
||||
|
||||
|
@ -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`
|
||||
|
||||
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