Sender Authentication

[soatok]

This is a rough draft proposal for implementing Sender Authentication in age without introducing any new cryptographic primitives.

This has previously been discussed on Cryptography Dispatches and in prior discussions.

Use Case

As an age user, I may want to allow my friends to send me encrypted messages while also being reasonably sure about which friend sent it to me.

It's not enough to sign-then-encrypt with another utility (e.g., minisign) because signatures intended for someone else could be re-bound to new ciphertext and I might be fooled.

I would also like to prevent strangers from being able to prove who sent which file without needing to be able to decrypt it.

(It's okay if I cannot decrypt files for which I do not know the sender's public key, should sender authentication be enabled for the message.)

Before I can think about such a thing in practice, however, I need to grapple with the complexity of key management. (For the sake of discussion, I'm going to assume this is already a solved problem, but any discussion must either address it or explicitly punt on it to be solved at another layer.)

Threat Model

1. Mallory received a message from Alice and wants to replay it to Bob such that he believes it was sent to him directly by Alice. This should fail.
2. Eve is capable of inspecting all ciphertexts and wants to observe whether Alice or Bob is sending messages to Carol simply by inspecting the ciphertext. (Other side-channels and metadata are not in scope.) The proposed solution should not reveal Alice or Bob's identity.
3. Alice sends Dave an encrypted file. Mallory replaces the ciphertext with an unsigned file of her own making. This should fail.

Proposed Solution

Cryptography

The current age protocol (v1) specifies an X25519 Recipient Type, which uses ephemeral-static Diffie-Hellman.

ephemeral := make([]byte, curve25519.ScalarSize)
if _, err := rand.Read(ephemeral); err != nil {
	return nil, err
}
ourPublicKey, err := curve25519.X25519(ephemeral, curve25519.Basepoint)
if err != nil {
	return nil, err
}
sharedSecret, err := curve25519.X25519(ephemeral, r.theirPublicKey)
if err != nil {
	return nil, err
}

When sender authentication is enabled for the message, we will implement a design pattern inspired by Signal's X3DH. This may warrant a different recipient-type (for domain separation and simplicity).

(This diff is meant to be pseudocode, to illustrate the point.)

  sharedSecret, err := curve25519.X25519(ephemeral, r.theirPublicKey)
  if err != nil {
  	return nil, err
  }
+ if senderAuthEnabled {
+ 	additionalSecret, err := curve25519.X25519(senderSecret, r.theirPublicKey)
+ 	if err != nil {
+ 		return nil, err
+ 	}
+ 	// Concatenate to existing ephemeral-static ECDH secret
+	sharedSecret = append(sharedSecret, additionalSecret...)
+ }

And then the HDKF usage when sender auth is enabled would look like:

  salt := make([]byte, 0, len(ourPublicKey)+len(r.theirPublicKey))
  salt = append(salt, ourPublicKey...)
  salt = append(salt, r.theirPublicKey...)
- h := hkdf.New(sha256.New, sharedSecret, salt, []byte(x25519Label))
+ if senderAuthEnabled {
+ 	// long-term public key, not ephemeral:
+ 	salt = append(salt, senderPublicKey...)
+ 	h := hkdf.New(sha256.New, sharedSecret, salt, []byte(x25519WithSenderAuthLabel))
+ } else {
+ 	h := hkdf.New(sha256.New, sharedSecret, salt, []byte(x25519Label))
+ }

What about multiple recipients?

Same thing: Just add an additional ECDH(senderSecret, recipientPublic) to the HKDF IKM, and use a domain-separated label.

EDIT: After feedback on the Fediverse, I'm of the opinion that multiple recipients should not be supported by this feature.

API

When encrypting a message, adding an additional optional flag (e.g. -A [key-id]) that enables this mode.

When decrypting a message sent with this mode, the recipient must pass a congruent flag (e.g., -A [key-id]) to tell age which public key to use to unwrap the key from the header.

Security Considerations

An attacker is assumed to be able to distinguish between messages sent with and without sender-auth enabled.

If the recipient doesn't know the public key of the sender, decryption will fail. This information is not communicated in-band.

Therefore, anyone that opts to use sender-auth is responsible for ensuring that the public keys are vended appropriately, and that the recipient knows which public key is expected to successfully decrypt the ciphertext before they attempt to do so with age. Users SHOULD NOT be opportunistic (i.e., loop through their address book and try everyone's public key until one succeeds).

If the recipient specifies a sender's public key for a ciphertext that didn't use sender-auth, it MUST fail to decrypt.

[unusualevent]

I like this for the following reasons:

1. it prevents people like me from shooting themselves in the foot writing their own cryptography
2. we're going to try combining signing and encryption regardless. may as well do it correctly (e.g., auth-HPKE or whatever)

[str4d]

This is a proposed change to the native X25519 recipient type, not to the overall age format. As such, its effects are completely negated if there is any other kind of recipient present in the same header. So this proposal would still require the same changes that were proposed in the referenced Cryptography Dispatches. While that could be special-cased inside every client implementation (as was originally done for the scrypt recipient), we have since implemented it as the "labels" extension to age-plugin:

• age-plugin: Add labels extension to recipient-v1 C2SP/C2SP#37
• c89f0b9
• Implement labels str4d/rage#514

I recommend that this proposal be initially trialled as a standalone age plugin, that uses a random label to tell the age client that it must be the only recipient in the header. The sender-auth UX could be achieved in a standalone plugin with the existing UX in a few different ways:

• Have the plugin request an input from the user at encryption / decryption time. The user provides whatever argument is necessary there, instead of on the CLI.
  • I think this is the better approach for testing, as it's closer to the eventual UX of an integrated approach.
• Give the plugin two forms of recipient / identity encodings: the normal encodings for long-term identities and their corresponding recipients, and an ephemeral encoding that the plugin can synthesize on the fly via its own CLI that contains both a recipient and an identity ((identity_A, recipient_B) at encryption, (recipient_A, identity_B) at decryption).

I recommend this approach because there is a bunch of UX work that needs to be done before any kind of CLI flag could be proposed for addition to the core client interface shared by e.g. age and rage. In particular, just like the -j flag that added a "default" mode for plugins, any CLI flag that is added here needs to interact correctly with every possible recipient kind (both native and plugin). Some plugins in particular won't have public key information in their recipient encodings (instead e.g. invoking remote calls to HSMs or KMSs), and others might use recipient schemes that are not amenable to sender authentication. The random label that a sender-auth-required recipient kind might use, only helps if that recipient kind is involved in an encryption somehow; the CLI flag would however always be potentially present. The UX implications of the presence of such a flag, and the resulting combinatorial increase in CLI surface area, need to be carefully documented in order to ensure that all clients implement it securely.

[EyeCon]

I'm not sure I understand the proposal correctly so feel free to correct me in any way possible, but doesn't this process give the public keys a "private" character, in the sense that they at least shouldn't be advertised if not kept secret entirely?

[soatok]

Based on outside discussions, I'm going to make an opinionated decision that we shouldn't support multiple recipients with this feature, as it could degrade KCI security further than anticipated.

I'm not sure I understand the proposal correctly so feel free to correct me in any way possible, but doesn't this process give the public keys a "private" character, in the sense that they at least shouldn't be advertised if not kept secret entirely?

No.

You specifically need the recipient's secret key in order to recover the first 256 bits of the shared secret. (You can use either party's to recover the latter 256 bits of the shared secret, but that's not helpful.) Authentication is tied into whether the ciphertext decrypts successfully.

[SalusaSecondus]

The cryptography looks correct. I want to call out two important subtle pieces of the design which need to be preserved:

1. We change how the salt is managed to include the sender's public key
2. We change the HKDF label to indicate that we are providing different input

I agree with requiring a single recipient as cross-recipient impersonation is a problem that cannot be reasonably solved without much more invasive changes to how age works.

Long-term, I believe that taking in the sender's public key as a command-line argument would be a very good thing. Otherwise people will need to pass it in via STDOUT. There is definitely a lot of work that needs to get there first.

Finally, you specify that determining the sender via trial decryption is not acceptable. Why not?

[soatok]

Finally, you specify that determining the sender via trial decryption is not acceptable. Why not?

It's a lesson learned from the poor ergonomics of PGP that led to https://efail.de

If we allow the sender to be slurped up from the ciphertext rather than provided explicitly by the decryptor, we have to both indicate who the sender was and provide the plaintext. This is two distinct cryptographic responsibilities for one function, and if one of them falls through, it's likely someone will implement our spec in a way that doesn't automatically cause the other to fail. This will lead to issues where you can either strip signatures, impersonate users, or release unauthenticated plaintext (with respect to sender authentication, not message integrity), and we can side-step all of this risk by simply requiring the public key be provided as a command line argument by the decryptor.