vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-25 17:12:06 +01:00
Code Issues Projects Releases Packages Wiki Activity

Normalize dash styling

Browse source 
(Mirroring styling in c-r)
This commit is contained in:
Heiko Schaefer 2023-12-20 11:58:20 +01:00
parent edc2c8322d
commit 0ba4461f3b
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
book/source/signing_data.md
View file

@ -54,7 +54,7 @@ This method is commonly used for signing or encrypting emails. Most email softwa
OpenPGP defines two variant forms of inline-signed messages: OpenPGP defines two variant forms of inline-signed messages:
1. **{term}`One-pass signed messages<One-pass signed Message>`** This is the commonly used format for inline-signed messages. A signer can produce and a verifier verify this format in one pass. 1. **{term}`One-pass signed messages<One-pass signed Message>`** This is the commonly used format for inline-signed messages. A signer can produce and a verifier can verify this format in one pass.
2. **{term}`Prefixed signed messages<Prefixed signed Message>`** This format predates[^inline-signature-formats] {term}`one-pass signed messages<One-pass signed Message>` and is conceptually slightly simpler. However, it has no strong benefits and is now rarely used. 2. **{term}`Prefixed signed messages<Prefixed signed Message>`** This format predates[^inline-signature-formats] {term}`one-pass signed messages<One-pass signed Message>` and is conceptually slightly simpler. However, it has no strong benefits and is now rarely used.
[^inline-signature-formats]: One-pass signing was first specified in RFC 2440. The format was not supported in PGP 2.6.x. [^inline-signature-formats]: One-pass signing was first specified in RFC 2440. The format was not supported in PGP 2.6.x.
@ -76,7 +76,7 @@ A {term}`one-pass signed<One-pass signed Message>` {term}`OpenPGP message` consi
```{figure} plain_svg/ops-signed-message.svg ```{figure} plain_svg/ops-signed-message.svg
:name: fig-ops-signed-message :name: fig-ops-signed-message
:alt: Depicts the structure of a one-pass-signed message. Two one-pass-signatures lead the literal data packet, followed by two signature packets. Arrows show, how the hash-algorithm field of the one-pass-signatures is inspected in order to initiate the hashing procedure. :alt: Depicts the structure of a one-pass signed message. Two one-pass signatures lead the literal data packet, followed by two signature packets. Arrows show, how the hash-algorithm field of the one-pass signatures is inspected in order to initiate the hashing procedure.
The structure of a one-pass signed message. The structure of a one-pass signed message.
``` ```
@ -88,7 +88,7 @@ Instead, it's a type of auxiliary packet that can be used in conjunction with {t
The position of the signature packet within the OpenPGP message is important for efficient data processing. The plaintext data might be large in size, and memory might be constrained. The position of the signature packet within the OpenPGP message is important for efficient data processing. The plaintext data might be large in size, and memory might be constrained.
The producer of a signed OpenPGP message wants to streamline the signature calculation process in such a way that allows to emit the data to be signed while calculating the signature. The signature itself is therefore appended to the data. The producer of a signed OpenPGP message wants to streamline the signature calculation process in such a way that allows to emit the data to be signed while calculating the signature. The signature itself is therefore appended to the data.
The verifier on the other hand needs to know the hash algorithm used to calculate the signature before starting the verification process. As a consequence, either the producer would need to pass the plaintext data twice, once to calculate the signature and a second time to emit the signed data (the result is a prefixed-signed message), or the verifier needs to process (and cache) the whole OpenPGP message to reach the signature packets at the end in order to determine the hash algorithm, to then re-process the whole message, verifying the signature. The verifier on the other hand needs to know the hash algorithm used to calculate the signature before starting the verification process. As a consequence, either the producer would need to pass the plaintext data twice, once to calculate the signature and a second time to emit the signed data (the result is a prefixed signed message), or the verifier needs to process (and cache) the whole OpenPGP message to reach the signature packets at the end in order to determine the hash algorithm, to then re-process the whole message, verifying the signature.
The one-pass signature solves this issue, by allowing both the creation and verification of a signed message in a single pass. The one-pass signature solves this issue, by allowing both the creation and verification of a signed message in a single pass.
``` ```
@ -116,7 +116,7 @@ Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`,
(prefixed-signature)= (prefixed-signature)=
### Prefixed signed message ### 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`. 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 #### Structure
@ -128,9 +128,9 @@ In this format, the signature packets are stored ahead of the message itself:
```{figure} plain_svg/prefixed-signed-message.svg ```{figure} plain_svg/prefixed-signed-message.svg
:name: fig-prefixed-signed-message :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. :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. 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. 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.