vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-10 03:39: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