Encrypt-Decrypt roundtrip with minimal key from Appendix A.3 of RFC9580.

Encrypt-Decrypt roundtrip with multiple keys: the message is encrypted with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00; and decrypted using the key from RFC9580 only.

Encrypt-Decrypt roundtrip with multiple keys: the message is encrypted with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00; and decrypted using the 'Alice' key only.

Encrypt-Decrypt roundtrip using the 'Alice' key from draft-bre-openpgp-samples-00.

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00.

Encrypt-Decrypt roundtrip using the 'Carol' key from draft-bre-openpgp-samples-00.

Encrypt-Decrypt roundtrip using the v3 'John' key.

Encrypt-Decrypt roundtrip using the v5 'Emma' key.

Encrypt-Decrypt roundtrip with the v6 Ed25519 key with an MLKEM768+X25519 subkey from Appendix A.1 of RFC9980.

Encrypt-Decrypt roundtrip with a v6 Ed25519 key with X25519 and MLKEM768+X25519 subkeys. I.e. this cert is PQC-ready but should still be usable by implementations that don't support MLKEM768+X25519.

Encrypt-Decrypt roundtrip with the v4 Ed25519 key with an MLKEM768+X25519 subkey from Appendix A.2 of RFC9980.

Encrypt-Decrypt roundtrip with a v4 Ed25519 key with X25519 and MLKEM768+X25519 subkeys. I.e. this cert is PQC-ready but should still be usable by implementations that don't support MLKEM768+X25519.

Encrypt-Decrypt roundtrip with a v4 EdDSA key with ECDH and MLKEM768+X25519 subkeys. I.e. this cert is PQC-ready but should still be usable by implementations that don't support MLKEM768+X25519.

Encrypt-Decrypt roundtrip with the v6 ML-DSA-65+Ed25519 key with an ML-KEM-768+X25519 subkey from Appendix A.3 of RFC9980.

Encrypt-Decrypt roundtrip with the v6 ML-DSA-87+Ed448 key with an ML-KEM-1024+X448 subkey from Appendix A.4 of RFC9980.

Encrypt-Decrypt roundtrip with the v6 SLH-DSA-SHAKE-128s key with an ML-KEM-768+X25519 subkey from Appendix A.5 of RFC9980.

Encrypt-Decrypt roundtrip with the v6 SLH-DSA-SHAKE-128f key with an ML-KEM-768+X25519 subkey from Appendix A.6 of RFC9980.

Encrypt-Decrypt roundtrip with the v6 SLH-DSA-SHAKE-256s key with an ML-KEM-1024+X448 subkey from Appendix A.7 of RFC9980.

Encrypt-Decrypt roundtrip using the persistent symmetric key from Appendix A.1 of draft-ietf-openpgp-persistent-symmetric-keys.

Tests decryption support for PQC algorithms using the test vectors from Appendix 1 through 5 of RFC9980.

Tests variations of recipient ids.

RSA ciphertext can vary in size. This creates an opportunity for mishandling of buffers, e.g. CVE-2021-3580.

RSA keys can differ wildly in size. This test checks which ones are accepted by different implementations, from way too small to way too big, including some odd sizes.

This tests support for the consumption (i.e. decryption) of different symmetric encryption algorithms using Sequoia to generate the artifacts.

This tests support for the consumption (i.e. decryption) of different symmetric encryption algorithms using Sequoia to generate the artifacts.

This tests support for the consumption (i.e. decryption) of different symmetric encryption algorithms using Sequoia to generate the artifacts.

This tests support for the consumption (i.e. decryption) of different symmetric encryption algorithms using Sequoia to generate the artifacts.

This tests support for the production (i.e. encryption) of different symmetric encryption algorithms. To that end, the preferred symmetric algorithms are set to only include the algorithm to be tested, and the features subpacket is set to [SEIPDv1].

This tests support for the production (i.e. encryption) of different symmetric encryption algorithms. To that end, the preferred AEAD ciphersuites are set to only include the algorithms to be tested, and the features subpacket is set to [SEIPDv2].

This tests support for the production (i.e. encryption) of different symmetric encryption algorithms. To that end, the preferred AEAD ciphersuites are set to only include the algorithms to be tested, and the features subpacket is set to [SEIPDv2].

This tests support for the production (i.e. encryption) of different symmetric encryption algorithms. To that end, the preferred AEAD ciphersuites are set to only include the algorithms to be tested, and the features subpacket is set to [SEIPDv2].

This tests support for the production (i.e. encryption) of different symmetric encryption algorithms. To that end, the preferred symmetric and AEAD algorithm preferences are set to only include the algorithms to be tested, and the features subpacket is set to [AEAD].

This tests support for the production (i.e. encryption) of different symmetric encryption algorithms. To that end, the preferred symmetric and AEAD algorithm preferences are set to only include the algorithms to be tested, and the features subpacket is set to [AEAD].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [IDEA], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [TripleDES], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [CAST5], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [Blowfish], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [AES128], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [AES192], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [AES256], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [Twofish], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [Camellia128], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [Camellia192], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [Camellia256], and features subpacket [SEIPDv1].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the AEAD ciphersuite algorithm preference [AES128-EAX], and features subpacket [SEIPDv2].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the AEAD ciphersuite algorithm preference [AES128-OCB], and features subpacket [SEIPDv2].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the AEAD ciphersuite algorithm preference [AES128-GCM], and features subpacket [SEIPDv2].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [AES128], AEAD algorithm preference [EAX], and features subpacket [AEAD].

Encrypt-Decrypt roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the symmetric algorithm preference [AES128], AEAD algorithm preference [OCB], and features subpacket [AEAD].

Encrypts a message using the password "password", and tries to decrypt it.

Tests support for S2K mechanisms in the context of symmetrically encrypted messages. Encrypts a message using the password "password" using different S2K mechanisms, and tries to decrypt it.

Tests support for Argon2 in the context of symmetrically encrypted messages. These are the test vectors from Appendix A.8 of RFC9580. The plaintext is "Hello, world!". The password is "password".

This tests support for the Symmetrically Encrypted Integrity Protected Data Packet (Tag 18) and verifies that modifications to the ciphertext are detected. To avoid creating a decryption oracle, implementations must respond with a uniform error message to tampering.

Tests support for SKESKv6 and SEIPDv2. These are the test vectors from Appendix A.9 through A.11 of RFC9580. The plaintext is "Hello, world!". The password is "password".

Tests support for SED (i.e. packet type 9), not integrity protected encrypted messages. To protect SEIPDv1 messages, which may be downgraded to SED messages, these MUST NOT be decrypted.

Tests support for decrypting keys using various encryption methods. Tries to decrypt a message using an encrypted key. All keys are encrypted using AES256, except for the LegacyCFB keys, which are encrypted using AES128. The password is "password" for all keys.

Detached Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580.

Detached Sign-Verify roundtrip test with multiple keys: the data is signed with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00, then verified using the key from RFC9580

Detached Sign-Verify roundtrip test with multiple keys: the data is signed with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00, then verified using the key 'Alice'.

Detached Sign-Verify roundtrip using the 'Alice' key from draft-bre-openpgp-samples-00.

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00.

Detached Sign-Verify roundtrip using both the 'Alice' and the 'Bob' key from draft-bre-openpgp-samples-00.

Detached Sign-Verify roundtrip using the 'Carol' key from draft-bre-openpgp-samples-00.

This is an OpenPGP v3 key.

Detached Sign-Verify roundtrip using the persistent symmetric key from Appendix A.1 of draft-ietf-openpgp-persistent-symmetric-keys.

Detached Sign-Verify roundtrip with v6 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.1 of RFC9980.

Detached Sign-Verify roundtrip with v4 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.2 of RFC9980.

Detached Sign-Verify roundtrip with v6 ML-DSA-65+Ed25519/ML-KEM-768+X25519 key from Appendix A.3 of RFC9980.

Detached Sign-Verify roundtrip with v6 ML-DSA-87+Ed448/ML-KEM-768+X25519 key from Appendix A.4 of RFC9980.

Detached Sign-Verify roundtrip with v6 SLH-DSA-128s/ML-KEM-768+X25519 key from Appendix A.5 of RFC9980.

Detached Sign-Verify roundtrip with v6 SLH-DSA-128f/ML-KEM-768+X25519 key from Appendix A.6 of RFC9980.

Detached Sign-Verify roundtrip with v6 SLH-DSA-256s/ML-KEM-1024+X448 key from Appendix A.7 of RFC9980.

Tests verification support for PQC algorithms using the test vectors from Appendix 3 through 7 of RFC9980.

Tests how implementations constrain the validity of signatures depending on the given subpackets. The test signs the message "Hello World :)".

Tests how implementations normalize line breaks when verifying text signatures. Section 5.2.1 of RFC4880 says: The signature is calculated over the text data with its line endings converted to <CR><LF>.

This test creates two signatures, a binary and a text signature, over the message one\r\ntwo\r\nthree, and checks whether variants of the message with different line endings can be verified using these signatures.

Tests how implementations normalize line breaks when verifying text signatures. Section 5.2.1.2 of RFC9580 says: The signature is calculated over the text data with its line endings converted to <CR><LF>.

This test creates a text signature, over the message \r\na\r\nb\r\nc\r\n\r\nd \r\ne\t\r\nf\t\r\nd\r\n, and checks whether variants of the message with different line endings can be verified.

This tests whether detached signatures with unknown versions of Signature packets are still verified. This is important for the evolution of the message format.

Explores whether implementations properly handle improbably short RSA signatures. RSA signatures are of the same size as the signing key's modulus. However, OpenPGP will strip leading zeros, so we can have "short" signatures with implementations either having to pad the signature again, or omitting RFC 3447's length check.

The signatures are over the string "Hello World :)" made using Bob's key.

Explores whether implementations set the digest prefix correctly. To that end, we ask implementations to make a detached signature and check whether the digest prefix is correct.

Explores whether implementations consider signatures with invalid digest prefixes invalid. There are two checks:

1. We make a detached signature, corrupt the digest prefix, and ask implementations to verify it.
2. We ask implementations to verify a signature using a cert where we corrupted all digest prefixes in the binding signatures.

Inline Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580.

Inline Sign-Verify roundtrip test with multiple keys: the data is signed with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00, then verified using the key from RFC9580

Inline Sign-Verify roundtrip test with multiple keys: the data is signed with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00, then verified using the key from RFC9580

Inline Sign-Verify roundtrip using the 'Alice' key from draft-bre-openpgp-samples-00.

The signature is created using the 'Alice' key from draft-bre-openpgp-samples-00, and the message is encrypted for 'Bob'.

Inline Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00.

The signature is created using the 'Bob' key from draft-bre-openpgp-samples-00, and the message is encrypted for 'Bob'.

Sign-Verify roundtrip using both the 'Alice' and the 'Bob' key from draft-bre-openpgp-samples-00.

The signatures are created using both the 'Alice' and the 'Bob' key from draft-bre-openpgp-samples-00, and the message is encrypted for 'Bob'.

Inline Sign-Verify roundtrip using the 'Carol' key from draft-bre-openpgp-samples-00.

The signature is created using the 'Carol' key from draft-bre-openpgp-samples-00, and the message is encrypted for 'Bob'.

This is an OpenPGP v3 key.

The signature is created using the v3 'John' key, and the message is encrypted for 'Bob'.

This is an OpenPGP v5 key.

The signature is created using the v5 'Emma' key, and the message is encrypted for 'Bob'.

The message is signed using the persistent symmetric key from Appendix A.1 of draft-ietf-openpgp-persistent-symmetric-keys.

Inline Sign-Verify roundtrip with v6 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.1 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v6 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.1 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v6 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.1 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v4 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.2 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v4 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.2 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v4 Ed25519/X25519,ML-KEM-768+X25519 key from Appendix A.2 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v4 EdDSA/ECDH,ML-KEM-768+X25519 key from Appendix A.3 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v4 EdDSA/ECDH,ML-KEM-768+X25519 key from Appendix A.3 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v4 EdDSA/ECDH,ML-KEM-768+X25519 key from Appendix A.3 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v6 ML-DSA-65+Ed25519/ML-KEM-768+X25519 key from Appendix A.4 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v6 ML-DSA-65+Ed25519/ML-KEM-768+X25519 key from Appendix A.4 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v6 ML-DSA-65+Ed25519/ML-KEM-768+X25519 key from Appendix A.4 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v6 ML-DSA-87+Ed448/ML-KEM-1024+X448 key from Appendix A.5 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v6 ML-DSA-87+Ed448/ML-KEM-1024+X448 key from Appendix A.5 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v6 ML-DSA-87+Ed448/ML-KEM-1024+X448 key from Appendix A.5 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v6 SLH-DSA-128s/ML-KEM-768+X25519 key from Appendix A.6 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v6 SLH-DSA-128s/ML-KEM-768+X25519 key from Appendix A.6 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v6 SLH-DSA-128s/ML-KEM-768+X25519 key from Appendix A.6 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v6 SLH-DSA-128f/ML-KEM-768+X25519 key from Appendix A.7 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v6 SLH-DSA-128f/ML-KEM-768+X25519 key from Appendix A.7 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v6 SLH-DSA-128f/ML-KEM-768+X25519 key from Appendix A.7 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with v6 SLH-DSA-256s/ML-KEM-1024+X448 key from Appendix A.8 of draft-ietf-openpgp-pqc.

Sign+Encrypt-Decrypt+Verify roundtrip with v6 SLH-DSA-256s/ML-KEM-1024+X448 key from Appendix A.8 of draft-ietf-openpgp-pqc.

Cleartext Signature Sign-Verify roundtrip with v6 SLH-DSA-256s/ML-KEM-1024+X448 key from Appendix A.8 of draft-ietf-openpgp-pqc.

Inline Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580.

Inline Sign-Verify roundtrip test with multiple keys: the data is signed with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00, then verified using the key from RFC9580

Inline Sign-Verify roundtrip test with multiple keys: the data is signed with the minimal key from Appendix A.3 of RFC9580 and the 'Alice' key from draft-bre-openpgp-samples-00, then verified using the key from RFC9580

Cleartext Signature Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00.

Cleartext Signature Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00. This test uses a particularly problematic text which requires dash-escaping and has trailing newlines.

Cleartext Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580, and a message with CRLF line endings.

Cleartext Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580, and a message with LF line endings.

Cleartext Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580, and a message with mixed line endings.

Cleartext Sign-Verify roundtrip with minimal key from Appendix A.3 of RFC9580, and a message with bare CR characters.

Tests verification (and decryption) support for PQC algorithms using the test vectors from Appendix 3 through 5 of RFC9980.

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [MD5].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [MD5].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA1].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA1].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [RipeMD].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [RipeMD].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA256].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA256].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA384].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA384].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA512].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA512].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA224].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA224].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA3_256].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA3_256].

Detached Sign-Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00, modified with the hash algorithm preference [SHA3_512].

Sign+Encrypt-Decrypt+Verify roundtrip using the 'Bob' key from draft-bre-openpgp-samples-00 as the signer and recipient key, with the recipient key modified with the hash algorithm preference [SHA3_512].

This tests whether detached signatures using SHA-1 over the collision from the paper The first collision for full SHA-1 are considered valid.

The first test establishes a baseline. It is a SHA-1 signature over the text "Hello World :)"

This tests support for the different compression algorithms using Sequoia to generate the artifacts.

This models key generation, distribution, and encrypted message exchange. Generates a key with the producer P, then extracts the certificate from the key and uses it to encrypt a message using the consumer C, and finally the producer P to decrypt the message.

This models key generation, distribution, and encrypted message exchange. Generates a key with the producer P, then extracts the certificate from the key and uses it to encrypt a message using the producer P, and finally the consumer C to decrypt the message.

This models key generation, distribution, and encrypted message exchange. Generates a key with the producer P, then extracts the certificate from the key and uses it to encrypt a message using the consumer C, and finally the producer P to decrypt the message. The key is encrypted with the password "password".

This models key generation, distribution, and encrypted message exchange. Generates a key with the producer P, then extracts the certificate from the key and uses it to encrypt a message using the producer P, and finally the consumer C to decrypt the message. The key is encrypted with the password "password".

This models key generation, distribution, and authenticated message exchange. Generates a key with the producer P, then signs a message using the producer P, then extracts the certificate from the key and uses it to verify the message using the consumer C.

This models key generation, distribution, and authenticated message exchange. Generates a key with the producer P, then signs a message using the consumer C, then extracts the certificate from the key and uses it to verify the message using the producer P.

This models key generation, distribution, and authenticated message exchange. Generates a key with the producer P, then signs a message using the producer P, then extracts the certificate from the key and uses it to verify the message using the consumer C. The key is encrypted with the password "password".

This models key generation, distribution, and authenticated message exchange. Generates a key with the producer P, then signs a message using the consumer C, then extracts the certificate from the key and uses it to verify the message using the producer P. The key is encrypted with the password "password".

This models key generation, distribution, and encrypted message exchange. Generates a key with the producer P, then extracts the certificate from the key and uses it to encrypt a message using the consumer C, and finally the producer P to decrypt the message.

This models key generation, distribution, and encrypted message exchange. Generates a key with the producer P, then extracts the certificate from the key and uses it to encrypt a message using the consumer C, and finally the producer P to decrypt the message.

OpenPGP has two kinds of key usage flags that cover encryption: 0x04 - This key may be used to encrypt communications. 0x08 - This key may be used to encrypt storage. This tests how implementation interpret these flags.This test uses two encryption subkeys, A (7C2FAA4DF93C37B2) and B (63E963F226FB07E7).

This tests various ways of specifying the primary key's flags. Key flags can be provided using direct key signatures, as well as binding signatures on userids.

Notation: p[flags-on-direct-key-sig] u[flags-on-uid-binding] s[flags-on-binding], where CSEA refer to certification, signing, encryption, and authentication capabilities, and 0 refers to an explicit empty set (the subpacket is present, but empty). The key is then used to do an encrypt-decrypt roundtrip.

A subkey binding signature indicating signing capabilities must carry an embedded primary key signature from the subkey over the primary key. This tests whether implementations pay attention to that signature.

The signature is over the string "Hello World :)".

Explores how key flags sets are looked up and composed. Key flags are stored in key flags subpackets on subkey binding signatures and direct key signatures. Furthermore, there could be more than one of such subpackets on a signature. This test explores whether key flags subpackets on direct key signatures are honored, and if multiple subpackets are given, what their precedence relation is, and how they are composed (e.g. is a union or intersection computed, or first or last subpacket wins, etc.), and whether a default value is used if the subpacket is not present (e.g., GnuPG appears to default to CSEA).

The notation used in the rows is as follows. First, a letter identifies a certificate component: p for primary key, u for userid, and s for subkey. Each component is followed by any number of key flag sets, enclosed in square brackets. The letters CSEA refer to certification, signing, encryption, and authentication capabilities. For example, p u[C] s[S] denotes a certificate with the primary key capable of certification, and the sole subkey capable of signing. This is the base case. A test like p u[C] s[][S] explores how an empty flag set followed by one denoting signing capabilities is handled.

The signature is over the string "Hello World :)".

Explores how robust the certificate canonicalization is to perturbations and permutations. While these certificates may not strictly adhere to the structure outlined in Section 12.1 of RFC4880, handling them gracefully improves the user experience.

Notation: Primary key, UserID, UserID Binding, Subkey, Subkey Binding, Marker, U*nbound UserID, unbound S*ubkey, Bad signature, Odd signature, Odd signature with subpacket type99, Odd signature with critical subpacket type99, Subkey version23, Subkey Binding version23, Xtremely unknown packet type, Xtremely unknown Critical packet type.

Explores how certificate expiration time is computed. Certificate expiration is implemented by expiring the primary key. Key expiration time subpackets can be stored on direct key signatures and binding signatures of the primary user id.

The test modifies the 'Bob' certificate so that it expires, then tries to encrypt and decrypt a message with it. Notation: P X U Y [U' Z] where Primary key, primary UserID, secondary U'serID, and X representing key expiration time subpackets on a direct key signature, Y on the primary userid binding signature, and Z on the secondary userid binding signature. For the expiration, f means expiration in the future, p means expiration in the past, 0 is the value 0, which means it should not expire, and - means there is no subpacket.

Explores how transferable secret keys where the secret key material of a component key has been stripped/omitted are handled by the implementations. There are two ways to do that.

The first way is to simply use a public key packet, as suggested by RFC9580.

The second way is to encode the stripped key using a secret key packet and a stub encrypted secret key part. This method is used by GnuPG and some other implementations prior to RFC9580.

The test creates a v6 OpenPGP key with a signing-capable subkey, strips the secret key of either the primary key or the subkey, and tries to create a signature with the resulting key structure. The signature is over the string "Hello World :)".

Explores how transferable secret keys where the secret key material of a component key has been stripped/omitted are handled by the implementations. There are two ways to do that.

The first way is to simply use a public key packet, as suggested by RFC9580.

The second way is to encode the stripped key using a secret key packet and a stub encrypted secret key part. This method is used by GnuPG and some other implementations prior to RFC9580.

The test creates a v4 OpenPGP key with a signing-capable subkey, strips the secret key of either the primary key or the subkey, and tries to create a signature with the resulting key structure. The signature is over the string "Hello World :)".

Explores how subpackets on binding signatures are handled.

The test creates variations of OpenPGP certs with a signing-capable subkey, and tries to verify a signature with it. The certificate has a signing-capable subkey, and the subkey's binding signature (SKB) as well as the embedded primary key binding signature (PKB) are modified. The signature is over the string "Hello World :)".

Explores a certificate corner case where a certificate includes its primary key as subkey. This is an oddball, supporting it is not necessary.

A certificate is constructed by taking Bob's subkey and using it as primary key as well as subkey. The test encrypts a short message, and tries to decrypt is using Bob's key.

This test uses a certificate with a signing capable primary key that is evolving over time. The certificate is constructed so that it is valid for a month, then not valid for a month, then valid for month again.

We then verify signatures made in these periods to probe whether implementations consider the certificate valid at this point in time.

There are three variants of this test. In the first variant A, we use expiring userid binding signatures. In the second variant B, the userid is bound for the whole time, but we temporarily revoke it using expiring revocation signatures. The third variant C is similar, but we temporarily revoke the certificate.

The signature is over the string "Hello World :)".

Timeline:
        v                                       A                 B, C
        |                              |                 |                    |
    t0 -| Creation of first signature  |                 |                    |
        |                              |                 |                    |
    t1 -| Certificate creation         |                 |                    |
        |                              |                 |                    |
 t1-t2 -| Creation of second signature |                 |                    |
        |                              |                 |                    |
    t2 -| Validity ends temporarily    | Binding expires | Revocation         |
        |                              |                 |                    |
 t2-t3 -| Creation of third signature  |                 |                    |
        |                              |                 |                    |
    t3 -| Validity restored            | New binding     | Revocation expires |
        |                              |                 |                    |
t3-now -| Creation of fourth signature |                 |                    |
        |                              |                 |                    |
   now -|                              |                 |                    |
        v

Explores how robust the certificate canonicalization is in the presence of subkeys with unknown public key algoritms and parameter encodings. While these keys are not functional, we can check whether they can coexist with classical keys so that we can have an upgrade path.

The test verifies a signature with a certificate containing a mock key using an unsupported algorithm or curve. The signature is made using the primary key over the message "Hello World :)". The mock subkey is not involved in any way, besides being present in the certificate.

The test explores two dimensions. On the one hand is the algorithm choice, on the other the parameter representation. The algorithms are:

• Unknown asymmetric algorithm
• ECDSA with an unknown curve
• EdDSA with an unknown curve
• ECDH with an unknown curve

The algorithm-specific data for each of these unknowable subkeys vary between:

• a series of well-formed MPIs
• reasonable-sized data (not in MPI format)
• huge data (unrepresentable as MPI)

Explores how robust the certificate canonicalization is in the presence of unknown certifications.

The test verifies a signature with a certificate containing a certification that is unknown in some way (unknown signature version, unknown public key algorithm, unknown hash algorithm). The signature is made using the primary key over the message "Hello World :)". The unknown certifiation is not involved in any way, besides being present in the certificate.

Tests whether implementations are willing to decrypt messages encrypted for a subkey that has not been marked as encryption-capable.

The key has a couple of subkeys with varying properties, all RSA keys. The test encrypts a message using each subkey and the primary key, and tests whether implementations are willing to decrypt the message.

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized.

In this particular test, the primary key is not revoked. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized.

In this particular test, the primary key is not revoked. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: no subpacket. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: no subpacket. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the subkey is revoked: no subpacket. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: unspecified. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: unspecified. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the subkey is revoked: unspecified. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: compromised. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: compromised. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the subkey is revoked: compromised. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: private. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: private. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the subkey is revoked: private. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: unknown. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the primary key is revoked: unknown. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a hard revocation, all signatures must be considered invalid.

In this particular test, the subkey is revoked: unknown. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the primary key is revoked: superseded. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the primary key is revoked: superseded. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the subkey is revoked: superseded. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the primary key is revoked: key retired. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the primary key is revoked: key retired. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the subkey is revoked: key retired. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable primary key that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the primary key is revoked: uid retired. The signed message is "Hello, World".

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of primary key
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - primary key is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the primary key is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the primary key is revoked: uid retired. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test uses a certificate with a signing capable subkey that is evolving over time. Later on, the subkey is revoked and then re-legitimized using a new signature. We then ask implementations to verify a signature at different points in time. Hard revocations of the key invalidate the signature at any point in time, whereas in the case of soft revocations, the keys can be re-legitimized. This is a soft revocation, so the key may be re-legitimized after which signatures should be considered valid again.

In this particular test, the subkey is revoked: uid retired. The signed message is "Hello, World". As extra subtlety, we bind the subkey *after* the t1-t2 signature.

Timeline:   v
            |
        t0 -| - Creation time of first signature
            |
        t1 -| - Primary key creation
            |
            | - Subkey creation
            |
     t1-t2 -| - Creation time of second signature
            |
            | - Subkey is bound
            |
        t2 -| - Revocation of subkey
            |
     t2-t3 -| - Creation time of third signature
            |
        t3 -| - subkey is re-legitimized
            |
    t3-now -| - Creation time of fourth signature
            |
       now -|
            v

This test generates valid messages with an unusual structure.

This test encrypts messages, with the plaintext being compressed N times to evaluate the maximum recursion depth of implementations.

This is a collection of signed messages. The message is "Hello\r\nWorld!\n". We vary signature type (binary, text), and literal data format identifier. Finally, we do the same with both a binary signature and a text signature at the same time. To avoid deduplication, we sign the second signature using Anne's key.

This is a collection of signed-then-encrypted messages. The messages are signed by and encrypted to the same key. The message is "Hello\r\nWorld!\n". We vary signature type (binary, text), and literal data format identifier. Finally, we do the same with both a binary signature and a text signature at the same time. To avoid deduplication, we sign the second signature using Anne's key.

Tests whether the Marker Packet is correctly ignored.

Tests whether the Trust Packet is ignored. According to Section 5.10 of RFC4880, [trust packets] SHOULD be ignored on any input other than local keyring files.

This tests whether encrypted messages with unknown versions of PKESK and SKESK packets are still decrypted. This is important for the evolution of the message format.

This is a collection of encrypted messages that are malformed, i.e. they do not conform to the OpenPGP Message grammar. All messages are passed to 'sop decrypt bob-secret.pgp'. When a single Literal Data packet is used in a test vector, the usual plaintext "Hello World :)" is used, but when two Literal Data Packets are present, "First" and "Second" are used so that we can tell which packet is picked up by implementations.

This is a collection of signed messages that are malformed, i.e. they do not conform to the OpenPGP Message grammar. All messages are passed to 'sop inline-verify bob.pgp'. When a single Literal Data packet is used in a test vector, the usual plaintext "Hello World :)" is used, but when two Literal Data Packets are present, "First" and "Second" are used so that we can tell which packet is picked up by implementations. In that case, two signatures are made, with timestamps 00:00:00 (for the first message) and 11:11:11 (for the second message), so that we can tell which signature(s) are accepted by implementations.

Encrypted messages that could, but should not, be decrypted (e.g.: v2 SEIPD may only be produced and consumed in combination with v6 SKESK and v6 PKESK). The plaintext is "Hello World :)". For the password-encrypted messages, the password is "password".

Explores whether concatenated ASCII Armor blocks are recognized as keyring. This is not mandated by OpenPGP, but some implementations may chose to support this.

The signature is from Bob over the string "Hello World :)".

Explores whether concatenated ASCII Armor blocks are recognized as sequence of signatures. This is not mandated by OpenPGP, but some implementations may chose to support this.

The signatures are from Bob and Ricarda over the string "Hello World :)", but we only use Bob's cert to verify the signatures.

ASCII Armor is supposed to protect OpenPGP data in transit, but unfortunately it can be a source of brittleness if the Armor parser isn't sufficiently robust.

This test mangles Bob's ASCII Armored key, and tries to decrypt the text "Hello World :)".

ASCII Armor is supposed to protect OpenPGP data in transit, but unfortunately it can be a source of brittleness if the Armor parser isn't sufficiently robust.

This test mangles Bob's ASCII Armored certificate, and tries to encrypt the text "Hello World :)".

ASCII Armor is supposed to protect OpenPGP data in transit, but unfortunately it can be a source of brittleness if the Armor parser isn't sufficiently robust.

This test mangles the ASCII Armored ciphertext decrypting to the text "Hello World :)".

ASCII Armor is supposed to protect OpenPGP data in transit, but unfortunately it can be a source of brittleness if the Armor parser isn't sufficiently robust.

This test mangles the ASCII Armored signature over the text "Hello World :)".

ASCII Armor is supposed to protect OpenPGP data in transit, but unfortunately it can be a source of brittleness if the Armor parser isn't sufficiently robust.

This test mangles the message using the Cleartext Signature Framework. The message is "From the grocery store we need:\n\n-tofu\n- vegetables\n- noodles\n - avocado\n-\n\n".

OpenPGP mandates that leading zeros are stripped when encoding MPIs. This test tests whether leading zeros in S, and 0x40-prefixed R are accepted.

Tests whether implementations can use Cv25519 keys that are not in canonical form to decrypt a message.

Tests whether implementations can use Cv25519 keys that use unusual ECDH parameters.

Tests whether implementations are willing to unwrap session keys using the recipient's primary key fingerprint.

Tests whether packet boundaries are properly enforced by creating a compressed data packet where the compressed data extends beyond the compressed data packet's boundaries.

Tests whether excess bytes in a packet are correctly consumed. The compressed data packet presents the unique opportunity to test whether the packet parser actually consumes (i.e. advances the read cursor) all the bytes specified in a packet header, even though they are not consumed by the underlying decompression algorithm.

The plaintext message is the string "Hello World :)", padded by the specified number of bytes using excess data in the compression stream.

Tests support for partial body encoding by constructing a message encrypted for Bob that uses different encodings for the literal data packet. The message consists of bytes encoding their position in the message modulo 128.

The spec mandates that if partial body encoding is used, the first chunk must be at least 512 bytes long, and the packet must be terminated by a fixed (or full) chunk (which may be of size zero).

The test vector's label indicate the length of the data written and the chunking, where 'fX' indicates a fixed (or full) length of X bytes, 'pX' indicates a partial chunk of X bytes, and 'i' indicates a chunk of indeterminate length.

In some vectors there is less or more data written to the packet than indicated by the chunks. Of particular interest is whether we can use that to peek into the memory after the literal data packet. A relatively safe peek ahead is 22 bytes, the size of the MDC packet.

Explores whether signatures and certs with suboptimal length encoding are accepted when verifying detached signatures.

Each vector consists of a cert and a detached signature over the message "Hello World :)". We modify either the cert or the message to use packets with suboptimal length encoding. The base case uses the unmodified cert and signature.

The labels indicate which artifact is modified, and how. L denotes that a legacy CTB and length encoding scheme is used. The number denotes the length of the encoded length.

Performs basic statistical analysis of random values in encrypted messages generated by implementations:

Each producer generates two (asymmetrically or symmetrically) encrypted messages. The random values in the messages are then extracted and analyzed for sufficient entropy:

• The session key
• The S2K salt (in the case of SKESK packets)
• The IV (in the case of SKESKv6 packets)
• The random prefix (in the case of SEIPDv1 packets)
• The salt (in the case of SEIPDv2 packets)

This test can by definition not determine positively if the entropy of the generated session keys and salts is good (that is, a 'successful' result does not necessarily signify sound randomness!)

However, a 'failure' result is exceedingly unlikely with good randomness. Failures should be investigated!