https://bugzilla.suse.com/show_bug.cgi?id=1193065
https://bugzilla.suse.com/show_bug.cgi?id=1193065#c6
--- Comment #6 from Matthias Gerstner
[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.