mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-10 03:39:41 +02:00
90 lines
6.1 KiB
Markdown
90 lines
6.1 KiB
Markdown
<!--
|
|
SPDX-FileCopyrightText: 2023 The "Notes on OpenPGP" project
|
|
SPDX-License-Identifier: CC-BY-SA-4.0
|
|
-->
|
|
|
|
(encryption_chapter)=
|
|
# Encryption
|
|
|
|
[Encryption](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#section-2.1) is one of the core facilities of OpenPGP. It provides confidentiality.
|
|
|
|
## High-Level overview of the message encryption process
|
|
|
|
OpenPGP uses a [hybrid cryptosystem](hybrid_cryptosystems). Encryption is performed in two distinct steps:
|
|
|
|
- The plaintext is encrypted with a (secret) symmetric key, the [*message key*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-confidentiality-via-encrypt). 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](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.
|
|
|
|
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](decryption_chapter) 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.
|
|
|
|
```{note}
|
|
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](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.
|
|
|
|
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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-public-key-encrypted-sessio) packets (PKESK) and
|
|
- [Symmetric-Key Encrypted Session Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#skesk) packets (SKESK)
|
|
|
|
(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 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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v6-pkesk) or [version 6 SKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v6-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](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#version-one-seipd) mechanism is supported by all modern OpenPGP version 4 implementations. It was introduced in [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.13).
|
|
|
|
Version 1 SEIPD can only be combined with either [version 3 PKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v3-pkesk) or [version 4 SKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v4-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](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).
|
|
|
|
## 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
|
|
|
|
```{admonition} TODO
|
|
: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
|