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

[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

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