Move anonymous recipient section to advanced topics

This commit is contained in:
Paul Schaub 2023-12-08 15:44:18 +01:00
parent f37472fc3e
commit 9a8dc3ce47
Signed by: vanitasvitae
GPG key ID: 62BEE9264BF17311

View file

@ -114,22 +114,6 @@ Decrypting the session-key from a version 6 PKESK packet.
Contrary to the version 3 PKESK, the encrypted session-key within the version 6 PKESK does not contain the symmetric cipher algorithm used to decrypt the SEIPD packet.
Instead, this cipher algorithm ID is encoded inside the SEIPDv2 packet directly.
(decryption_anonymous_recipient)=
### Anonymous recipients
Having all recipients keys listed as part of the PKESK packets presents a metadata leakage. An observer can easily enumerate recipients of a message by comparing the PKESKs with certificates of potential recipients.
To prevent this issue, the sender can decide to add individual recipients as anonymous recipients using a wildcard key-ID / fingerprint.
This is done by creating a normal PKESK packet for the recipient, but setting the recipient key field to `0` (as well as omitting the version number of the key for v6 PKESKs).
A recipient of such a message that does not find a PKESK addressed specifically to any of their keys, can then try to decrypt any anonymous PKESK packets using any of their encryption subkeys.
```{admonition} TODO
:class: warning
When did the decryption succeed? Describe quick check of the check sum and decryption of first few bytes of the SEIPD as test strategies.
```
## SEIPD (v1)
Version 1 SEIPD packets MUST only be used with version 3 PKESK packets and/or version 4 SKESK packets.
@ -213,4 +197,21 @@ also see:
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#pkesk-notes
> An implementation MAY accept or use a Key ID of all zeros, or an omitted key fingerprint, to hide the intended decryption key
(decryption_anonymous_recipient)=
> An implementation MAY accept or use a Key ID of all zeros, or an omitted key fingerprint, to hide the intended decryption key(decryption_anonymous_recipient)=
### Anonymous recipients
Having all recipients keys listed as part of the PKESK packets presents a metadata leakage. An observer can easily enumerate recipients of a message by comparing the PKESKs with certificates of potential recipients.
To prevent this issue, the sender can decide to add individual recipients as anonymous recipients using a wildcard key-ID / fingerprint.
This is done by creating a normal PKESK packet for the recipient, but setting the recipient key field to `0` (as well as omitting the version number of the key for v6 PKESKs).
A recipient of such a message that does not find a PKESK addressed specifically to any of their keys, can then try to decrypt any anonymous PKESK packets using any of their encryption subkeys.
To reduce the number of keys to try, the recipient can skip all secret keys which do not share the public-key algorithm stated in the PKESK packet.
```{admonition} TODO
:class: warning
When did the decryption succeed? Describe quick check of the check sum and decryption of first few bytes of the SEIPD as test strategies.
```