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

Remove some TODOs from ch10 and add some more

Browse source
This commit is contained in:
Paul Schaub 2023-12-06 21:15:24 +01:00
parent 4b507f9737
commit c5c9ae56e4
Signed by: vanitasvitae
GPG key ID: 62BEE9264BF17311
1 changed files with 39 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

51
book/source/10-encryption.md
View file

@ -34,17 +34,11 @@ Above, "plaintext" either means a *Literal Data* packet, *Compressed Data* packe
A *signed message* on the other hand is a packet sequence that either resembles an *inline-signed message* (a *Literal Data* packet sandwhiched between one or more *One-Pass-Signature* and their respective *Signature* packets), or a *prefixed-signed* message (one or more *Signature* packets followed by a single *Literal Data* packet).
```
## Generations of encryption mechanisms in OpenPGP
```{admonition} TODO
:class: warning
"Generations" here may be confused with the substantive of "generate" upon first reading. Perhaps we can find a better title?
```
## History of encryption mechanisms in OpenPGP
OpenPGP's encryption mechanisms have evolved over time. The RFC shows an [overview of encryption mechanisms](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-10.3.2.1), and how they may be combined.
Two generations of encryption mechanisms are currently relevant in OpenPGP, and will co-exist for the foreseeable future. The main difference between these lies in the symmetric part of the encryption mechanism, represented by versions 1 and 2 of the *Symmetrically Encrypted and Integrity Protected Data* packets (abbreviated as "SEIPD"). More on these below.
Two generations of encryption mechanisms are currently relevant in OpenPGP, and will co-exist for the foreseeable future. The main difference between these lies in the symmetric part of the encryption mechanism, represented by versions 1 and 2 of the *Symmetrically Encrypted and Integrity Protected Data* packets (abbreviated as "SEIPD"), as they make use of different techniques to provide non-malleability. More on these below.
Older, legacy encryption mechanisms exist in OpenPGP. However, those must not be used for encryption anymore. Messages encrypted using these legacy mechanisms may still be decrypted, although with caution. For more information see the [decryption](decryption_chapter) chapter.
@ -53,7 +47,7 @@ SEIPD packets are typically used in combination with two mechanisms that provide
- [Public-Key Encrypted Session Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-key-encrypted-sessio) (PKESK) packets and
- [Symmetric-Key Encrypted Session Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#skesk) (SKESK) packets.
The typical combination of mechanisms for encryption in OpenPGP is a [hybrid cryptosystem](hybrid_cryptosystems), consisting of [Public-Key Encrypted Session Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-key-encrypted-sessio) packets (PKESK), and a *Symmetrically Encrypted Integrity Protected Data* (SEIPD) packet. In this combination, an asymmetric cryptographic mechanism is used to protect a *session key*, with PKESK packets, and SEIPD packet is used to symmetrically encrypt the plaintext.
The typical combination of mechanisms for encryption in OpenPGP is a [hybrid cryptosystem](hybrid_cryptosystems), consisting of one or more [Public-Key Encrypted Session Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-key-encrypted-sessio) packets (PKESK), followed by a [Symmetrically Encrypted Integrity Protected Data* (SEIPD) packet. In this combination, an asymmetric cryptographic mechanism is used to protect a *session key* inside PKESK packets, which is used to protect the plaintext using symmetric-key encryption in a SEIPD packet.
## Encapsulating session keys: PKESK, SKESK
@ -62,7 +56,7 @@ The typical combination of mechanisms for encryption in OpenPGP is a [hybrid cry
- [PKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-key-encrypted-sessio): Uses asymmetric OpenPGP key material to protect a session key, and
- [SKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-symmetric-key-encrypted-ses): Uses passphrases to protect the symmetric key material, instead of OpenPGP asymmetric key material (this is less commonly used).
An arbitrary number of PKESKs and SKESKs can be used for the same message.
An arbitrary number of PKESKs and SKESKs can be used for the same message. It is also possible to mix those, resulting in a message which can be decrypted using either one of the designated OpenPGP keys or any of the passwords used to encrypt the message. This is useful to make a message available to a number of known recipients, with the option to provide the password to future recipients.
### PKESK: Session key encrypted to an asymmetric OpenPGP key
@ -70,12 +64,23 @@ To encrypt an OpenPGP message for a recipient, the session-key is encrypted to t
This procedure is repeated for each recipient of the message, and all resulting PKESK packets are prepended to the SEIPD packet (see below) containing the actual message.
Typically, the sender would also include themselves as a recipient, in order to be able to decrypt the sent message at a later point in time.
### SKESK: Session key encrypted to a passphrase
As an alternative (or augmentation) to PKESK packets, a message can also be encrypted to a symmetric passphrase. This is done using a SKESK packet, which basically uses an S2K mechanism to derive a symmetric key from a passphrase, which is then either used directly as the session-key, or more commonly, used as a key-encapsulation-key (KEK) to encrypt the session-key.
Also see https://flowcrypt.com/docs/guide/send-and-receive/send-password-protected-emails.html
As for protection of secret key material, it is important to chose appropriate S2K parameters when generating an SKESK packet.
The specification currently recommends to use either *Iterated and Salted S2K* or *Argon2*.
```{admonition} TODO:
:class: warning
Add further guidance for recommended S2K parameters, like iteration count or Argon2 configuration. Perhaps in a dedicated "S2K Parameters" section, which can be reused for the encryption chapter and when we talk about secret key encryption in TSKs.
```
## Symmetric encryption of data, SEIPD
*Symmetrically Encrypted Integrity Protected Data* (SEIPD) packets represent the symmetric aspect of OpenPGP's encryption mechanism. The function of these packets is entirely independent of (asymmetric) OpenPGP keys.
@ -86,7 +91,7 @@ A SEIPD packet contains the actual payload: the ciphertext of the encrypted mess
SEIPD packets are the successor to the [Symmetrically Encrypted Data](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-symmetrically-encrypted-dat) packet, which is obsolete.
```
Two versions of the SEIPD packet (separated by the version number) have been specified. Version 1, introduced in RFC4880, is used in OpenPGP v4 (and can be used with v6) while SEIPD version 2 was introduced with OpenPGP v6 and is not backwards compatible to OpenPGP v4.
Two versions of the SEIPD packet (differentiated by the version number) have been specified. Version 1, introduced in RFC4880, is used in OpenPGP v4 while SEIPD version 2 was introduced with OpenPGP v6. Both versions can be used with either OpenPGP v4 or v6 keys, although OpenPGP v4 keys need to announce support for SEIPD version 2 via the *Feature* signature subpacket.
When decrypted, the data contained in a SEIPD packet forms an [OpenPGP message](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-openpgp-messages). That is, the decrypted data consists of a series of OpenPGP packets.
@ -112,7 +117,7 @@ With SEIPDv1, the session-key is directly used as message-key to encrypt the pay
(SEIPDv2)=
### v2 SEIPD, based on AEAD
The [version 2 SEIPD](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#version-two-seipd) mechanism was introduced in OpenPGP version 6, and is only supported by OpenPGP version 6 implementations. Consequently, it can only be used for encryption when all recipients support OpenPGP version 6.
The [version 2 SEIPD](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#version-two-seipd) mechanism was introduced in OpenPGP version 6. Consequently, it can only be used for encryption when all recipients explicitly announce support for it using a *Feature* signature subpacket.
It provides integrity protection of the ciphertext using *AEAD* (authenticated encryption with additional data).
v2 SEIPD can only be combined with either [version 6 PKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v6-pkesk) and/or [version 6 SKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v6-skesk) packets.
@ -129,6 +134,8 @@ The session-key can use a different symmetric algorithm than the message-key.
With SEIPDv2, the message-key is derived from the session-key in an extra step.
```
This additional step introduces key-separation into the protocol, which protects against certain attacks, such as an [OpenPGP SEIP downgrade attack](https://www.metzdowd.com/pipermail/cryptography/2015-October/026685.html).
```{admonition} TODO
:class: warning
@ -141,12 +148,32 @@ This might very well go into the advanced topics section though.
### Encrypt to multiple/single subkey per certificate?
A recipients certificate may possibly contain more than one usable encryption subkey.
This raises the question, should the message be encrypted for all of them?
There is the argument, that a powerful attacker might have managed to add an attacker-controlled encryption subkey to the victims certificate.
In this case, only encrypting to the "newest" encryption key would help uncovering such an attack, although a powerful attacker could just MitM any sent messages and just add a PKESK for the victim-controlled encryption keys to hide the fact that the sender used a different key.
On the other hand, a user might have multiple encryption subkeys on purpose.
Picture for example a scenario where the same certificate is used on multiple devices, but each devices has dedicated encryption subkeys to allow for smoother revocation in case of a lost device.
In this scenario, it is important that the sender encrypts the message to all available encryption subkeys.
### "Negotiating" algorithms based on recipients preference subpackets
#### Prevent "downgrade" -> Policy
Each implementation should define a "minimum" level of security when it comes to algorithms.
If the lowest common denominator of symmetric encryption algorithms preferred by a set of recipients provides too little security, the implementation should either use a fallback algorithm instead, or fail to produce a message at all.
### Implications of how a recipient cert is "addressed" (fingerprint/key-ID vs. user-ID) (preferences, expiration, revocation)
```{admonition} TODO
:class: warning
This has been described elsewhere already.
See 9.7.3
```
### AEAD modes in v2 SEIPD: GCM
```{admonition} TODO