vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-10 19:59:40 +02:00
Code Issues Projects Releases Packages Wiki Activity

spelling fixes

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-11 02:02:07 +01:00
parent 07dc692b2b
commit d628bb7a48
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
2 changed files with 15 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

18
book/source/11-decryption.md
View file

@ -10,7 +10,7 @@ Message decryption is the process of taking an encrypted message and recovering
This involves multiple steps.
Implementations typically first process the PKESK and SKESK packets leading the SEIPD packet to identify \*ESK packets suitable for decryption.
A PKESK packet is suitable, if it contains a recipient-Key ID matching a decryption (sub-) key of the users certificate.
A PKESK packet is suitable if it contains a recipient-Key ID matching a decryption (sub-) key of the user's certificate.
Typically, all \*ESK packets leading a SEIPD packet contain the same *session key* once decrypted.
```{note}
@ -70,7 +70,7 @@ Sanitizing this algorithm ID of the decrypted session key acts as a very early q
### SKESK v6
With version 6 SKESK packets, the result of the passing the passphrase through the S2K function is used as *initial keying material* (IKM) to derive a symmetric *key encryption key* using HKDF as a key derivation function. The HKDF function doesn't use any salt in this step and the *info* parameter is assembled from parameters of the SKESK packet.
With version 6 SKESK packets, the result of the passing the passphrase through the S2K function is used as *initial keying material* (IKM) to derive a symmetric *key encryption key* using HKDF as a key derivation function. The HKDF function doesn't use any salt in this step, and the *info* parameter is assembled from parameters of the SKESK packet.
In the next step, this symmetric key is used to decrypt the *session key* using AEAD.
The AEAD function uses information from the associated SEIPDv2 packet as *additional data*.
@ -92,10 +92,10 @@ More common than SKESK packets are PKESK packets which are used to protect the s
### PKESK v3
With version 3 PKESKs, the recipients secret encryption (sub-) key is directly used to decrypt the encrypted *session key*.
With version 3 PKESKs, the recipient's secret encryption (sub-) key is directly used to decrypt the encrypted *session key*.
The Key ID of the subkey to be used is recorded in the PKESKs key-id field. A value of `0` indicates an anonymous recipient (see [](decryption_anonymous_recipient)).
To detect, which symmetric cipher is used to decrypt the SEIPDv1 packet later on, each public key algorithm uses a slightly different encoding to unpack the symmetric algorithm tag from the decrypted session key. See the respective sections[^rsa-spec] [^elgamal-spec] [^ecdh-spec] [^x25519-spec] [^x448-spec] of the standard. Typically, the cipher algorithm ID is prefixed the the actual session key.
To detect, which symmetric cipher is used to decrypt the SEIPDv1 packet later on, each public key algorithm uses a slightly different encoding to unpack the symmetric algorithm tag from the decrypted session key. See the respective sections[^rsa-spec] [^elgamal-spec] [^ecdh-spec] [^x25519-spec] [^x448-spec] of the standard. Typically, the cipher algorithm ID is prefixed to the actual session key.
[^rsa-spec]: [Algorithm-Specific Fields for RSA encryption](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-fields-f)
[^elgamal-spec]: [Algorithm-Specific Fields for Elgamal encryption](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-fields-fo)
@ -105,18 +105,18 @@ To detect, which symmetric cipher is used to decrypt the SEIPDv1 packet later on
```{figure} drawio/PKESKv3-decryption.svg
:name: fig-decryption-pkesk3
:alt: Depicts, how the the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session key.
:alt: Depicts, how the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session key.
Decrypting the session key from a version 3 PKESK packet.
```
### PKESK v6
The decryption of version 6 PKESK packets works quite similar to version 3.
The decryption of version 6 PKESK packets works quite similarly to version 3.
```{figure} drawio/PKESKv6-decryption.svg
:name: fig-decryption-pkesk6
:alt: Depicts, how the the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session key.
:alt: Depicts, how the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session key.
Decrypting the session key from a version 6 PKESK packet.
```
@ -174,7 +174,7 @@ For each chunk, the chunk index starting at `0` is passed into the function as s
All decrypted plaintext blocks are appended to form the result of the decryption process.
After all blocks have been processed, in a last AEAD step, the total number of plaintext octets gets appended to the *additional data* and the final AEAD auth tag from the SEIPD packet is processed.
After all blocks have been processed, in a final AEAD step, the total number of plaintext octets gets appended to the *additional data* and the final AEAD auth tag from the SEIPD packet is processed.
```{figure} drawio/SEIPDv2-decryption-chunks.svg
:name: fig-decryption-seipd2-chunks
@ -194,7 +194,7 @@ Legacy mode, may be decrypted, but not produced.
### Verify successful session key decryption
SEIPDv1 packets might make use of a "quick check" mechanism to quickly verify that the correct session key was used without the need to decrypt the whole SEIPD packet.
This check consists of 16 random bytes, followed a copy of the two last bytes, which are prefixed to the plaintext.
This check consists of 16 random bytes, followed by a copy of the two last bytes, which are prefixed to the plaintext.
During decrypting, these 2 bytes can be compared to the 15th and 16th random byte to detect use of the wrong session key.
Since the chance to accidentally end up with matching quick check bytes albeit the use of the wrong session key is 1:65536, some implementations validate further contents of the plaintext, such as the packet headers.