https://bugzilla.suse.com/show_bug.cgi?id=1193065 https://bugzilla.suse.com/show_bug.cgi?id=1193065#c6 --- Comment #6 from Matthias Gerstner <matthias.gerstner@suse.com> --- I had a look at the AGE spec [1] at the rage-enc command line tool as such, as well as into its source code. [1]: https://age-encryption.org/v1 The concept looks interesting for an easy to use file encryption tool on the command line. Certainly more easy and flexible to use than what we know from gnupg. Problematic for me on the design level is only that they leave out the signing part. As they state in the spec:

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

So this means for us to replace GPG with rage-encryption we would need to couple it carefully with one of the proposed options for signing, *or* we would need to rely on people using otherwise trusted channels to transmit rage encrypted data. Relying on people in this regard is probably too much to ask, however. rage-encryption itself supports a small zoo of encryption algorithms. The source code for rage-encryption itself it pretty managable, but relies a lot on third-party crates that I cannot cover all as part of this review. The one thing that could go wrong cryptography wise within rage-encryption itself is the parametrization of the cryptographic primitives. For example for x25519 [2]. On the other hand some (as I believe) less frequently used encryption schemes like ChaCha20-Poly1305 are supported. Less frequently used could mean a larger probability of yet undetected problems in libraries that implement them. [2]: https://github.com/str4d/rage/blob/main/age/src/x25519.rs#L165 I am struggling a bit with the scope of this review. I don't think a fully blown source code review will help much. The tool is too generic both in its command line usage and its source code implementation to focus on anything in particular. Looking at all cryptography related third-party crates and their usage would exceed an efficient scope of the review. The source code that I *did* look into looks well thought out, however. -- You are receiving this mail because: You are on the CC list for the bug.