An Argument for Signing Support about 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

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

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