From b89b8fb086c0da9f23efa4d0b07e7234d4f21af4 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sun, 10 Dec 2023 23:58:02 +0100 Subject: [PATCH] edits for clarity --- book/source/10-encryption.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/book/source/10-encryption.md b/book/source/10-encryption.md index d8ac4c5..4b3cb4f 100644 --- a/book/source/10-encryption.md +++ b/book/source/10-encryption.md @@ -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