Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimental: Symmetric Keys and Forwarding #141

Draft
wants to merge 19 commits into
base: main
Choose a base branch
from
Draft

Experimental: Symmetric Keys and Forwarding #141

wants to merge 19 commits into from

Conversation

wussler
Copy link
Contributor

@wussler wussler commented Jan 17, 2023

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.

openpgp/forwarding.go Outdated Show resolved Hide resolved
openpgp/forwarding.go Outdated Show resolved Hide resolved
openpgp/forwarding.go Show resolved Hide resolved
twiss and others added 16 commits June 25, 2024 16:03
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.

Conversly, 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 implenetation 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 availabe.

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 serialing the public part of a keyring.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants