8.8 KiB
(encryption_chapter)=
Encryption
Encryption is one of the core facilities of OpenPGP. It provides confidentiality.
For an in-depth, packet-level view of encrypted data in OpenPGP, see {ref}zoom_enc.
Terminology
| Term | Description |
|---|---|
| SEIPD Packet | Symmetrically Encrypted, Integrity Protected Data packet; contains the encrypted message payload |
| SKESK Packet | Symmetric-Key-Encrypted Session-Key packet; contains or provides a passphrase-encrypted Session-Key |
| PKESK Packet | Public-Key-Encrypted Session-Key packet; contains a session-key encrypted using an asymmetric public-key |
| Session-Key | Symmetric encryption key, which is either used directly as - or to derive - the Message-Key |
| Message-Key | Symmetric encryption key used to encrypt the contents of the SEIPD packet |
High-Level overview of the message encryption process
Encryption in OpenPGP is performed in two distinct steps:
- The plaintext is encrypted based on a (secret) symmetric key, the session key. The (potentially large) ciphertext only needs to be stored once, even if it is sent to multiple recipients. All recipients get access to the same shared session key to decrypt the message.
- For each recipient of the message, a packet that contains the session key is generated.
- Usually, the session key is encrypted to a public encryption component key of the recipient.
- Alternatively - or additionally - the session key may also be encrypted using a passphrase. This is a specialized and less commonly used mode of operation that doesn't require OpenPGP certificates.
Above, "plaintext" either means a *Literal Data* packet, *Compressed Data* packet or a *signed message*.
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
:class: warning
"Generations" here may be confused with the substantive of "generate" upon first reading. Perhaps we can find a better title?
OpenPGP's encryption mechanisms have evolved over time. The RFC shows an overview of encryption mechanisms, 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.
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 chapter.
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. The SEIPD mechanisms only deal with symmetric cryptography.
A SEIPD packet contains the actual payload: the ciphertext of the encrypted message. For a large encrypted message, the SEIPD packet will also be large.
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.
When decrypted, the data contained in a SEIPD packet forms an OpenPGP message. That is, the decrypted data consists of a series of OpenPGP packets.
In both versions of SEIPD, the decryptor must have obtained a session key in a previous step, before processing the SEIPD packet. Using this session key, the decryptor can decrypt the SEIPD packet and process the plaintext data that it contains.
Both versions of SEIPD can be used in combination with two mechanisms that provide session keys:
- Public-Key Encrypted Session Key (PKESK) packets and
- Symmetric-Key Encrypted Session Key (SKESK) packets.
The typical combination of mechanisms for encryption in OpenPGP is a hybrid cryptosystem, consisting of Public-Key Encrypted Session Key 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.
(SEIPDv2)=
v2 SEIPD, based on AEAD
The version 2 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. v2 SEIPD can only be combined with either version 6 PKESK and/or version 6 SKESK packets.
In version 2 SEIPD, the session key is transformed into a message key, based on a salt value in the v2 SEIPD packet.
:name: fig-encryption-seipdv2-pkesk
:alt: TODO
With SEIPDv2, the message-key is derived from the session-key in an extra step.
v1 SEIPD, based on MDC
The version 1 SEIPD mechanism is supported by all modern OpenPGP version 4 implementations. It was introduced in RFC 4880.
Version 1 SEIPD can only be combined with either version 3 PKESK and/or version 4 SKESK packets.
When communicating with a mix of recipients, some of whose OpenPGP software only supports OpenPGP version 4, then this mechanism must be used.
:name: fig-encryption-seipdv1-pkesk
:alt: Depicts a dotted hexagon labeled "Plaintext", from which a curved arrow passes another dotted hexagon "Session Key" and finally points to a "SEIPDv1" packet. Two more curved arrows originate from the session key and pass Alice' and Bob's encryption key, ending in two PKESK packets.
With SEIPDv1, the session-key is directly used as message-key to encrypt the payload
Handling encrypted session keys: PKESK, SKESK
"*ESK" is a family of mechanisms for dealing with symmetric key material. It has two branches:
- PKESK: Uses asymmetric OpenPGP key material to protect a session key, and
- SKESK: Uses passphrases to protect the symmetric key material, instead of OpenPGP asymmetric key material (this is less commonly used).
PKESK: Session key encrypted to an asymmetric OpenPGP key
SKESK: Session key encrypted to a passphrase
Also see https://flowcrypt.com/docs/guide/send-and-receive/send-password-protected-emails.html
Advanced topics
Encrypt to multiple/single subkey per certificate?
"Negotiating" algorithms based on recipients preference subpackets
Prevent "downgrade" -> Policy
Implications of how a recipient cert is "addressed" (fingerprint/key-ID vs. user-ID) (preferences, expiration, revocation)
AEAD modes in v2 SEIPD: GCM
:class: warning
Produce text around discussion: https://mailarchive.ietf.org/arch/msg/openpgp/ZTYD5VJsG1k2jJBbn5zIAf5o7d4/