ch10 feedback

This commit is contained in:
Paul Schaub 2023-11-27 22:47:29 +01:00 committed by Heiko Schaefer
parent 3d8bd5eab3
commit a4969aa98b
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB

View file

@ -10,6 +10,16 @@ SPDX-License-Identifier: CC-BY-SA-4.0
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:
@ -19,13 +29,24 @@ Encryption in OpenPGP is performed in two distinct steps:
- 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.
```{note}
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
```{admonition} TODO
: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](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.
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.
## Symmetric encryption of data, SEIPD
@ -51,7 +72,7 @@ The typical combination of mechanisms for encryption in OpenPGP is a [hybrid cry
(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).
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. 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.
In version 2 SEIPD, the *session key* is transformed into a *message key*, based on a salt value in the v2 SEIPD packet.
@ -59,7 +80,7 @@ In version 2 SEIPD, the *session key* is transformed into a *message key*, based
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).
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) and/or [version 4 SKESK](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#v4-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.