6.1 KiB
(encryption_chapter)=
Encryption
Encryption is one of the core facilities of OpenPGP. It provides confidentiality.
High-Level overview of the message encryption process
OpenPGP uses a hybrid cryptosystem. Encryption is performed in two distinct steps:
- The plaintext is encrypted with a (secret) symmetric key, the message key. The (potentially large) payload only needs to be stored once in its encrypted form, even if it is encrypted to multiple recipients.
- For each recipient of the message, a packet with information about the message key is generated.
- Usually, the information that allows retrieval of the message key is encrypted to a public encryption component key of the recipient.
- Alternatively - or additionally - the secret symmetric key may also be encrypted using a passphrase, in place of an asymmetric key. This is a specialized and less commonly used mode of operation that doesn't require OpenPGP certificates.
Generations of encryption mechanisms in OpenPGP
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. 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.
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 has 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 contained plaintext data.
Both versions of SEIPD can be used in combination with two mechanisms that provide session keys:
- Public-Key Encrypted Session Key packets (PKESK) and
- Symmetric-Key Encrypted Session Key packets (SKESK)
(SEIPDv2)=
v2 SEIPD, based on AEAD
The version 2 SEIPD mechanism is new in OpenPGP version 6, and 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 or version 6 SKESK.
In version 2 SEIPD, the session key is transformed into a message key, based on a salt value in the v2 SEIPD packet.
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 or version 4 SKESK.
When communicating with a mix of recipients, some of whose OpenPGP software only supports OpenPGP version 4, then this mechanism must be used.
Handling session keys with *ESK packets
"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).
Advanced topics
Encrypt for 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: GCM
:class: warning
Produce text around discussion: https://mailarchive.ietf.org/arch/msg/openpgp/ZTYD5VJsG1k2jJBbn5zIAf5o7d4/
Zooming in: Packet structure
Encryption yields a 'wrapped' openpgp packet stream
SKESK
Also see https://flowcrypt.com/docs/guide/send-and-receive/send-password-protected-emails.html