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

break out verification/encryption advanced chapters

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-12 13:58:20 +01:00
parent 43f5d8ccac
commit 4541cec324
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
5 changed files with 169 additions and 159 deletions
Download patch file Download diff file Expand all files Collapse all files

29
book/source/encryption.md
View file

@ -152,32 +152,3 @@ Explain, that with SEIPDv2, a session key can essentially protect more than one
This might very well go into the advanced topics section though.
```
## Advanced topics
### Encrypt to multiple/single subkey per certificate?
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 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 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
#### Prevent "downgrade" -> Policy
Each implementation should define a "minimum" level of security when it comes to algorithms and key lengths.
If the lowest common denominator of symmetric encryption algorithms preferred by a set of recipients provides too little security, the implementation should either use a configured fallback algorithm instead, or fail to produce a message at all.
### AEAD modes in v2 SEIPD: GCM
```{admonition} TODO
:class: warning
Produce text around discussion: https://mailarchive.ietf.org/arch/msg/openpgp/ZTYD5VJsG1k2jJBbn5zIAf5o7d4/
```