From 9a8dc3ce47c4994d400685dac1c3a59df2cde317 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Fri, 8 Dec 2023 15:44:18 +0100 Subject: [PATCH] Move anonymous recipient section to advanced topics --- book/source/11-decryption.md | 35 ++++++++++++++++++----------------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/book/source/11-decryption.md b/book/source/11-decryption.md index 7760cc5..3e8b318 100644 --- a/book/source/11-decryption.md +++ b/book/source/11-decryption.md @@ -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 \ No newline at end of file +(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. +```