Support public key authenticated encryption (sender authentication)

[NeilMadden]

Currently age encryption with X25519 or ssh keys is unauthenticated. While the use of an AEAD for encryption of the file contents prevents tampering with the ciphertext, an attacker who is in a position to do such tampering can instead just replace the entire file with their own encrypted contents.

Although this doesn’t impact the confidentiality of age-encrypted files, it has practical impacts on the security of streaming use-cases for which an online AE mode was (I think) selected. For example, in agl’s blog post linked from the spec he talks about cases such as:

gpg -d your_archive.tgz.gpg | tar xz

This is insecure if an attacker could replace the archive with one of their choosing. Such an attack is possible in most situations a chosen ciphertext attack is.

While you could argue that origin authentication can be done by another tool like minisign or signify, use of those tools implies giving up on streaming as a signature over the entire archive would need to be verified before any output can be processed.

Public key authenticated encryption could be achieved by making the encryptor supply a X25519 private key and using crypto_box (or equivalent) to encrypt the file key in the header rather than the current ECIES-like scheme.

(NB where there are multiple recipients then each recipient can use the decrypted file key to create new encrypted file contents with the same header and make it look as if the original user produced the new ciphertext, so the threat model would need to be worked out in detail - perhaps only supporting a single recipient when using this mode).

I wrote a bit more about this here: https://neilmadden.blog/2019/12/30/a-few-comments-on-age/

[tqbf]

Unlike a full-on signing feature, a decryption feature that takes a durable sender public key seems straightforwardly an improvement?

[xorhash]

It's probably worth noting that the response to this has apparently moved to the mailing list: https://groups.google.com/d/msg/age-dev/r-gwwcN3L-0/EhEvUbG5AwAJ

[ovalseven8]

I wonder about the use-cases for age without any public key sender authentication or signing capabilities?

The "I want to decrypt this message and verify it's from XY" is a very common use-case. And combining age with e.g. Minisign looks unhandy because you have to maintain two different key pairs.

[tqbf]

In what application is "I want to decrypt this message and verify it's from XY" very common? age isn't a general-purpose building block the way pgp is.

[ovalseven8]

When age is used primarily as small library for other, bigger systems, I can understand that it's only focused on encryption/decryption (confidentiality).

But since age seems to be a CLI tool as well, I do not understand the lack of optional sender authentication - and even with sender authentication it's far from being the all-in-one solution that GnuPG is.

[FiloSottile]

Hey all, sorry to resurrect an old thread, but I just wrote up the details of how we think about authenticated encryption, including why we did not include support for signing and a possible way forward. I'd be interested in feedback from the people who had opinions or use cases revolving around this. https://words.filippo.io/dispatches/age-authentication/

[kardianos]

If I understand your proposed tweak correctly, is to (a) limit recipients one to prevent leakage and (b) to wrap the recipient header so it isn't directly discoverable.

The signcryption (I'm reading http://dx.doi.org/10.5120/12451-9215 ) is very cool. I saw someone suggest using age to send encrypted emails and publish public keys over DNSSEC. In this (admittedly hypothetical) situation age would be vulnerable to replacement attacks. Also recipients keys could be derived from the unencrypted To header and DNS lookup.

I use age for a more mundane purpose. I would be concerned that while your tweak work for some use cases, in the hypothetical above, it would still fail to properly authenticate because the public key of the recipient could be otherwise derived. While I understand (I think) the reason technically for not allowing multiple recipients, it seems like a sharp(unexpected?) edge to have in the UX.

Is there a technical reason that signcryption could not be used? Backwards compatibility? It does seem like a useful property to be able to authenticate the source from the source public key. From a UX perspective, it would not appear to complicate the API.

[covert-encryption]

I gather that signcryption is functionally equivalent to encrypt then sign (presuming that senders and recipients are also signed) and that the only benefit is having to do less computation (less scalarmul operations with elliptic curves, to be particular). Hardly a benefit worth a mention, and thus I am not really surprised that no-one seems to implement it.

Implementing it would certainly be harder than simply adding a signature, as it would also change how the encryption key is calculated, while being just as complicated as a separate signature for the signing part. One notable difficulty is with that the signature (R, s) is needed for calculating encryption keys, which can be difficult in streaming (large files). Having to know the sender key prior to decryption could also be problematic (very often we wish to send messages to someone whose public key we have but who don't know of us a priori).