9.4 KiB
(cyrptography_chapter)=
Cryptographic concepts and terms
:class: warning
- Introduce visualizations for cryptographic primitives
- Show example visualizations for operations? (encrypt/decrypt and signing/verification - only if we're going to reuse the visual primitives later)
Cryptographic hash functions
Cryptographic hash functions take data strings of any length (like a text message or file) and output a fixed-size code, often called a "hash" or "digest." This hash acts like a unique identifier for the original data.
Here are two important properties of cryptographic hash functions:
- "Pre-image resistance": Given a hash value, it should be very difficult to determine the original data it represents.
- "Collision resistance": It should be very difficult to find two distinct pieces of data that map to the same hash value.
Symmetric-key cryptography
Symmetric-key cryptography uses the same cryptographic key for both encryption and decryption, unlike asymmetric cryptography where a pair of keys is used: a public key for encryption and a corresponding private key for decryption. Symmetric-key cryptographic systems support encryption/decryption operations.
Participants in symmetric-key operations need to exchange the shared secret over a secure channel.
---
---
A symmetric cryptographic key (which acts as a shared secret)
Benefits and downsides
Symmetric-key cryptography has major benefits: It is much faster than public-key cryptography (see below). Also, most current symmetric cryptographic algorithms are considered quantum-resistant[^postquantum].
:class: warning
I am not convinced that this information is helpful but, if it remains, perhaps we need this additional statement: "That is, symmetric-key cryptographic mechanisms are currently considered to be resilient against known computer threats, providing a measure of assurance in the evolving landscape of cryptography and quantum computing."
[^postquantum]: Daniel J. Bernstein (2009). ["Introduction to post-quantum cryptography" (PDF)](http://www.pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf) states that: "many important classes of cryptographic systems", including secret-key cryptographic mechanisms like AES "[..] are believed to resist classical computers and quantum computers." (pages 1, 2).
However, exchanging the required shared secret is a problem that needs to be solved separately.
Hybrid cryptosystems combine the advantages of symmetric-key cryptography with a separate mechanism for managing the shared secret, using public-key cryptography.
Symmetric-key cryptography in OpenPGP
Symmetric-key cryptography is used in OpenPGP in three contexts:
- most prominently, as part of a hybrid cryptosystem to encrypt and decrypt data,
- to encrypt password-protected private key material, and
- for password-protected data encryption, a less commonly used feature of the standard.
Where symmetric keys are used in OpenPGP for data encryption, they are called either "message keys" or "session keys1."
Authenticated encryption with associated data (AEAD)
Authenticated encryption offers more than just confidentiality; it ensures data integrity too.
In OpenPGP version 6, AEAD replaced the MDC2 mechanism to address malleability. In earlier OpenPGP versions, malicious alterations to ciphertext might go unnoticed. AEAD guards against such undetected changes.
By addressing the malleability problem, AEAD also counters a variation of the EFAIL3 attack.
Public-key (asymmetric) cryptography
Public-key cryptography uses asymmetric pairs of related keys. Each pair consists of a public key and a private key. These systems support encryption, decryption, and digital signature operations.
Unlike symmetric cryptography, participants are not required to pre-arrange a shared secret. In public-key cryptography, the public key material is shared openly for certain cryptographic operations, such as encryption and signature creation, while the private key, kept confidential, is used for operations like decryption and signature verification.
(asymmetric_key_pair)=
Asymmetric cryptographic key pairs
Throughout this document, we will frequently reference asymmetric cryptographic key pairs:
---
---
An asymmetric cryptographic key pair
Each key pair comprises two parts: the public key and the private key. For ease of identification, we will depict the public key in green and the private key in red throughout this document.
It's important to note that in many scenarios, only the public key is exposed or used (we will expand on these situations in subsequent sections):
---
---
The public parts of an asymmetric key pair
Usage and terminology in OpenPGP
OpenPGP extensively uses public-key cryptography for encryption and digital signing operations.
:class: note
OpenPGP documentation, including the foundational RFC, opts for the term "secret key" over the more widely accepted "private key." As a result, in the RFC, you'll encounter the "public/secret key" pairing more frequently than "public/private key." This terminology reflects historical developments in the OpenPGP community, not a difference in technology.
While "secret key" (as used in the OpenPGP RFC) and "private key" serve the same purpose in cryptographic operations, this document will use the more common "public/private" terminology for clarity and consistency with broader cryptographic discussions.
Cryptographic digital signatures
Digital signatures are a fundamental mechanism of asymmetric cryptography, providing secure, mathematical means to validate the authenticity, integrity, and origin of digital messages and documents.
In OpenPGP, digital signatures have diverse applications, extending beyond mere validation of a message's origin. They can signify various intents, including certification, consent, acknowledgment, or even revocation by the signer. The multifaceted nature of "statements" conveyed through digital signatures in cryptographic protocols is wide-ranging but crucial, allowing third parties to inspect/evaluate these statements for authenticity and intended purpose.
:class: warning
- add visualization showing: message + private key (signing) = signature -> message + signature + public key (verification) = validation confirmed?
Digital signatures in OpenPGP are used in two primary contexts:
(hybrid_cryptosystems)=
Hybrid cryptosystems
OpenPGP uses a hybrid cryptosystem. Hybrid cryptosystems combine the use of symmetric and asymmetric (public-key) cryptography to capitalize on the strengths of each, namely symmetric cryptography's speed and efficiency and public-key cryptography's mechanism for secure key exchange.
:class: warning
Move this to the chapter that details it:
Within OpenPGP's hybrid system, so-called "session keys" are central. They are generated uniquely for each session and are instrumental in both encrypting and decrypting the actual message content, using the efficiency of symmetric-key cryptography.
Using asymmetric (public-key) cryptography, the session keys are also encrypted. This ensures that only the intended recipient, the holder of the corresponding private key, can decrypt and gain access to the session key. With the decrypted session key, they can then use the session key to decrypt the actual message.
-
In OpenPGP version 6, the "Version 2 Symmetrically Encrypted Integrity Protected Data Packet Format" requires that a "message key" is derived from a "session key." In contrast, up to OpenPGP version 4, and in version 6 when using "Version 1 Symmetrically Encrypted Integrity Protected Data Packet Format", the "session key" was used directly as a symmetric encryption key. ↩︎
-
OpenPGP version 4 introduced a mechanism called MDC (Modification Detection Code), which fulfills a comparable purpose as AEAD in safeguarding message integrity. MDC is a non-standard mechanism, but no known attacks have compromised this scheme as of this document's last update. ↩︎
-
A variation of the EFAIL attack can be prevented by both the MDC and AEAD mechanisms. Also see "No, PGP is not broken, not even with the Efail vulnerabilities," especially the section "Malleability Gadget Exfiltration Channel Attack." ↩︎