An Argument for Signing Support

[ghost]

According to the specification, signing of any type is out of scope:

• Any kind of signing (which is not a tooling problem, but a trust and key distribution problem, and to the extent that tools matter you should just use signify/minisign, and for keys we should probably use SSH ones)

This is, in my opinion, a missed opportunity. This project is an opportunity to not only build a new tool that addresses issues that plague other tools (such as GPG), but also to build support in the community around this tool. By placing this restriction on the functionality that age may contain, age is less useful, and will require the use off additional tools (and additional keys to manage) to achieve the same functionality that users will likely expect.

This expectation can be demonstrated by looking at the open issues (such as #38 & #49), and conversation on Twitter about age - the lack of signing support is striking potential users as a surprise, as it would be assumed that a tool of this nature would include signing support. There is, without question, user interest in this feature.

There are, as noted in the quoted section above, issues with signing support, in that it can involve key distribution and trust, which are complex issues - that said, these issues need not be addressed by age, as a solution is not required to allow users that wish to validate that an encrypted file is from the expected sender/system to perform this validation. Adding optional support for signing a file with the sender's key is a trivial matter; adding an additional header to the age file format is a simple matter, adding CLI support for this is likewise, a simple matter.

In use cases where it is desirable to validate the sender, it would not be unreasonable to require users to transmit their public key out-of-band (from a UX perspective, this could use the proposed aliases.txt file to display a friendly name for known senders). It is possible that key distribution methods could evolve around age, though these should be allowed to evolve organically, and it is not necessary for age to address this at this point in time.

While there are tools such as signify and minisign (which I am personally a fan of), it is not a good user experience to require users to make use of an additional tool, with additional keys, to perform signing of files they produce.

I would propose that an optional header be added, which includes the sender's public key and a signature of the hash of the encrypted data. When a file is decrypted, this signature would be validated, and decryption should fail if this check fails. The user can either manually review the public key for a match to known senders, or age could look up the public key in the proposed aliases.txt file and display a friendly name. This could be done with minimal impact, would improve protection of files that have been signed, and require no extra effort from those that don't have a need to perform this validation.

I appreciate that this could lead to a push for greater development of a key distribution & trust solution (which could evolve into a interesting side project, though that's another conversation), though it will without doubt lead to a better user experience and lead to further use cases for age.

[tqbf]

Arguments against signature support:

• There's already a good, relatively modern signature system available to everything that would use age (minisign/signify), and we should be encouraging its adoption, not confusing it.

• Signature support creates an affordance for using age for secure messaging, an application for which it is not at all suited.

• Signatures have weird UX interactions with authentication (you could argue that confusion here is at the heart of the PGP MDC problem),

• The signature proposal here adds optional headers and, in effect, opens a door to protocol negotiation that may be hard to close.

Ultimately, the issue I see with signatures is that it's not clear what the use case is, and one of the best things about age is that it's fiercely scoped down to its use case. If someone comes up with a clear use case for signed encrypted files that isn't "very bad version of Signal", the formats for both minisign and age are well-documented and both are available as libraries; nothing stops people from using them both.

[iger]

I wholeheartedly agree with all of @adamcaudill's reasoning, except the proposed implementation.

• minisign/signify - AFAIK the tools and their formats do not support streamed verification, thus they cannot simply be used together with age in command or library form in streaming use cases. It means requiring more storage/passes and opening for TOCTOU vulnerabilities.
• Signal - In making a useful file/stream encryption/security tool, I see no relevance whether or not a tool can be used as a bad Signal replacement.
• PGP/GPG has many, many issues. I don't see how having users create their own encrypt+sign concoction would be more secure than designing and implementing an actually secure format and tool. Creating a WoT immitation and multitudes of key, encryption and signature formats probably would not be the best of ideas.
• I guess so, if you do it badly

The use case is, that secure messaging - transporting files/streams through space and/or time usually requires both encryption and authentication of the data (making sure it's the correct data).

[pauldotknopf]

I prefer to have static binaries compile/run on multiple distributions/OSs easily. That is why I like golang and am trying to void C/C++ libs. The go-minisign looked like a potential, but it only handles verifying signatures.

In the end, I am going to use age, but it would be nice if it was built in.

# Encrypt the md5
md5sum file | age -r ... > file.sig
# Decrypt the md5 to compare against "md5sum file"
age -d -i ... file.sig

[HW42]

This doesn't provide additional security and doesn't replace a signature! An attacker can just generate and encrypt the MD5 hash (assuming they know the public key of the recipient). If you only care about accidental (as opposed to malicious) modifications, or you are in the special case in which the public part of the asymmetric key pair is also kept secret, this is already covered by the use of an AEAD internally by age. So no need for the extra checksum in that case.

[mimoo]

I'll add my two grains of salt :P

First, what is the threat model here? If I'm encrypting a file to myself and keeping it somewhere where it can't be tampered with then I see no problem.

In other use-cases, it sounds like there is no way to verify the origin of the file, or that the file was intended to me. Which is problematic even when I encrypt to myself.

I am not too familiar with minisign, but the problem of composing here is that it most likely doesn't work in some of the important use-cases:

• if I encrypt something to you, and sign the ciphertext and append the signature, someone can still replace the signature with theirs and pretend that they sent you the encrypted file).
• If I do the reverse and encrypt the file + signature, now you can re-encrypt this to someone else and they'll think I sent them the file

[Macil]

First, what is the threat model here? If I'm encrypting a file to myself and keeping it somewhere where it can't be tampered with then I see no problem.

If you're keeping a file for yourself on some medium, then I think there's a spectrum of security for that medium that goes from {can't be tampered with by others, can't be read by others} -> {can't be tampered with by others, can be read by others} -> {can be tampered with by others, can be read by others}. On the first side of that spectrum, you don't need signatures or encryption. In the middle of that spectrum, the spot you identify, then you need encryption but not signatures, and age works fine. On the end side of that spectrum, you want the file encrypted to you and signed by you.

I would guess that the ends of this spectrum are more common than the middle (private storage / fully trusted cloud host vs possibly compromised cloud host), and it's awkward that age can't go all the way in handling the least-secure end of that spectrum. It's annoying that age has support for doing nice things like streaming decryption, but I don't personally know how to combine tools so that I get age's features like streaming decryption while combined with signing to work for stuff stored in the least secure storage mediums.

[averms]

This issue seems somewhat related to #59. I will add that I fully agree with tqbf who says

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

[maisiliym]

What people really want is a single key agent to do all their crypto needs, and GPG sucks if only because it doesnt allow the usage of plain encryption keys and cannot do encryption and signatures with a single secret. Wether or not code X or code Y is needed to sign/encrypt is not really a problem, although it doesnt really make sense to split them, but whatever; this is the dark age of sotware and a man shall do with what is available to him. GPG key agent currently supports a lot of systems.

What does Signal have to do with any of this? It seems quite off-topic; here's some messaging platform that uses phone numbers to create trust. Lol. How does one get signal data from his messages to prove a certain device sent a certain message at a certain time? Who the fuck knows! So it's not a real tool, just another crypto2000 vertically-integrated corporate thing. If anything, libolm is what should be used as a comparison, and it seems to mostly do data-encryption, not signatures

[xxxserxxx]

Having no signature support pushes the problem onto users, and comes close to forcing users to "roll their own cryptography." They're not being asked to implement PK, but there are any number of ways a user could hack together their signing solution that opens attack vectors. Having a lack of a standard exposes users and hinders adoption. For example, look at @pauldotknopf's solution above: md5sum is vulnerable to intentional corruption and shouldn't be used here. Finally, by taking no position, age limits itself to people with a certain level of technical sophistication, which is exclusive. It consequently provides a disincentive for client software to add support as it forces them into a walled garden where the only (likely) compatible software is itself.

A solution might provide a wrapper that uses minisign and age together as an all-in-one tool, easy to use and set up, combining public signing and encryption keys and farming out to the respective libraries... but, then, what about that hypothetical solution different from adding signing to age?

1. Is it really preferable to have users figure out their own standards for signing and encryption?
2. With everybody forging their own paths, how many different protocols will M people have to support to communicate with each other?
3. What is the happy path -- a good, working solution -- for users?
4. Why does adding signing support require solving the key trust problem? The author of opmsg argues for (and implements) the trust model outside of the encryption/signing tool.

[Seirdy]

A solution might provide a wrapper that uses minisign and age together as an all-in-one tool, easy to use and set up, combining public signing and encryption keys and farming out to the respective libraries

This sounds like the best solution for people who want one tool that can sign and encrypt. The UNIX Philosophy exists for these sorts of use-cases.

[xxxserxxx]

I'll re-iterate that I foresee interoperability (and security) issues if everyone is rolling their own solution for this. Encryption has at least an isolationist use case. Signing is a particularly collaborative activity, and having a consistent, predictable solution is an important aspect.

[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/

[covert-encryption]

Nice to see progress with this.

Separate encryption and signing has always been major trouble, as it forces one to do either sign then encrypt (violating the doom principle) or encrypt then sign (where it is easy to rip off the signature or replace it with another). Also if no encryption is employed at all, having the message plainly visible leads to signatures not being verified (because people are lazy), or to signature verification failures due to formatting changes in text (e.g. different whitespace or typographic quotation marks being inserted).

These of course are just the issues that we are trying to address with Covert encryption.

[xxxserxxx]

@FiloSottile That was a pleasant read; thanks for taking the time to write it. It was written in a general case, and didn't talk explicitly about signing-for-email. You did a good job explaining that there's subtlety about what "signing" means; I think I'm (personally) still a little confused about how your proposed tweak (regardless of the technical implementation) would impact this issue.

As you say, there are a couple of signing use cases; for email, I'd venture that most people who are signing are wanting the signature to assert that the email was signed by a specific identity. Ascertaining trust in the signing key itself is a separate issue. Web of trust, central cert authority, blockchain identity public ledger... I think it'd be ideal if the identity aspect be separated, and it'd be necessary with Age (I think?).

Would you mind bringing it back to the email signing use case? What would a solution possibly look like using Age authentication?