Recommend Age

[dngray]

Description

URL of affected page: https://privacyguides.org/software/productivity/#encrypt

https://github.com/FiloSottile/age

[ghost]

This seems like a CLI Tool.

[dngray]

It is, but it is:

• modern code
• fairly decent and supported on a lot of platforms.

We don't not mention CLI tools as we do mention tomb on that page.

Ideally it would be a nice first project for someone to make a graphical user interface maybe in Qt using that tool.

[ph00lt0]

Interesting project for sure. What are the privacyguides requirements on encryption tools?

I quickly went through this. All seems to rely on 128 bit key, which is likely going to be fine for the next years.
https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s80Unjv8zCg_A7sPAX_9Y/preview

Just wonder if some kind of audit would be appropriate? Encryption usually fails at the implementation side.

[samuel-lucas6]

@efb4f5ff-1298-471a-8973-3d47447115dc Yes, which is why there's a discussion here.

[HACKERALERT]

I agree with @samuel-lucas6 and @ph00lt0 and would like to add some of my own views on this.

In the age specification:

encrypt[key](plaintext) is ChaCha20-Poly1305 from RFC 7539 with a zero nonce.

If I'm interpreting this correctly, that basically states that a nonce isn't used at all and age relies on the key being random to avoid duplicate nonces. I get that, but... the key is only 128-bits, which not only reduces the maximum security of the program by quite a bit, but also increases the chance of a nonce, or rather, "key" collision. Expanding on the topic of keys, age uses scrypt for key derivation. scrypt is okay, but when modern and more demanding KDFs like Argon2 are easily accessible, age is not at its full potential.

Don't get me wrong here, I support age being added and believe it would be a good replacement for gpg. It is popular and written by a recognized cryptographer. But as is custom for PT/PG, I feel it is worth mentioning some of age's shortcomings.

[samuel-lucas6]

I have no idea why 128-bit keys are being used. The scrypt parameters could be higher too.

[ph00lt0]

@HACKERALERT I just read the specification and I believe you are right. I bring up that 128 bit keys are still considered very secure, but it does indeed limit the maximum security, and it would be better to start looking at larger key sizes as also recommended by most standardization institutions.

About the nonce, I was not sure if what I was reading was correct. From what I know reusing nonce, actually would be quite a flaw. As is also described in chapter 3 of this article http://cr.yp.to/mac/poly1305-20050329.pdf

So I went to look further and stood upon this discussion FiloSottile/age#227. So it turns out that the key cannot be reused, but the nonce will be fixed. This is very odd, and not the recommended way of implementing it. I am not good enough of a crypto person to know whether this is problematic, but it is definitely a good observation you made.

And yes Argon2 is considered the best afaik.

[samuel-lucas6]

The spec is confusing, and so is that discussion. I don't understand why the master key is only 128 bits.

Reusing a nonce is bad, especially with AES-GCM. However, a fixed nonce is perfectly fine assuming the key never repeats, and with a 256-bit key, that's not a concern. The odds are worse for a 128-bit key but not terrible, just like the chances of a salt repeating. Using a fixed nonce isn't that different from using a counter nonce in some sense, and I've seen it done elsewhere to avoid having to store a nonce. I wouldn't call it the recommended approach though as you say.

[dngray]

I think regarding this topic we were looking at some guides instead privacyguides/privacyguides.org#845