vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +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

12
book/source/10-encryption.md
View file

@ -70,7 +70,7 @@ An arbitrary number of PKESKs and SKESKs can be used in the same message. It is
### PKESK: Session key encrypted to an asymmetric OpenPGP key
To encrypt an OpenPGP message for a recipient, the session key is encrypted to the recipients public key. The resulting encrypted session key is packed into a PKESK packet, which holds essential metadata, like an identifier of the recipients encryption (sub)-key.
To encrypt an OpenPGP message for a recipient, the session key is encrypted to the recipient's public key. The resulting encrypted session key is packed into a PKESK packet, which holds essential metadata, like an identifier of the recipients encryption (sub)-key.
This procedure is repeated for each recipient of the message, and all resulting PKESK packets are prepended to the SEIPD packet (see below) containing the actual message.
@ -82,7 +82,7 @@ As an alternative (or augmentation) to PKESK packets, a message can also be encr
Also see https://flowcrypt.com/docs/guide/send-and-receive/send-password-protected-emails.html
As for protection of secret key material, it is important to chose appropriate S2K parameters when generating an SKESK packet.
As for protection of secret key material, it is important to choose appropriate S2K parameters when generating an SKESK packet.
The specification currently recommends to use either *Iterated and Salted S2K* or *Argon2*.
```{admonition} TODO:
@ -158,14 +158,14 @@ This might very well go into the advanced topics section though.
### Encrypt to multiple/single subkey per certificate?
A recipients certificate may possibly contain more than one usable encryption subkey.
A recipient's certificate can contain more than one usable encryption subkey.
This raises the question, should the message be encrypted for all of them?
There is the argument, that a powerful attacker might have managed to add an attacker-controlled encryption subkey to the victims certificate.
In this case, only encrypting to the "newest" encryption key would help uncovering such an attack, although a powerful attacker could just MitM any sent messages and just add a PKESK for the victim-controlled encryption keys to hide the fact that the sender used a different key.
There is the argument that a powerful attacker might have managed to add an attacker-controlled encryption subkey to the victim's certificate.
In this case, only encrypting to the "newest" encryption key would help uncover such an attack. However, a powerful attacker could just MitM any sent messages and just add a PKESK for the victim-controlled encryption keys to hide the fact that the sender used a different key.
On the other hand, a user might have multiple encryption subkeys on purpose.
Picture for example a scenario where the same certificate is used on multiple devices, but each devices has dedicated encryption subkeys to allow for smoother revocation in case of a lost device.
Picture, for example, a scenario where the same certificate is used on multiple devices, but each device has dedicated encryption subkeys to allow for smoother revocation in case of a lost device.
In this scenario, it is important that the sender encrypts the message to all available encryption subkeys.
### "Negotiating" algorithms based on recipients preference subpackets

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.