Comment # 6 on bug 1193065 from
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: