Is recipient secrecy sufficient for unforgeability?

[awnumar]

In this post I'm referring to the native X25519 recipients implemented by this package.

age uses public-key cryptography to implement file encryption, so any key is actually a key-pair: one used for encryption and another for decryption.

With normal symmetric encryption, e.g. using an AEAD with key-commitment, an attacker is unable to produce a valid ciphertext without knowledge of the secret key, as they're unable to forge a valid MAC.

This is not the case with age, as knowledge of the recipient is sufficient to produce a valid ciphertext. To overcome this, you'd have to compute a MAC over the ciphertext, which is tricky to juggle alongside a streaming API and requires separate key management (or some key derivation from the identity).

Another approach is to keep the recipient a secret, however I'm not sure if ciphertexts leak the recipient or other information that allows construction of a ciphertext. Is there something I'm missing here or is this sufficient to disallow forgeries?

(The use-case here is where we have no communication between different parties, rather age is being used to encrypt data for yourself to decrypt later. This question makes less sense when sharing data between parties -- in that case you'd use a signature or multiple channels.)

[FiloSottile]

Yes! I explored that exact property for that exact purpose in https://words.filippo.io/dispatches/age-authentication/.

One big caveat, which is why this is not advertised in the docs: you need to use only one recipient at a time. Otherwise, anyone with the identity for recipient B can forge files that will decrypt with identity A (because they can reuse the file key).

We might add a special encoding for "secret recipients" that enforce they can only be used alone, at some point.

[awnumar]

Thank you, that clears it up!

We might add a special encoding for "secret recipients" that enforce they can only be used alone, at some point.

Interesting idea. In our use-case we have a wrapper library around age that only supports encrypting to a single recipient at a time, but the other issue is how to communicate to users that the recipient is secret. API design can only go so far -- the worry is that people think "it can't decrypt so it's safe to share". Maybe a combined public-private key object or non-exportable recipient would suffice.