In favor of public key sender-authentication support (Re: https://words.filippo.io/dispatches/age-authentication/))

[HW42]

First two side notes:

• I have seen the other related discussions here. The existing threads didn't quite fell like the right place to post this response to @FiloSottile's post. Sorry if you would have preferred this as comment in Support public key authenticated encryption (sender authentication) #229.
• I had looked at age earlier but didn't comment since the existing discussion sounded like this feature isn't desired. But given the post explicitly asks for feedback on this topic I'm doing that now.

Sender-authentication in general

As a tool that advertises itself as "[...] a simple, modern and secure file encryption tool, format, and Go library. It features small explicit keys, no config options, and UNIX-style composability." I expect it to support sender¹-authentication ². Why? Because from my PoV many use cases require this and I think many users implicitly expect this property from encryption.

For this discussion use cases fall in two categories:

The authenticity is guaranteed by other means so only confidentiality is required, for example:

• Backup to some local storage medium.
• A USB drive you carry with you to some other location/machine.
• Encrypted secrets committed into some source code management system (example from the post).
• Encrypt-to-delete (dito)
• A courier you trust but that might still lose the storage media.
• etc. ³

Authenticity is not guaranteed by other means, for example ⁴:

• Backup to a server controlled by a third-party (like backup's to the cloud).
• A courier service you don't trust too much.
• Data transfer through some online service you don't want to trust.
• Transfer through some existing systems (email, web service, etc.)
  I you want to respond with "you shouldn't encrypt email", "use Signal/Matrix/$x" or similar, you don't understand the use case. I'm not talking about replacing PGP/MIME, but cases in which some data has to be transferred by some mechanism you can't freely choose. In the worst case you might have to upload it to some unsecured web form and then someone will forward the file by email, because that's all the current processes in the involved organizations are prepared to handle. ⁵
• etc.

From my personal point of view the cases that require sender-authentication are rather common, I would even expect them to be more common than the other cases. Of course this depends on the user, for example the age design clearly cares a lot about supporting multiple recipients, which is something I seldomly need. But I don't think that those cases that need sender-authentication are niche use cases.

Additionally I think many users implicitly expect that encryption provides sender-authentication. Sure if they have some programming background and you ask long enough the right questions they might realize themselves that this can't work (since the sender doesn't need any secret), but I bet many won't realize this themselves (see for example this comment, and that's from a thread that just discussed the problem). To make things worse age actually provides this property in the passphrase mode. So for me this is exactly one of the UI footguns people criticize PGP for and that age wants to avoid.

Authkeys

@FiloSottile' post considers adding an "authkey" plugin. Those would work like the native X25519 keys, except that the normally public part of the asymmetric key pair would be expected to be kept secret. In my opinion I don't really see a use case in which authkeys would be worth using instead of a symmetric key. Sure I could construct something for which it makes a difference, but those cases seem rather far fetched and from my point of view not worth the complexity ⁶.

Public key sender-authentication support

Therefore I would wish for public key sender-authentication. This doesn't require to support signing (which has been stated as being undesired multiple times). If in the background you actually sign the data an option is to just not support singing without encryption, which probably already prevents the (from age's design undesired) use as signing tool. But probably you can even integrate this such that this is even enforced cryptographically and the recipient could forge the authentication. This might even make the streaming property easier to implement.

I think a simple approach like the following might work (ignoring multiple recipients), but I haven't carefully thought this through and you are in a much better situation to design this anyway: Add a new X25519-sender-auth stanza that gets another field that contains a signature over "age-ecryption.org/v1/X25519-sender-auth\n" || recipient || file key using the senders key.

Footnotes

1. I will be using "sender" and "receiver"/"recipient" and "transport"/"transfer". Of course this includes cases in which sender and receiver might be the same machine or two different machines used by the same user and transport might be the same storage media that just "traveled" in time. ↩

2. Actually I would expect it to be at least strongly encouraged by the UI, but I will leave this out here. ↩

3. Didn't include the "self-authenticating data" example from the blog post, since to me this sounds like one of the cases of trying to be "clever" with crypto which only works if you know very exactly what you are doing and not something age is aimed for. ↩

4. Of course this depends on how much you trust some third party for the concrete case. ↩

5. Admittedly assuming that both sender and final recipient can choose to use age is already an assumption and in many cases you will have to hope that the encrypted zip implementation you have to use is not too bad. But those cases are off-topic here. ↩

6. With complexity I'm more referring to the unusual concept of private asymmetric keys than the required code. ↩

[covert-encryption]

If I understood you correctly, you would still be using traditional signature (i.e. requiring support for it) over recipient public key and file key (symmetric encryption key). This still allows any recipient to forge the content, which as I argue in other threads on this, is rarely a desirable property.

Might as well take the additional step to sign the content and the headers (a hash of), as I've suggested, for the following properties:

• authentication and non-repudiation: Each recipient can be sure that the sender signed it and prove that to third parties (by releasing the encrypted file and the file key)
• No outsiders can strip off the signature without being detected or re-sign with their own, which are problems with encrypt then sign
• No recipient can re-encrypt to different recipient(s) than originally intended, fooling them to think the signed message was addressed at them, a problem with sign then encrypt
• sealed sender (optional): The signature itself remains confidential if the signature header and the signature are also encrypted