9.5 KiB
(decryption_chapter)=
Decryption
Message decryption is the process of taking an encrypted message and recovering its plaintext. This involves multiple steps.
Implementations typically first process the PKESK and SKESK packets leading the SEIPD packet to identify *ESK packets suitable for decryption. A PKESK packet is suitable, if it contains a recipient-keyID matching a decryption (sub-) key of the users certificate. Typically, all *ESK packets leading a SEIPD packet contain the same session-key once decrypted.
Anonymous-recipient PKESK packets contain a recipient-keyID of `0`, so if no suitable non-anonymous PKESK was found, any anonymous PKESKs are tried with any available decryption (sub-) keys (see [](decryption_anonymous_recipient)).
If no suitable PKESK packets were found, SKESK packets are tried next, meaning the user is typically prompted to enter a decryption passphrase.
Once any of these methods succeeded, the resulting session-key is used to decrypt the SEIPD packet.
:class: warning
- using expired certificate?
- using revoked certificate?
- using expired subkey?
- using revoked subkey?
Symmetric decryption of the session-key (SKESK)
Decrypting a SKESK packet to recover the session-key is done by performing the encryption steps in reverse, based on a user-provided passphrase.
In both version 4 and version 6 of the SKESK packet, the user is prompted to enter a passphrase, which is passed through the S2K function described by the SKESK packet. However, the subsequent steps of the procedure are different:
SKESK v4
Here, the result of the S2K function is a symmetric key, which is either used to decrypt the encrypted session-key contained in the SKESK packet, or - less commonly - used as session-key directly.
The "direct method" where the result of the S2K function is directly used as session key is only applicable if only one SKESK packet is present.
:name: fig-skeskv4-decryption
:alt: Diagram depicting how the S2K function is used to derive key symmetric key from the user-provided passphrase. This key is then either used directly as session-key, or used to decrypt the encrypted session-key.
Decrypting the session-key from a version 4 SKESK packet.
With version 4 SKESK packets, which are only used with version 1 SEIPD packets, the session-key is used as message-key without an intermediate derivation. The symmetric cipher algorithm tag of the SKESK packet dictates the cipher algorithm used to decrypt the plaintext from the SEIPD packet.
SKESK v6
With version 6 SKESK packets, the result of the passing the passphrase through the S2K function is used as initial keying material (IKM) to derive a symmetric key encryption key using HKDF as a key derivation function. The HKDF function doesn't use any salt in this step and the info parameter is assembled from parameters of the SKESK packet.
In the next step, this symmetric key is used to decrypt the session-key using AEAD. The AEAD function uses information from the associated SEIPDv2 packet as additional data. The function is also salted using the SEIPDv2's salt. The AEAD Auth Tag of the SKESK packet is used as authentication tag.
The result is the session-key.
:name: fig-skeskv6-decryption
:alt: Diagram depicting the complicated process of deriving the session-key from a SKESK version 6 packet.
Decrypting the session-key from a version 6 SKESK packet.
Asymmetric decryption of the session key via PKESK
More common than SKESK packets are PKESK packets which are used for asymmetric encryption of the session-key. Here, the recipients secret key is used to decrypt the session-key.
PKESK v3
With version 3 PKESKs, the recipients secret encryption (sub-) key is directly used to decrypt the encrypted session key.
The key ID of the subkey to be used is recorded in the PKESKs key-id field. A value of 0 indicates an anonymous recipient (see ).
To detect, which symmetric cipher is used to decrypt the SEIPDv1 packet later on, each public key algorithm uses a slightly different encoding to unpack the symmetric algorithm tag from the decrypted session key. See sections 5.1.3 through 5.1.7 of the OpenPGP specification. Typically, the cipher algorithm ID is prefixed the the actual session key.
:class: warning
Link those sections directly
:name: fig-decryption-pkesk3
:alt: Depicts, how the the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session-key.
Decrypting the session-key from a version 3 PKESK packet.
PKESK v6
The decryption of version 6 PKESK packets works quite similar to version 3.
:name: fig-decryption-pkesk6
:alt: Depicts, how the the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session-key.
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.
: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. Any other combinations are not allowed and MUST result in a broken message.
Since SEIPD version 1 is susceptible to downgrade attacks under certain scenarios, it is recommended to use SEIPD version 2 wherever possible.
To decrypt the contents of a version 1 SEIPD packet, the session-key obtained in the previous step is used. The cipher algorithm is determined by TODO.
:class: warning
Describe in detail, how the cipher algorithm is obtained.
Once the cipher is initialized, the whole encrypted data from the SEIPD packet is decrypted.
:class: warning
Describe the MDC which is used for modification detection.
:name: fig-decryption-seipd1
:alt: Depicts how the session-key is used directly to decrypt the contents of the SEIPD packet.
The contents of the SEIPD packet are decrypted using the session-key as message-key.
SEIPD w/ AEAD (v2)
Preferred mode. Version 2 SEIPD packets MUST only be used with version 6 PKESK packets and/or version 6 SKESK packets. Any other combinations are not allowed and MUST result in a broken message.
Once the session-key was obtained from a PKESK or SKESK, it is used to derive a message-key and an IV. This is done by passing the session-key through a salted HKDF function, where the salt is unique per message and obtained from the SEIPD packet.
The result is split into the message key and first half of the IV.
:name: fig-decryption-seipd2-mk-derivation
:alt: Depicts how the session-key is fed into a salted HKDF to derive both the message-key and the first half of an IV.
In a first step, a message-key and half of an IV is derived from the session-key.
Then, the contens of the SEIPDs encrypted data are split into chunks, which are processed sequentially. Each chunk is decrypted using AEAD with parameters from the SEIPD packet as additional data.
For each chunk, the chunk index starting at 0 is passed into the function as second half of the IV.
All decrypted plaintext blocks are appended to form the result of the decryption process.
After all blocks have been processed, in a last AEAD step, the total number of plaintext octets gets appended to the additional data and the final AEAD auth tag from the SEIPD packet is processed.
:name: fig-decryption-seipd2-chunks
:alt: Depicts, how the message-key and index-postfixed IV are used to decrypt each individual chunk of plaintext.
Each chunk is decrypted using AEAD using the message-key and an IV with appended chunk index.
SED
Legacy mode, may be decrypted, but not produced.
Advanced topics
Selecting decryption key
- Trying PKESKs until one works out
- consider "smart" strategies
additional wrinkle: hidden intended decryption key (gnupg --throw-keyid)
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