From 2444e6cc931247b56a3f666447ab88be80a25f75 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 23 Dec 2023 04:01:07 +0100 Subject: [PATCH 1/2] Adjust styling of "one-pass" in the nesting section --- book/source/adv/signing_data.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/book/source/adv/signing_data.md b/book/source/adv/signing_data.md index d89250e..2f65f87 100644 --- a/book/source/adv/signing_data.md +++ b/book/source/adv/signing_data.md @@ -116,16 +116,16 @@ However, when a signer creates a {term}`prefixed signed message`, the signed dat ## 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. An OpenPGP message can contain multiple signatures added that way. ```{note} -One-Pass-Signatures are nested, meaning the outermost One-Pass-Signature packet corresponds to the outermost signature packet. +One-pass signatures are nested, meaning the outermost one-pass signature packet corresponds to the outermost signature packet. ``` When a message is signed, the signature is always calculated over the contents of the literal data packet, not the literal data packet itself. -This means that if a message, which is compressed using a compressed data packet is wrapped using a one-pass-signature, the signature is still being calculated over the plaintext inside the literal data packet. +This means that if a message, which is compressed using a compressed data packet is wrapped using a one-pass signature, the signature is still being calculated over the plaintext inside the literal data packet. There is one exception, though. ```{note} @@ -137,20 +137,20 @@ If this flag is set to `0`, it indicates that further OPSs will follow this pack [^nested-flag]: See [description of the nested flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.4-3.8.1). -This mechanism enables attested signatures, where the signer signs an already one-pass-signed message including the already contained signature. +This mechanism enables attested signatures, where the signer signs an already one-pass signed message including the already contained signature. As a practical example, consider the following notation: * `LIT("Hello World")` represents a literal data packet with the content `Hello World`. * `COMP(XYZ)` represents a compressed data packet over some other packet `XYZ`. -* `OPS₁` represents a one-pass-signature packet with the nested flag set to `1`. Analogous, `OPS₀` has the nested flag set to `0`. +* `OPS₁` represents a one-pass signature packet with the nested flag set to `1`. Analogous, `OPS₀` has the nested flag set to `0`. * `SIG` represents a signature packet. -A normal, one-pass-signed message looks like this: +A normal, one-pass signed message looks like this: `OPS₁ LIT("Hello World") SIG` Here, the signature is calculated over the plaintext `Hello World`, as is it in a message that has the following form: `OPS₁ COMP(LIT("Hello World")) SIG`. -A message, where multiple one-pass-signatures are calculated over the same plaintext looks the following: +A message, where multiple one-pass signatures are calculated over the same plaintext looks the following: `OPS₀ OPS₀ OPS₁ LIT("Hello World") SIG SIG SIG` All three signatures are calculated over the same plaintext `Hello World`. From 7b4031dc0a5b6d12038f710c2e7fda215b959023 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 23 Dec 2023 19:09:17 +0100 Subject: [PATCH 2/2] Move "nesting" section up into the OPS section --- book/source/adv/signing_data.md | 60 ++++++++++++++++----------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/book/source/adv/signing_data.md b/book/source/adv/signing_data.md index 2f65f87..b8e9ad6 100644 --- a/book/source/adv/signing_data.md +++ b/book/source/adv/signing_data.md @@ -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`, 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` successfully. -(prefixed-signature)= -### Prefixed signed message - -A {term}`prefixed signed message` consists of {term}`signature packet(s)` 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`**: 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` in this format, and the (otherwise equivalent) {term}`signature packet(s)` 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)` 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`**: 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` in this format, and the (otherwise equivalent) {term}`signature packet(s)` 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).