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

Add more info about SEIPDv1's quick check mechanism

Browse source
This commit is contained in:
Paul Schaub 2023-12-08 15:44:50 +01:00 • committed by Heiko Schaefer
parent 6371b60512
commit 39ed1873d0
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 6 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

14
book/source/11-decryption.md
View file

@ -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.