diff --git a/book/source/05-private.md b/book/source/05-private.md index ce52cce..5b4fc78 100644 --- a/book/source/05-private.md +++ b/book/source/05-private.md @@ -34,7 +34,7 @@ In certain cases, an exception arises where the cryptographic private key materi ## Transferable secret key format -Sometimes it is useful to handle OpenPGP certificates combined with private key material in the form of a [*transferable secret key (TSK)*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-transferable-secret-keys). A TSK is a serialized format that combines OpenPGP certificate data with its connected private key material, stored in a single file. +Sometimes it is useful to handle OpenPGP certificates combined with private key material in the form of a [*transferable secret key (TSK)*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-transferable-secret-keys). A TSK is a serialized format that combines OpenPGP certificate data with its connected private key material, stored in a single file. ```{figure} diag_converted/TSK.svg :name: fig-transferable-secret-key @@ -66,7 +66,7 @@ This method proves effective in scenarios where an unauthorized party obtains th When protecting private key material in OpenPGP, a symmetric key is derived from the user's passphrase. This derived key is then used to protect the OpenPGP private key data. -To facilitate this, the OpenPGP standard defines a set of mechanisms known as [string-to-key (S2K)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-string-to-key-s2k-specifier). S2K mechanisms are used to generate high-entropy symmetric encryption keys from lower-entropy passphrases, using a [key derivation function (KDF)](https://en.wikipedia.org/wiki/Key_derivation_function). +To facilitate this, the OpenPGP standard defines a set of mechanisms known as [string-to-key (S2K)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-string-to-key-s2k-specifier). S2K mechanisms are used to generate high-entropy symmetric encryption keys from lower-entropy passphrases, using a [key derivation function (KDF)](https://en.wikipedia.org/wiki/Key_derivation_function). ```{figure} diag_converted/passphrase_using_S2K.svg :name: fig-passphrase-using-s2k @@ -79,10 +79,10 @@ This symmetric key is used to protect the private key material it is in a passiv #### Mechanisms for symmetric key generation -Over time, OpenPGP has evolved to include various [S2K mechanisms for generating symmetric keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-string-to-key-s2k-types-reg), in line with advancements in cryptographic practices. Currently, two mechanisms are universally recommended: +Over time, OpenPGP has evolved to include various [S2K mechanisms for generating symmetric keys](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-string-to-key-s2k-types-reg), in line with advancements in cryptographic practices. Currently, two mechanisms are universally recommended: -- [**Argon2**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-argon2): Introduced in OpenPGP version 6, Argon2 is a memory-hard mechanism designed to reduce the efficiency of brute-force attacks using specialized hardware. -- [**Iterated and Salted S2K**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-iterated-and-salted-s2k): This mechanism is a staple with OpenPGP version 4 implementations. +- [**Argon2**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-argon2): Introduced in OpenPGP version 6, Argon2 is a memory-hard mechanism designed to reduce the efficiency of brute-force attacks using specialized hardware. +- [**Iterated and Salted S2K**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-iterated-and-salted-s2k): This mechanism is a staple with OpenPGP version 4 implementations. A third mechanism is conditionally allowed for key generation. Decryption of private keys that use obsolete mechanisms is also allowed. diff --git a/book/source/18-zoom_certificates.md b/book/source/18-zoom_certificates.md index 48d0c5b..8e436e1 100644 --- a/book/source/18-zoom_certificates.md +++ b/book/source/18-zoom_certificates.md @@ -357,7 +357,7 @@ This next section shows the remaining fields of this signature packet, which rel - `ed25519_sig`: [algorithm-specific](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-algorithm-specific-fields-for-ed2) representation of the signature (here: 64 bytes of Ed25519 signature) -The hash digest is calculated from the following data (see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC): +The hash digest is calculated from the following data (see [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-computing-signatures) in the RFC): - the signature's salt - the serialized primary key's public data @@ -533,7 +533,7 @@ The signature is calculated over a hash digest. In this case, the hash digest is - the serialized subkey's public data - the serialized subkey binding signature packet (excluding the unhashed area) -Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for details. +Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-computing-signatures) in the RFC for details. ## Signing subkey @@ -782,7 +782,7 @@ Historically, the self-signature that binds the primary User ID to the certifica Setting key expiration time and key flags on the primary User ID self-signature is one mechanism to configure the primary key. -The interaction between metadata on direct key signatures and User ID binding self-signatures [is subtle](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-notes-on-self-signatures), with changes between version 6 and version 4. +The interaction between metadata on direct key signatures and User ID binding self-signatures [is subtle](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-self-signatures), with changes between version 6 and version 4. ```{admonition} TODO @@ -804,7 +804,7 @@ The signature is calculated over a hash. The hash, in this case, is derived from - the serialized User ID This section specifies- the serialized self-signature packet (excluding the unhashed area) -Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-computing-signatures) in the RFC for details. +Refer to [Computing Signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-computing-signatures) in the RFC for details. ## Certifications (Third Party Signatures) diff --git a/book/source/19-zoom_private_keys.md b/book/source/19-zoom_private_keys.md index 548a291..cfc233b 100644 --- a/book/source/19-zoom_private_keys.md +++ b/book/source/19-zoom_private_keys.md @@ -183,7 +183,7 @@ The next set of data is the "string-to-key (S2K) specifier." Its format depends - `s2k_type: 0x04` [String-to-Key (S2K) Specifier Type](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-string-to-key-s2k-specifier-), set to *Argon2* here. -The next fields are [specific to Argon2](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#name-argon2): +The next fields are [specific to Argon2](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-argon2): - `argon2_salt`: "16-octet salt value" - `argon2_t`: "number of passes t" @@ -195,7 +195,7 @@ The next fields are [specific to Argon2](https://www.ietf.org/archive/id/draft-i Where is that IV: -["If string-to-key usage octet was 253 (AEAD), an initialization vector (IV) of size specified by the AEAD algorithm (see Section 5.13.2), which is used as the nonce for the AEAD algorithm"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-11.html#section-5.5.3-3.4.2.5) +["If string-to-key usage octet was 253 (AEAD), an initialization vector (IV) of size specified by the AEAD algorithm (see Section 5.13.2), which is used as the nonce for the AEAD algorithm"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.5.3-3.4.2.5) Is the example key wrong?! ```