From cd6b049ae5bea1d67432604ac6da7eb9553e8050 Mon Sep 17 00:00:00 2001 From: "Tammi L. Coles" Date: Thu, 30 Nov 2023 17:19:42 +0100 Subject: [PATCH] edit ### Two-tier architecture --- book/source/05-private.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/source/05-private.md b/book/source/05-private.md index 6f8043f..42bd71e 100644 --- a/book/source/05-private.md +++ b/book/source/05-private.md @@ -154,21 +154,21 @@ For example, a private key store might contain a TSK with outdated certificate m This problem was notably present in GnuPG 1.x, which held separate TSK copies in its private store component. Similarly, the current design of Thunderbird's OpenPGP subsystem can lead to users experiencing such issues. ``` -### Two tiers +### Two-tier architecture -At its core, an OpenPGP private key subsystem performs operations that only require the private cryptographic key material, as in design 1. +At its core, an OpenPGP private key subsystem performs operations requiring only the private cryptographic key material, akin to the "separate backend operations" model described above. -However, some operations require additional access to the metadata of the component key. Those operations can be considered supplementary to the core keystore operations, and don't involve the private key material, themselves. When implementing a key store based on hardware cryptographic devices, like [OpenPGP card](card-priv), its design will consist of two layers: +However, the subsystem also supports operations that require additional access to the metadata of the component key. These operations, supplementary to the core key store operations, do not involve the private key material. -- One that deals immediately with private key material, and -- One that performs additional cryptographic operations, which don't directly use the private key material (in particular: [AES key wrap](https://www.rfc-editor.org/rfc/rfc3394.html) for ECDH). +When implementing a key store based on hardware cryptographic devices like [OpenPGP card](card-priv), its design will consist of two layers: + +- **core layer**: directly handles private key material, and +- **supplementary layer**: performs additional cryptographic operations that don't directly use the private key material, such as [AES key wrap](https://www.rfc-editor.org/rfc/rfc3394.html) for ECDH. ```{note} -Decryption with ECC algorithms using ECDH in particular is a multi-step procedure. + The decryption process using ECC algorithms, especially ECDH, has multiple steps. The initial step, typically performed by devices such as OpenPGP cards, directly uses private key material to produce a "shared secret." Following this, operations like ["AES key unwrap"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-ec-dh-algorithm-ecdh) are conducted in software outside the hardware device. -Only one of these steps deals directly with private key material, and is performed by e.g. an OpenPGP card device. This step produces the "shared secret". - - An additional ["AES key unwrap"](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-ec-dh-algorithm-ecdh) step happens in software, outside the card. Also see "Advanced Encryption Standard (AES) Key Wrap Algorithm" [RFC 3394](https://www.rfc-editor.org/rfc/rfc3394.html). + Further details on this process can be found in the "Advanced Encryption Standard (AES) Key Wrap Algorithm" [RFC 3394](https://www.rfc-editor.org/rfc/rfc3394.html). ``` ### Addressing individual keys