mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-12-22 13:57:59 +01:00
Shift away from "plaintext" term for the signed data
Talking about "plaintext" seems potentially confusing, especially when signing an encrypted message.
This commit is contained in:
parent
ad68dc83da
commit
7d756c77ee
1 changed files with 3 additions and 3 deletions
|
@ -35,7 +35,7 @@ Note that {term}`data signatures<Data Signature>` are distinct from [](/signing_
|
|||
|
||||
- **{term}`Detached<Detached Signature>`**: The OpenPGP signature exists as a separate entity, independent of the signed data.
|
||||
- **{term}`Inline<Inline Signature>`**: Both the original data and its corresponding {term}`OpenPGP signature<OpenPGP Signature Packet>` are encapsulated within an {term}`OpenPGP message`.
|
||||
- **{term}`Cleartext signature`**: A plaintext message and its {term}`OpenPGP signature<OpenPGP Signature Packet>` coexist in a combined text format, preserving the readability of the original message.
|
||||
- **{term}`Cleartext signature`**: A plain text message and its {term}`OpenPGP signature<OpenPGP Signature Packet>` coexist in a combined text format, preserving the readability of the original message.
|
||||
|
||||
[^sign-modes-gpg]: These three forms of {term}`signature<OpenPGP Signature Packet>` application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options.
|
||||
|
||||
|
@ -89,7 +89,7 @@ Instead, it's a type of auxiliary packet that can be used in conjunction with {t
|
|||
|
||||
#### The function of the one-pass signature packet
|
||||
|
||||
To understand the purpose of this packet, consider that without it, the position of signature packets within an inline signed OpenPGP message constitutes a trade-off for efficient data processing. In particular when plaintext data is large and exceeds available memory in size.
|
||||
To understand the purpose of this packet, consider that without it, the position of signature packets within an inline signed OpenPGP message constitutes a trade-off for efficient data processing. In particular when signed data is large and exceeds available memory in size.
|
||||
|
||||
The producer of a signed OpenPGP message wants to streamline the signature calculation process in such a way that allows to emit a copy of the signed data while calculating the cryptographic signature. On the signer's side, the signature packet is therefore easy to store after the signed data.
|
||||
|
||||
|
@ -109,7 +109,7 @@ The signer can easily emit this metadata before processing the full message, and
|
|||
|
||||
#### Creation
|
||||
|
||||
To produce an {term}`inline signature`, the {term}`signer` decides on a hash algorithm and emits a {term}`one-pass signature packet<One-pass Signature Packet>` into the destination {term}`OpenPGP message`. This contains essential information such as the {term}`fingerprint<OpenPGP Fingerprint>` of the {term}`signing key<OpenPGP Component Key>` and the {term}`hash<Hash Digest>` algorithm used for computing the {term}`signature<OpenPGP Signature Packet>`'s {term}`hash digest`. The signer then processes the entirety of the plaintext data, emitting it as a {term}`literal data<Literal Data Packet>` into the message as well. Once the data is processed, the {term}`signer` calculates a {term}`cryptographic signature` using the calculated hash value. Lastly, the result is emitted as a {term}`data signature packet` to the output message, and the whole packet sequence can be efficiently stored or transmitted.
|
||||
To produce a {term}`one-pass inline signature<One-pass signed Message>`, the {term}`signer` decides on a hash algorithm and emits a {term}`one-pass signature packet<One-pass Signature Packet>` into the destination {term}`OpenPGP message`. This contains essential information such as the {term}`fingerprint<OpenPGP Fingerprint>` of the {term}`signing key<OpenPGP Component Key>` and the {term}`hash<Hash Digest>` algorithm used for computing the {term}`signature<OpenPGP Signature Packet>`'s {term}`hash digest`. The signer then processes the entirety of the signed data, emitting it as a {term}`literal data<Literal Data Packet>` into the message as well. Once the data is processed, the {term}`signer` calculates a {term}`cryptographic signature` using the calculated hash value. Lastly, the result is emitted as a {term}`data signature packet` to the output message, and the whole packet sequence can be efficiently stored or transmitted.
|
||||
|
||||
For efficient {term}`verification`, an application must understand how to handle the {term}`literal data<Literal Data Packet>` prior to reading from it. This requirement is addressed by the {term}`one-pass signature packets<One-pass Signature Packet>` located at the beginning of {term}`inline-signed<Inline Signature>` messages. This setup enables the verifier to process the data correctly and efficiently in only a single pass.
|
||||
|
||||
|
|
Loading…
Reference in a new issue