Advice for encryption tool needed

lemma · August 10, 2025, 10:22pm

I mean, I literally asked what else they’d suggest. And… no answer. ¯\_(ツ)_/¯

eousphoros · August 10, 2025, 11:16pm

It depends on what I was trying to keep secret. Partitioning the data into segments by encrypting them with different ciphers like chacha20 and falcon or whatnot at the most extreme would limit the blast radius should there be a vulnerability discovered in one of the cyphers used.

vic · August 11, 2025, 5:23am

A quick check showed GPG, 7z, RAR all use AES for encryption. age/rage use ChaCha20 and so does PicoCrypt. Now I get it when people said modernity in age/rage.

GPG has compile option to support ChaCha20 but ArchLinux has it disabled.

What Linux tools support Falcon or some other post quantum ciphers ?

eousphoros · August 11, 2025, 5:41am

github.com/FiloSottile/age

Use chacha20 without poly for more speed? Aka AEAD?

opened 11:23PM - 28 Dec 19 UTC

closed 02:01PM - 29 Dec 19 UTC

iger

According to the specification https://age-encryption.org/v1, signing is out of …scope, thus authentication is out of scope, thus AEAD is a misfeature slowing decryption and bloating the file size, and worse, implies nonexistent authentication to an unattentive reader. The specification misquotes an authenticated streaming encryption endorsement https://www.imperialviolet.org/2014/06/27/streamingencryption.html, as it doesn't actually provide any authentication in the recommended usage scheme. Is there actually a reasonable case for encryption without authentication? Is it not a bad idea to release an encryption tool without authentication, as masses will forget to sign when they should? On a more serious note, if we were to take recommendation from the quoted document: https://www.imperialviolet.org/2014/06/27/streamingencryption.html, age would provide a semblance of nacl's crypto_box, with streaming, on a command line. It seems reasonable to support encryption to either a symmetric or asymmetric key and verify authenticity via a symmetric or asymmetric key. No web of trust, key distribution etc. It might be nice if it were interoperable with signify, meaning it could use the same key, at least for signing. It might even be possible to reuse the format to sign the header and that might be sufficient.

github.com/FiloSottile/age

An Argument for Signing Support

opened 01:21AM - 29 Dec 19 UTC

closed 01:09AM - 19 Apr 21 UTC

ghost

According to the [specification](https://age-encryption.org/v1), 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.

I am not very familiar with these specific implementations and these issues are old but its enough to make me stop looking at the project.

GitHub - open-quantum-safe/oqs-provider: OpenSSL 3 provider containing post-quantum algorithms This looks like it implements falcon inside of openssl which you should be able to use to do chacha20-falcon but if not chacha20-poly1305 is also probably fine for awhile. There are other interesting ciphers beyond chacha20 which I encourage people to explore and learn more about.

vic · August 11, 2025, 6:09am

Digital signing (which Falcon also falls into this category of algos) is about verifying the sender who claims what he is. age/rage consciously made the decision not to support it to avoid escalated complexity in its compact implementation. Personally I accept this justification.

Consider typical usage scenarios: OP encrypts a file and stores on USB stick. Hand it over to the recipient face to face. “Digital signing” is physically verified. Or similarly, done through a secured communication channel between them.

I’ve been using chacha20-poly1305 for many years in one application because it’s light on compute and so mobile phone friendly.

I should think of OpenSSL 3 for post quantum ciphers but it’s more a library not an end user friendly CLI tool. So I guess we have to wait a bit for PQC to be more commonplace.

eousphoros · August 11, 2025, 6:10am

I don’t really want to get into the constraints the age/rage projects have put on themselves but using a stream cipher like chacha20 without a signature is very dangerous.

To expand on this since there seems to be a bit of misunderstanding about signatures and signing. In this case its not verifying identity but instead it just allows you detect the file remains unchanged.