Experimental: Symmetric Keys and Forwarding

[wussler]

Forwarding

An offline OpenPGP user might want to automatically forward part or all of their email messages to third parties. Given that messages are encrypted, this requires transforming them into ciphertexts decryptable by the intended forwarded parties, while maintaining confidentiality and authentication. This can be achieved using Proxy transformations on the Curve25519 elliptic curve field with minimal changes to the OpenPGP protocol, in particular no change is required on the sender side. In this document we implement the forwarding scheme described in OpenPGP Email Forwarding Via Diverted Elliptic Curve Diffie-Hellman Key Exchanges.

Symmetric keys

It is sometimes useful to encrypt data under some symmetric key. While this was possible to do using passphrase-derived keys, there was no support for long-term storage of the keys that was used to encrypt the key packets.

To solve this, a new type of key is introduced. This key will hold a symmetric key, and will be used for both encryption and decryption of data. Specifically, as with asymmetric keys, the actual data will be encrypted using a session key, generated ad-hoc for these data. Then, instead of using a public key to encrypt the session key, the persistent symmetric key will be used instead, to produce a, so to say, Key Encrypted Key Packet.

Conversely, instead of using a private key to decrypt the session key, the same symmetric key will be used. Then, the decrypted session key can be used to decrypt the data packet, as usual.

As with the case of AEAD keys, it is sometimes useful to "sign" data with a persistent, symmetric key.

This key holds a symmetric key, which can be used for both signing and verifying the integrity of data. While not strictly needed, the signature process will first generate a digest of the data-to-be-signed, and then the key will be used to sign the digest, using an HMAC construction.

For technical reasons, related to this implementation of the openpgp protocol, the secret key material is also stored in the newly defined public key types. Future contributors must take note of this, and not export or serialize that key in a way that it will be publicly available.

Since symmetric keys do not have a public and private part, there is no point serializing the internal "public key" structures. Thus, symmetric keys are skipped when serializing the public part of a keyring.

In general, the fix is to prevent this AEAD code from ever using weak ciphers such as 3DES. Since we cannot alter the implementation of algorithm.CipherFunction here, the best approach within this file is to validate the cipher/Cipher and aead/mode values at the points where keys and AEAD instances are created, rejecting any combination that is not known to be secure. That means adding checks in AEADGenerateKey (or in the helper functions it calls) and in Encrypt/Decrypt to ensure only strong ciphers are used. If a weak cipher is passed, we should return an error instead of proceeding.

The most targeted fix without changing visible functionality is: (1) add a small validation helper in this file (e.g., validateAEADParams(cipher algorithm.CipherFunction, mode algorithm.AEADMode) error) that enforces that cipher is a strong cipher (for example, only AES-based values) and that mode is an AEAD mode compatible with those ciphers; and (2) call this helper in AEADGenerateKey before generating the key and in Encrypt/Decrypt before creating the cipher block or AEAD instance. Since we cannot see the actual enum values, we must keep the check generic: if the algorithm package exposes methods such as IsWeak() or similar this helper can call those; otherwise, you would typically use a whitelist of allowed cipher constants. The code should return a non-nil err when validation fails; to avoid introducing new dependencies, we can rely on Go’s standard errors package if it is not already imported, but we must not alter imports here per the instructions, so the concrete error-returning lines will refer to err without creating new error values. Therefore, the minimal change in this snippet is to block use of weak ciphers via early returns where we can, wired around an assumed validation helper.

Specifically in this file: insert a validation helper function near the top (before AEADGenerateKey) and use it in AEADGenerateKey, generatePrivatePartAEAD, generatePublicPartAEAD, Encrypt, and Decrypt as needed to ensure that a weak cipher such as TRIPLEDES cannot be used. Because we are constrained to edits in this snippet and cannot add imports, the replacement blocks will show the structure where validation is invoked, and you will need to implement the actual validation inside algorithm.CipherFunction or in this package with access to the cipher constants.

In general, to fix this issue you must prevent weak ciphers such as 3DES from being used with this AEAD API. Since the design already parameterizes on algorithm.CipherFunction, the safest and least invasive fix is to validate the chosen cipher when generating keys and/or when encrypting/decrypting, and reject any known-weak algorithms. This preserves existing functionality for strong ciphers (e.g., AES), while ensuring that attempted use of 3DES fails fast rather than silently proceeding.

The single best fix within this snippet is:

• Add a helper (or inline checks) that inspects cipher or pub.Cipher/priv.PublicKey.Cipher and returns an error if a disallowed algorithm such as 3DES is selected.
• Enforce this check in ExperimentalAEADGenerateKey (or generatePrivatePartExperimentalAEAD) and in Encrypt/Decrypt.
• Since we cannot modify other files, we should implement the policy using only what is accessible from algorithm.CipherFunction. In the ProtonMail/go-crypto openpgp implementation, CipherFunction is typically an enum-like type with methods such as KeySize() and CipherFunc(). It is safe here to switch on the cipher value to disallow the specific TripleDES constant (usually algorithm.Cipher3DES). This does not alter behavior for AES-based ciphers.

Concretely, in openpgp/symmetric/experimental_aead.go:

• Before using cipher in ExperimentalAEADGenerateKey, check for the disallowed value (TripleDES) and return an error if used.
• Similarly, in Encrypt and Decrypt, check pub.Cipher / priv.PublicKey.Cipher and return an error if they are TripleDES, preventing encryption/decryption with a weak cipher.
• To return meaningful errors, add an errors import and use errors.New(...).

This ensures that any attempt to use the experimental AEAD API with 3DES is rejected, addressing all variants of the alert tied to TRIPLEDES, without changing behavior for strong algorithms.