mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-09 11:19:41 +02:00
sort "advanced" chapters some more
This commit is contained in:
parent
4541cec324
commit
1fd70a93ed
5 changed files with 38 additions and 33 deletions
35
book/source/adv/decryption.md
Normal file
35
book/source/adv/decryption.md
Normal file
|
@ -0,0 +1,35 @@
|
|||
<!--
|
||||
SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
|
||||
SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
-->
|
||||
|
||||
# Advanced material: Decryption
|
||||
|
||||
(decryption_seipd_quick_check)=
|
||||
## Verify successful session key decryption
|
||||
|
||||
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 by 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.
|
||||
|
||||
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.
|
||||
|
||||
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)=
|
||||
## 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.
|
||||
```
|
|
@ -3,7 +3,7 @@ SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
|
|||
SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
-->
|
||||
|
||||
# Advanced material: Private key material in OpenPGP
|
||||
# Advanced material: Private keys
|
||||
|
||||
(key-store-design)=
|
||||
## Private keystores
|
||||
|
|
|
@ -3,7 +3,7 @@ SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
|
|||
SPDX-License-Identifier: CC-BY-SA-4.0
|
||||
-->
|
||||
|
||||
# Advanced material: OpenPGP Signatures
|
||||
# Advanced material: Signatures
|
||||
|
||||
(notation_signature_subpackets)=
|
||||
## Notation signature subpackets
|
||||
|
|
|
@ -186,34 +186,3 @@ Each chunk is decrypted using AEAD using the message key and an IV with appended
|
|||
## SED
|
||||
|
||||
Legacy mode, may be decrypted, but not produced.
|
||||
|
||||
## Advanced topics
|
||||
|
||||
(decryption_seipd_quick_check)=
|
||||
### Verify successful session key decryption
|
||||
|
||||
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 by 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.
|
||||
|
||||
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.
|
||||
|
||||
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)=
|
||||
### 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.
|
||||
```
|
||||
|
|
|
@ -37,6 +37,7 @@ adv/signing_data.md
|
|||
adv/signing_components.md
|
||||
adv/verification.md
|
||||
adv/encryption.md
|
||||
adv/decryption.md
|
||||
|
||||
zoom/certificates.md
|
||||
zoom/private_keys.md
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue