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

edits for clarity

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-10 23:58:02 +01:00
parent f1f8e6be43
commit b89b8fb086
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 13 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -24,25 +24,31 @@ For an in-depth, packet-level view of encrypted data in OpenPGP, see {ref}`zoom_
Encryption in OpenPGP is performed in two distinct steps:
1. The plaintext is encrypted based on a (secret) symmetric key, the [*session key*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-confidentiality-via-encrypt). 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.
2. For each recipient of the message, a packet that contains the session key is generated.
1. **Symmetric encryption**: The plaintext is encrypted based on a (secret) symmetric key, the [*session key*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-confidentiality-via-encrypt). 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.
2. **Encapsulating session key**: 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.
```{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).
Above, "plaintext" means one of:
- *Literal Data* packet,
- *Compressed Data* packet or a
- *signed message*.
A *signed message*, in turn, 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).
```
## 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"), as they make use of different techniques to provide non-malleability. 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"). The two versions use different mechanisms 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.
SEIPD packets are typically used in combination with two mechanisms that provide *session keys*:
SEIPD packets are used in combination with two mechanisms that store *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) (PKESK) packets and
- [Symmetric-Key Encrypted Session Key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#skesk) (SKESK) packets.
@ -68,7 +74,7 @@ Typically, the sender would also include themselves as a recipient, in order to
### 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.
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 uses an S2K mechanism to derive a symmetric key from a passphrase. This key is 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