mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-09 11:19:41 +02:00
Convert also drawio based SVGs to plain SVGs and use unified path
Load all plain SVGs from a unified path. Signed-off-by: David Runge <dave@sleepmap.de>
This commit is contained in:
parent
4b0bc1c007
commit
707ac2f78e
11 changed files with 36 additions and 36 deletions
2
.gitignore
vendored
2
.gitignore
vendored
|
@ -3,4 +3,4 @@
|
|||
|
||||
.idea
|
||||
book/build/
|
||||
book/source/diag_converted
|
||||
book/source/plain_svg
|
||||
|
|
|
@ -21,11 +21,11 @@ BUILDDIR = build
|
|||
|
||||
# clean build output and also preprocessed/ converted data
|
||||
clean-all: clean
|
||||
@$(RM) -rv $(SOURCEDIR)/diag_converted/
|
||||
@$(RM) -rv $(SOURCEDIR)/plain_svg/
|
||||
|
||||
# convert all SVG to plain SVGs without metadata and paths instead of text
|
||||
convert-svg:
|
||||
for file in $(SOURCEDIR)/diag/*.svg; do if [[ ! -f $(SOURCEDIR)/diag_converted/$$(basename $$file) ]]; then $(INKSCAPE) --export-text-to-path --export-plain-svg --export-filename=$(SOURCEDIR)/diag_converted/$$(basename $$file) $$file; fi; done
|
||||
for file in $(SOURCEDIR)/diag/*.svg $(SOURCEDIR)/drawio/*.svg; do if [[ ! -f $(SOURCEDIR)/plain_svg/$$(basename $$file) ]]; then $(INKSCAPE) --export-text-to-path --export-plain-svg --export-filename=$(SOURCEDIR)/plain_svg/$$(basename $$file) $$file; fi; done
|
||||
|
||||
epub: convert-svg
|
||||
@$(SPHINXBUILD) -M epub "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
|
|
@ -41,7 +41,7 @@ For detailed information on KDFs and their role in the OpenPGP protocol, see the
|
|||
|
||||
Participants in symmetric-key operations need to exchange the shared secret over a secure channel.
|
||||
|
||||
```{figure} diag_converted/symmetric_key.svg
|
||||
```{figure} plain_svg/symmetric_key.svg
|
||||
:name: fig-symmetric-key
|
||||
:alt: Depicts a box with a white background and the title "Symmetric key". In the box a single key symbol, rendered with full yellow line, is shown pointing to the right hand side.
|
||||
|
||||
|
@ -94,7 +94,7 @@ Unlike symmetric cryptography, participants are not required to pre-arrange a sh
|
|||
|
||||
Throughout this document, we will frequently reference asymmetric cryptographic key pairs:
|
||||
|
||||
```{figure} diag_converted/asymmetric_keypair.svg
|
||||
```{figure} plain_svg/asymmetric_keypair.svg
|
||||
:name: fig-asymmetric-keypair
|
||||
:alt: Depicts a box with white background and the title "Asymmetric keypair". In the box two key symbols with text next to them are shown. The top key symbol is rendered using full green lines, points to the right hand side and has the accompanying text "Public key". The lower key symbol is rendered using dotted red lines, points to the left hand side and has the accompanying text "Private key".
|
||||
|
||||
|
@ -105,7 +105,7 @@ Each key pair comprises two parts: the {term}`public key<OpenPGP Certificate>` a
|
|||
|
||||
It's important to note that in many scenarios, only the {term}`public key<OpenPGP Certificate>` is exposed or used. These situations will be elaborated upon in subsequent sections of this document.
|
||||
|
||||
```{figure} diag_converted/public_key.svg
|
||||
```{figure} plain_svg/public_key.svg
|
||||
:name: fig-public-key
|
||||
:alt: Depicts a box with white background and the title "Public part of an asymmetric keypair". In the box one key symbol with text next to it is shown. The key symbol is rendered using full green lines, points to the right hand side and has the accompanying text "Public key".
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ An {term}`OpenPGP certificate` (or "{term}`OpenPGP key`") is a collection of an
|
|||
|
||||
This documentation collectively refers to {term}`component keys<OpenPGP Component Key>` and {term}`identity components<Identity Component>` as "the {term}`components<Component>` of a {term}`certificate<OpenPGP Certificate>`."
|
||||
|
||||
```{figure} diag_converted/Components_of_an_OpenPGP_Certificate.svg
|
||||
```{figure} plain_svg/Components_of_an_OpenPGP_Certificate.svg
|
||||
:name: fig-openpgp-certificate-components
|
||||
:alt: Depicts a box with white background and the title "OpenPGP certificate". In the box several other boxes and accompanying texts, representing component keys and User IDs, are shown. There are three component keys boxes with a green frame, each with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol in the lower right area. All three have a title, a unique fingerprint below the box and a unique capability keyword, perpendicular to the box on the right side. The top-most component key box has a light-green background, with the title "Component Key (primary)" and capability keyword "certification". The second-to-top component key box has a white background, with the title "Component Key" and capability keyword "encryption". The lowest component key box has a white background, with the title "Component Key" and capability keyword "signing". There are two User ID boxes, each with a black frame, open to top left and lower right corner. Both boxes have a user icon on the top left side, the title "User ID" on the top right side and a User ID string at the bottom. The top box has "Alice Adams <alice@example.org>" and the lower box has "Alice" as User ID string.
|
||||
|
||||
|
@ -71,7 +71,7 @@ An {term}`OpenPGP certificate` usually contains multiple {term}`component keys<O
|
|||
|
||||
[^ecdh-parameters]: For [ECDH](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-part-for-ecd) {term}`component keys<OpenPGP Component Key>`, two additional algorithm parameters are integral to the {term}`component key<OpenPGP Component Key>`'s constitutive and immutable properties. Those parameters specify a hash function and a {term}`symmetric<Symmetric Cryptography>` encryption algorithm.
|
||||
|
||||
```{figure} diag_converted/Component_Key.svg
|
||||
```{figure} plain_svg/Component_Key.svg
|
||||
:name: fig-component-key
|
||||
:alt: Depicts a box with white background and no title. In the box one other box is shown. The inner box has a green frame, with a dotted lower-left section, that shows the text "key creation time" and the green public key symbol, as well as the red-dotted private key symbol in the lower right area. In the top left of the inner box the text reads "Component Key."
|
||||
|
||||
|
@ -85,7 +85,7 @@ An {term}`OpenPGP component key`
|
|||
|
||||
Each {term}`OpenPGP component key` possesses an *{term}`OpenPGP fingerprint`*. This {term}`fingerprint<OpenPGP Fingerprint>` is derived from the {term}`public key material<OpenPGP Certificate>`, the {term}`creation timestamp<Creation Time>`, and, when relevant, the ECDH parameters.
|
||||
|
||||
```{figure} diag_converted/Fingerprint.svg
|
||||
```{figure} plain_svg/Fingerprint.svg
|
||||
:name: fig-fingerprint
|
||||
:alt: Depicts a box with white background and the title "Fingerprint of an OpenPGP component key." Inside, another box with a green frame, the title "Component Key", the text "key creation time" on the lower left and a the green public key symbol on the lower right is shown. Below the component key box a fingerprint in a box with a light-yellow background and a yellow dotted line is depicted. The word "Fingerprint" is shown left of the box with the fingerprint and both are connected with a yellow dotted line.
|
||||
|
||||
|
@ -125,7 +125,7 @@ Modern {term}`OpenPGP certificates<OpenPGP Certificate>` typically include sever
|
|||
|
||||
While {term}`subkeys<OpenPGP Subkey>` have the same structural attributes as the {term}`primary key<OpenPGP Primary Key>`, they fulfill different roles. {term}`Subkeys<OpenPGP Subkey>` are cryptographically linked with the {term}`primary key<OpenPGP Primary Key>`, a relationship further discussed in {numref}`binding_subkeys`.
|
||||
|
||||
```{figure} diag_converted/Binding_Subkeys.svg
|
||||
```{figure} plain_svg/Binding_Subkeys.svg
|
||||
:name: fig-subkeys
|
||||
:alt: Diagram depicting three component keys. The primary key is positioned at the top, designated for certification. Below it, connected by arrows, are two subkeys labeled as "for encryption" and "for signing," respectively.
|
||||
|
||||
|
@ -142,7 +142,7 @@ While {term}`subkeys<OpenPGP Subkey>` have the same structural attributes as the
|
|||
|
||||
{term}`OpenPGP certificates<OpenPGP Certificate>` can contain multiple [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#uid). Each {term}`User ID` associates the {term}`certificate<OpenPGP Certificate>` with an {term}`identity`.
|
||||
|
||||
```{figure} diag_converted/Binding_a_UserID.svg
|
||||
```{figure} plain_svg/Binding_a_UserID.svg
|
||||
:name: fig-user-ids
|
||||
:alt: Depicts a diagram with white background and the title "User IDs". Inside, a public primary component key for certification and a User ID is shown. A green arrow points from component key to User ID and is annotated with a signature.
|
||||
|
||||
|
@ -205,7 +205,7 @@ Key attributes, such as {term}`capabilities<Capability>` (like *signing* or *enc
|
|||
|
||||
It is crucial to note that the {term}`components<Component>` of an {term}`OpenPGP certificate` remain static after their creation. The use of {term}`signatures<OpenPGP Signature Packet>` to store {term}`metadata` allows for subsequent modifications without altering the original {term}`component<Component>`. For instance, a {term}`certificate holder` can update the {term}`expiration time` of a {term}`component` by issuing a new, superseding {term}`signature<OpenPGP Signature Packet>`.
|
||||
|
||||
```{figure} diag_converted/Primary_key_metadata.svg
|
||||
```{figure} plain_svg/Primary_key_metadata.svg
|
||||
:name: fig-primary-metadata
|
||||
:alt: Depicts a direct key signature, associated with a primary component key.
|
||||
|
||||
|
@ -263,7 +263,7 @@ Additionally, OpenPGP allows modeling {term}`User ID`-specific preferences. The
|
|||
|
||||
Following our review of how {term}`keys<Component Key>` and {term}`identity components<Identity Component>` are linked, let's reexamine the {term}`OpenPGP certificate` from {numref}`fig-openpgp-certificate-components`. Our focus now extends to all of its binding signatures and the {term}`direct key signature` that contains {term}`metadata` for the full {term}`certificate<OpenPGP certificate>`:
|
||||
|
||||
```{figure} diag_converted/OpenPGP_Certificate.svg
|
||||
```{figure} plain_svg/OpenPGP_Certificate.svg
|
||||
:name: fig-openpgp-certificate
|
||||
:alt: Depicts an OpenPGP certificate, including a set of components, binding signatures, and a direct key signature on the primary key.
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ This chapter focuses on the corresponding counterpart to the elements of certifi
|
|||
|
||||
In this documentation, we treat the private key material as logically separate from the OpenPGP certificate. Operations that use private key material are typically managed by a separate subsystem. It is useful to view OpenPGP certificates and the associated private key material as related but distinct elements[^pkcs11]:
|
||||
|
||||
```{figure} diag_converted/OpenPGPCert_with_privatekeystore.svg
|
||||
```{figure} plain_svg/OpenPGPCert_with_privatekeystore.svg
|
||||
:name: fig-openpgp-certificate-with-private-key-store
|
||||
:alt: A diagram on a white background showing an OpenPGP certificate and a private keystore. Gray dotted lines connect the green public key symbols of the OpenPGP certificate to red dotted private key symbols in the private keystore.
|
||||
|
||||
|
@ -36,7 +36,7 @@ In certain cases, an exception arises where the cryptographic private key materi
|
|||
|
||||
Sometimes it is useful to handle OpenPGP certificates combined with private key material in the form of a [*transferable secret key (TSK)*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-transferable-secret-keys). A TSK is a serialized format that combines OpenPGP certificate data with its connected private key material, stored in a single file.
|
||||
|
||||
```{figure} diag_converted/TSK.svg
|
||||
```{figure} plain_svg/TSK.svg
|
||||
:name: fig-transferable-secret-key
|
||||
:alt: A box on a white background titled "transferable secret key." It resembles the figure depicting an OpenPGP certificate, except that in each component key box, below the green public key symbol, the red-dotted private key symbol is also shown.
|
||||
|
||||
|
@ -68,7 +68,7 @@ When protecting private key material in OpenPGP, a symmetric key is derived from
|
|||
|
||||
To facilitate this, the OpenPGP standard defines a set of mechanisms known as [string-to-key (S2K)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-string-to-key-s2k-specifier). S2K mechanisms are used to generate high-entropy symmetric encryption keys from lower-entropy passphrases, using a [key derivation function (KDF)](https://en.wikipedia.org/wiki/Key_derivation_function).
|
||||
|
||||
```{figure} diag_converted/passphrase_using_S2K.svg
|
||||
```{figure} plain_svg/passphrase_using_S2K.svg
|
||||
:name: fig-passphrase-using-s2k
|
||||
:alt: A diagram on a white background titled "Converting a passphrase into a symmetric key." On the left is a light-yellow box with dotted-yellow borders framing the phrase "correct horse battery staple." A dotted yellow line falls below the box to the term "passphrase." To the right of the box is a light-green arrow with green-dotted borders and the text "S2K mechanism (string-to-key). The arrow points to its right, where a yellow symmetric key symbol is shown.
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ Within OpenPGP, the term *{term}`signature<OpenPGP Signature Packet>`* can have
|
|||
- **{term}`Cryptographic signature`**: a sequence of bytes created by {term}`cryptographic keys<Cryptographic Key>`, calculated according to a {term}`signature` scheme.
|
||||
- **{term}`OpenPGP signature packets<OpenPGP signature packet>`**: Defined in the [OpenPGP standard](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2), these {term}`packets<Packet>` combine a raw {term}`cryptographic signature` along with a *{term}`type<OpenPGP Signature Type>`* designation and additional {term}`metadata`.
|
||||
|
||||
```{figure} diag_converted/meaning_of_signatures.svg
|
||||
```{figure} plain_svg/meaning_of_signatures.svg
|
||||
:name: fig-meaning-of-signatures
|
||||
:alt: Depicts a box on white background with the title "Meanings of signature in OpenPGP", "signature" in italics. The top half of the box shows a green seal symbol with the word "sig" in it on the left side. The symbol is connected to the text "Cryptographic signature" by a black dotted line. The bottom half of the box shows a diagram. On the left hand side a box with green dotted frame and white background provides the title "Signature type", while inside the box the text reads "Signature over Signature data, Signature metadata". The words "Signature metadata" serve as title for a yellow box at the lower half of the signature type box. The yellow box also contains a cryptographic signature symbol. Right of the signature type box, the text "OpenPGP signature packet" is shown, which is connected to the box by a green dotted line. Below the text a list is shown, which reads "signature type, signature over input data, additional metadata and cryptographic signature". The last item is connected to the cryptographic signature symbol in the yellow box by a black dotted line.
|
||||
|
||||
|
@ -89,7 +89,7 @@ The {term}`signature packet<OpenPGP Signature Packet>` consists of two parts:
|
|||
- A {term}`hash digest` is calculated from the input data.
|
||||
- The {term}`cryptographic signature` is then calculated for this {term}`hash digest`.
|
||||
|
||||
```{figure} diag_converted/Signature_Creation.svg
|
||||
```{figure} plain_svg/Signature_Creation.svg
|
||||
:name: fig-signature-creation
|
||||
:alt: Depicts a complex diagram with white background and the title "Signature creation". On the top left side a box with black frame and white background reads "Input Data packets, One or more packets". Below it the symbol of a signature packet is shown (however, instead of the green signature symbol, only a circle with white background and dotted frame is shown). Both are connected (via green dotted arrows) to a green, right pointing arrow symbol with green dotted frame and the title "Hash mechanism". Text above the green arrow symbol reads "A hash digest is calculated from the input data packets and the signature metadata". The "Hash mechanism" arrow points at a box with white background and green frame, which reads "hash digest". At the top right corner of the diagram the symbol for a component key with both public and private key and the title "Signer private key" is shown. Both hash digest and component key symbol point to a large green arrow symbol, with green dotted frame, at the lower right corner of the diagram, using green dotted arrow lines. The large arrow symbol has the title "Signing mechanism" and text overlaid across it reads "A cryptographic signature is calculated over the hash digest, using the private key material of the signer.". It points at a cryptographic signature symbol at the bottom of the diagram. The cryptographic signature symbol is connected (via a green dotted arrow line) to the circle with white background and dotted green frame in the signature packet symbol.
|
||||
|
||||
|
@ -107,7 +107,7 @@ The main differences:
|
|||
- **Use of {term}`signature verification` mechanism**:
|
||||
After calculating the {term}`hash digest` from the input data, a {term}`signature verification` mechanism is employed. This mechanism uses the {term}`hash digest`, the {term}`cryptographic signature` from the {term}`signature packet<OpenPGP Signature Packet>`, and the {term}`public key<OpenPGP Certificate>` of the {term}`signer`. Its purpose is to ascertain the cryptographic {term}`validity<Validation>` of the {term}`signature<OpenPGP Signature Packet>`.
|
||||
|
||||
```{figure} diag_converted/Signature_Verification.svg
|
||||
```{figure} plain_svg/Signature_Verification.svg
|
||||
:name: fig-signature-verification
|
||||
:alt: Depicts a complex diagram with white background and the title "Signature verification". On the top left side a box with black frame and white background reads "Input Data packets, One or more packets". Below it the symbol of a signature packet is shown. Both are connected (via green dotted arrows) to a green, right pointing arrow symbol with green dotted frame and the title "Hash mechanism". Text above the green arrow symbol reads "A hash digest is calculated from the input data packates and the signature metadata". The "Hash mechanism" arrow points at a box with white background and green frame, which reads "hash digest". At the top right corner of the diagram the symbol for a component key with only public key and the title "Signer public key" is shown. Hash digest, component key symbol and the cryptographic signature symbol in the signature packet point to a large green arrow symbol, with green dotted frame, at the lower right corner of the diagram, using green dotted arrow lines. The large arrow symbol has the title "Signature verification mechanism" and text overlaid across it reads "A cryptographic signature is verified against the hash digest, using the public key of the signer.". It points at a success and fail symbol at the bottom of the diagram.
|
||||
|
||||
|
|
|
@ -94,7 +94,7 @@ A {term}`subkey binding signature` binds a {term}`subkey<OpenPGP Subkey>` to a {
|
|||
|
||||
{term}`Subkeys<OpenPGP Subkey>` designated for signing purposes, identified by the *{term}`signing<Signing Key Flag>`* [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags), represent a unique category and are handled differently. See {numref}`bind_subkey_sign`.
|
||||
|
||||
```{figure} diag_converted/subkey_binding_signature.svg
|
||||
```{figure} plain_svg/subkey_binding_signature.svg
|
||||
:name: fig-subkey-binding-signature
|
||||
:alt: Depicts a diagram on white background with the title "Subkey binding signature". At the top left the symbol of a primary component key with certification capability is shown. At the bottom left the symbol of a component key with encryption capability is shown. The primary component key points at the lower component key with a full green arrow line. In the middle of the connection the small symbol of a signature packet is shown. On the right side of the diagram a detailed version of the signature packet can be found in a box with the title "Subkey binding signature". The text reads "Signature over Primary key, Subkey" and the box with "Signature metadata" contains the list "signature creation time", "key expiration time", "key flags" and "issuer fingerprint". The primary component key points at the detailed signature packet with a dotted green arrow line and the text "Primary key creates a subkey binding signature to bind the subkey to the primary key".
|
||||
|
||||
|
@ -123,7 +123,7 @@ To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's
|
|||
- the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-subkey-binding) ({term}`type ID<Signature Type ID>` `0x18`), which is issued by the {term}`certificate<OpenPGP Certificate>`'s {term}`primary key<OpenPGP Primary Key>`
|
||||
- the [primary key binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding) ({term}`type ID<Signature Type ID>` `0x19`), created by the {term}`subkey<OpenPGP Subkey>` itself. This is informally known as an embedded "{term}`back signature<Primary Key Binding Signature>`," because the {term}`subkey<OpenPGP Subkey>`'s {term}`signature<OpenPGP Signature Packet>` points back to the {term}`primary key<OpenPGP Primary Key>`.
|
||||
|
||||
```{figure} diag_converted/subkey_binding_signatur_for_signing_sk.svg
|
||||
```{figure} plain_svg/subkey_binding_signatur_for_signing_sk.svg
|
||||
:name: fig-subkey-binding-signature-for-signing-subkeys
|
||||
:alt: Depicts a diagram on white background with the title "Subkey binding signature for signing subkeys". At the top left the symbol of a primary component key with certification capability is shown. At the bottom left the symbol of a component key with signing capability is shown. The primary component key points at the lower component key with a full green arrow line. In the middle of the connection the small symbol of a signature packet is shown. On the right side of the diagram a detailed version of the signature packet can be found in a box with the title "Subkey binding signature". The text reads "Signature over Primary key, Subkey" and the box with "Signature metadata" in it contains the list "signature creation time", "key expiration time", "key flags" and "issuer fingerprint". Within the signature metadata a box with a green dotted frame extends the list with an inlined signature packet with the title "Embedded Signature; Primary key binding". Its inner text reads "Signature over Primary Key, Signing Subkey". The signature metadata area of this embedded signature holds the list "signature creation time" and "issuer fingerprint". The cryptographic signature symbol overlaps both metadata and general section of the embedded signature. From the signing component key a green dotted arrow line points to the embedded signature in the subkey binding signature with the text "Signing key creates a primary binding signature to associate itself with the primary key" ("primary binding signature" in bold). At the top of the diagram, the primary component key points at the detailed signature packet with a dotted green arrow line and the text "Primary key creates a subkey binding signature to bind the subkey to the primary key".
|
||||
|
||||
|
@ -143,7 +143,7 @@ There are four types of *{term}`certifying self-signature`*. The most commonly u
|
|||
|
||||
The {term}`certifying self-signature` {term}`packet` – calculated over the {term}`primary key<OpenPGP Primary Key>`, {term}`User ID`, and {term}`metadata` of the {term}`signature packet<OpenPGP Signature Packet>` – is added to the {term}`certificate<OpenPGP Certificate>`, directly following the {term}`User ID` {term}`packet`.
|
||||
|
||||
```{figure} diag_converted/user_id_certification.svg
|
||||
```{figure} plain_svg/user_id_certification.svg
|
||||
:name: fig-user-id-certification
|
||||
:alt: Depicts a diagram on white background with the title "User ID binding signature". At the top left the symbol of a primary component key with certification capability is shown. At the bottom left the symbol of a User ID reads "Alice Adams <alice@example.org>". The primary component key points at the User ID with a full green arrow line. In the middle of the connection the small symbol of a signature packet is shown. On the right side of the diagram a detailed version of the signature packet can be found in a box with the title "User ID binding signature". The text reads "Signature over Primary key, User ID" and the box with "Signature metadata" in it contains the list "signature creation time", "key expiration time", "primary User ID flag", "algorithm preferences", "key expiration time (primary key)" and "key flags (primary key)". At the top of the diagram, the primary component key points at the detailed signature packet with a dotted green arrow line and the text "Primary key creates a User ID binding signature to associate the User ID with the primary key".
|
||||
|
||||
|
|
|
@ -117,7 +117,7 @@ In this version of the SEIPD packet, the session key is used directly as message
|
|||
|
||||
When communicating with a mix of recipients, some of whose OpenPGP software only supports OpenPGP version 4, then this mechanism must be used.
|
||||
|
||||
```{figure} drawio/SEIPDv1-PKESK.svg
|
||||
```{figure} plain_svg/SEIPDv1-PKESK.svg
|
||||
:name: fig-encryption-seipdv1-pkesk
|
||||
:alt: Depicts a dotted hexagon labeled "Plaintext", from which a curved arrow passes another dotted hexagon "Session Key" and finally points to a "SEIPDv1" packet. Two more curved arrows originate from the session key and pass Alice' and Bob's encryption key, ending in two PKESK packets.
|
||||
|
||||
|
@ -137,7 +137,7 @@ In version 2 SEIPD, the *session key* is transformed into a *message key*, based
|
|||
The session key can use a different symmetric algorithm than the message key.
|
||||
```
|
||||
|
||||
```{figure} drawio/SEIPDv2-PKESK.svg
|
||||
```{figure} plain_svg/SEIPDv2-PKESK.svg
|
||||
:name: fig-encryption-seipdv2-pkesk
|
||||
:alt: TODO
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ Here, the result of the S2K function is a symmetric key, which is either used to
|
|||
The "direct method" where the result of the S2K function is directly used as session key is only applicable if only one SKESK packet is present.
|
||||
```
|
||||
|
||||
```{figure} drawio/SKESKv4-decryption.svg
|
||||
```{figure} plain_svg/SKESKv4-decryption.svg
|
||||
:name: fig-skeskv4-decryption
|
||||
:alt: Diagram depicting how the S2K function is used to derive key symmetric key from the user-provided passphrase. This key is then either used directly as session key, or used to decrypt the encrypted session key.
|
||||
|
||||
|
@ -79,7 +79,7 @@ The *AEAD Auth Tag* of the SKESK packet is used as authentication tag.
|
|||
|
||||
The result is the *session key*.
|
||||
|
||||
```{figure} drawio/SKESKv6-decryption.svg
|
||||
```{figure} plain_svg/SKESKv6-decryption.svg
|
||||
:name: fig-skeskv6-decryption
|
||||
:alt: Diagram depicting the complicated process of deriving the session key from a SKESK version 6 packet.
|
||||
|
||||
|
@ -103,7 +103,7 @@ To detect, which symmetric cipher is used to decrypt the SEIPDv1 packet later on
|
|||
[^x25519-spec]: [Algorithm-Specific Fields for X25519 encryption](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-fields-for-)
|
||||
[^x448-spec]: [Algorithm-Specific Fields for X448 encryption](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-algorithm-specific-fields-for-x)
|
||||
|
||||
```{figure} drawio/PKESKv3-decryption.svg
|
||||
```{figure} plain_svg/PKESKv3-decryption.svg
|
||||
:name: fig-decryption-pkesk3
|
||||
:alt: Depicts, how the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session key.
|
||||
|
||||
|
@ -114,7 +114,7 @@ Decrypting the session key from a version 3 PKESK packet.
|
|||
|
||||
The decryption of version 6 PKESK packets works quite similarly to version 3.
|
||||
|
||||
```{figure} drawio/PKESKv6-decryption.svg
|
||||
```{figure} plain_svg/PKESKv6-decryption.svg
|
||||
:name: fig-decryption-pkesk6
|
||||
:alt: Depicts, how the secret-key component of the users encryption subkey is directly used to decrypt the encrypted session key.
|
||||
|
||||
|
@ -144,7 +144,7 @@ Once the cipher is initialized, the whole encrypted data from the SEIPD packet i
|
|||
Describe the MDC which is used for modification detection.
|
||||
```
|
||||
|
||||
```{figure} drawio/SEIPDv1-decryption.svg
|
||||
```{figure} plain_svg/SEIPDv1-decryption.svg
|
||||
:name: fig-decryption-seipd1
|
||||
:alt: Depicts how the session key is used directly to decrypt the contents of the SEIPD packet.
|
||||
|
||||
|
@ -162,7 +162,7 @@ Once the session key was obtained from a PKESK or SKESK, it is used to derive a
|
|||
|
||||
The result is split into the message key and first half of the IV.
|
||||
|
||||
```{figure} drawio/SEIPDv2-decryption-mk-derivation.svg
|
||||
```{figure} plain_svg/SEIPDv2-decryption-mk-derivation.svg
|
||||
:name: fig-decryption-seipd2-mk-derivation
|
||||
:alt: Depicts how the session key is fed into a salted HKDF to derive both the message key and the first half of an IV.
|
||||
|
||||
|
@ -176,7 +176,7 @@ All decrypted plaintext blocks are appended to form the result of the decryption
|
|||
|
||||
After all blocks have been processed, in a final AEAD step, the total number of plaintext octets gets appended to the *additional data* and the final AEAD auth tag from the SEIPD packet is processed.
|
||||
|
||||
```{figure} drawio/SEIPDv2-decryption-chunks.svg
|
||||
```{figure} plain_svg/SEIPDv2-decryption-chunks.svg
|
||||
:name: fig-decryption-seipd2-chunks
|
||||
:alt: Depicts, how the message key and index-postfixed IV are used to decrypt each individual chunk of plaintext.
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ alice.pub-9--Signature
|
|||
```
|
||||
|
||||
|
||||
```{figure} diag_converted/certificate_packet_list.svg
|
||||
```{figure} plain_svg/certificate_packet_list.svg
|
||||
:name: fig-certificate-packet-list
|
||||
:alt: Depicts a box with white background and the title "Certificate packet list". Inside, a list of several boxes on white background and varying frame colors represent a list of OpenPGP packets from top to bottom. The first box, with green frame, represents the "Public-Key packet", and includes the green public key symbol. The second box, with yellow frame, represents a "Signature packet" ("Direct Key Signature") and includes the green cryptographic signature symbol. The third box, with black frame, represents a "User ID packet", and includes the black User ID symbol. The fourth box, with yellow frame, represents a "Signature packet" ("Certifying self-signature for User ID"), and includes the green cryptographic signature symbol. The fifth box, with green frame, represents a "Public-Subkey packet" and includes the green public key symbol. The sixth box, with yellow frame, represents a "Signature packet" ("Subkey binding signature") and includes the green cryptographic signature symbol. The seventh box, with green frame, represents a "Public-Subkey packet" and includes the green public key symbol. The eighth box, with yellow frame, represents a "Signature packet" ("Subkey binding signature") and includes the green cryptographic signature symbol. The ninth box, with green frame, represents a "Public-Subkey packet" and includes the green public key symbol. The tenth box, with yellow frame, represents a "Signature packet" ("Subkey binding signature") and includes the green cryptographic signature symbol.
|
||||
|
||||
|
@ -77,7 +77,7 @@ This version of Alice's certificate contains just two packets:
|
|||
|
||||
This is the shape of the packets we'll explore in the subsequent sections:
|
||||
|
||||
```{figure} diag_converted/Minimal_OpenPGP_certificate.svg
|
||||
```{figure} plain_svg/Minimal_OpenPGP_certificate.svg
|
||||
:name: fig-public-certificate-minimal
|
||||
:alt: TODO
|
||||
|
||||
|
@ -173,7 +173,7 @@ The packet type ID ("6") defines the semantics of the following data within the
|
|||
|
||||
Note that the *Public-Key packet* contains only the public part of the key.
|
||||
|
||||
```{figure} diag_converted/public-key_packet.svg
|
||||
```{figure} plain_svg/public-key_packet.svg
|
||||
:name: fig-public-key-packet
|
||||
:alt: Depicts a box with white background and title "Public-Key packet". In the center a box with white background and green frame is shown. Inside it several items are listed, separated by green dotted horizontal lines. The first three are "Version", "Creation Time", "Public-Key Algorithm" written in black. The last one is written in green and reads "Public Key Material" and has the green public key symbol at its right side.
|
||||
|
||||
|
@ -365,7 +365,7 @@ The hash digest is calculated from the following data (see [Computing Signatures
|
|||
|
||||
The signature is calculated from this hash digest.
|
||||
|
||||
```{figure} diag_converted/direct_key_signature_packet.svg
|
||||
```{figure} plain_svg/direct_key_signature_packet.svg
|
||||
:name: fig-direct-key-signature-packet
|
||||
:alt: Depicts a box with white background, title "Signature packet" and subtitle "Direct Key Signature (type ID 0x1F)". In the center a box with white background and yellow frame is shown. Inside it several items are listed, separated by yellow dotted horizontal lines. The first three are "Version", "Public-Key Algorithm" and "Hash Algorithm". The fourth item is called "Hashed area" and confines further sub-items by a light-yellow frame on the top and left side. The sub-items are "Signature Creation Time", "Key Expiration Time", "Preferred Symmetric Ciphers for v1 SEIPD", "Preferred Hash Algorithms", "Key Flags", "Features" and "Issuer Fingerprint". The fifth item is named "Unhashed area" and again introduces an area for sub-items, this time using a light-gray border on the top and left side. The unhashed area has no sub-items though. The last item is called "Cryptographic Signature", with the subtitle "by the primary key over primary key, subkey and signature metadata" and includes the green cryptographic signature symbol on the right side.
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ The output starts with the (primary) [Secret-Key packet](https://www.ietf.org/ar
|
|||
|
||||
This is the structure of the Secret-Key packet we will now look at.
|
||||
|
||||
```{figure} diag_converted/secret-key_packet.svg
|
||||
```{figure} plain_svg/secret-key_packet.svg
|
||||
:name: fig-secret-key-packet
|
||||
:alt: Depicts a box with white background and title "Secret-Key packet". In the center a box with white background and red frame is shown. Inside it several items are listed, separated by red dotted horizontal lines. The first three are "Version", "Creation Time", "Public-Key Algorithm" written in black. The fourth one is written in green and reads "Public Key Material" and has the green public key symbol at its right side. The fifth one is again written in black and reads "S2K Usage (Secret Key Encryption)". The sixth item reads "Secret Key Material", written in red and has the red private key symbol at its right side.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue