From 39ed1873d0e0ca6cea62d6c03d6a906de3f72b22 Mon Sep 17 00:00:00 2001 From: Paul Schaub Date: Fri, 8 Dec 2023 15:44:50 +0100 Subject: [PATCH] Add more info about SEIPDv1's quick check mechanism --- book/source/11-decryption.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/book/source/11-decryption.md b/book/source/11-decryption.md index 3e8b318..a14b3df 100644 --- a/book/source/11-decryption.md +++ b/book/source/11-decryption.md @@ -186,19 +186,17 @@ Legacy mode, may be decrypted, but not produced. ## Advanced topics -### Selecting decryption key +### Verify successful session-key decryption -- Trying PKESKs until one works out -- consider "smart" strategies +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. +During decrypting, these 2 bytes can be compared to the 15th and 16th random byte to detect use of the wrong session key. -additional wrinkle: hidden intended decryption key (`gnupg --throw-keyid`) - -also see: +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. -https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#pkesk-notes +The standard [warns against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-risks-of-a-quick-check-orac) using the quick check mechanism, as it introduces the risk of a decryption oracle. Instead, the use of SEIPDv2 is recommended, as the AEAD mechanism automatically detects use of the wrong session-key early on after the first chunk has been decrypted. (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.