FWIW, no cryptographer I know would call 128 bits "sub-standard" and NIST itself is of the opinion that quantum computers will not break 128 bit keys. The links in my other comment get into more details as to why.
I want to mention something about "this issue should be clearly stated in the front page". I've seen this suggestion made many times about many projects, and I disagree with it almost universally, aside from the fact that it's often made about non-issues, such as in this case. Security (and security-relevant) tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. Imagine if every project came with a list of potential issues you have to form an opinion on, and that you're not allowed to complain about because you were warned, after all. It's not a solution! If I thought this was an issue, I would produce a v2 of the spec, and guide users through migrating, instead.
To sum up for people here, the Grover’s algorithm can’t be easily parallelized. Operating serially, it’s difficult to implement. Hence, it may not reduce the security of 128 bits to 64 bits; it’s less effective in practice.
Keep in mind that NIST doesn’t recommend symmetric keys below 112 bits. So the margin with 128 bits is low. I give you an example. If the user’s random number generator isn’t perfect, the file key in Age will contain an entropy less than 128 bits, which quickly gets you into an uncomfortable area. You should also take into account small reduction in security due to new attacks and speed ups. I am not a cryptographer; a cursory look at Grover’s doesn’t cut it. If I write crypto software, I will err on the side of ignorance and be conservative in my design.
As for the cryptographers’ opinion, I think the industry standard for encryption of data data at rest is AES-256. The acceptable range is 128–256, but 128 is the low end of the range, the recommendation is 256 bits which is what most companies use. Sure, 100 bits may not be breakable now or in short term, but nobody uses 100 bits for that reason (note that Age uses 10 words in its default, which if using bips list, is 110 bits).
Lastly, you should not forget compliance. Top secret information is often required to be encrypted with 256 bits (see NSA recommendations).
> note that Age uses 10 words in its default, which if using bips list, is 110 bits
That's correct. The passphrase is then fed to scrypt with N = 18, so the total number of operations required for a conventional key search that enumerates possible passphrases is 2^128. I do wonder how hard scrypt is to implement in a QC, I'll look in the literature or ask. Even if scrypt costed zero gates, which seems unlikely since memory accesses are not free, 110 bits Grover would still require ~2^112 gates at MAXDEPTH 2^40.
> I think the industry standard for encryption of data data at rest is AES-256.
Discussions about what is or isn't "industry standard" are hard to have productively because there is no authoritative or technical answer, but I will point out that mail.google.com and Chrome use 128 bits ciphers to talk to each other. Data at rest is not more sensitive than data in transit, the latter can just be recorded by an attacker and cracked in the future.
wow. this is such a bad take, it makes me question using Age at all.
> tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user.
no tool is perfect, including Age. and no issue is fixed immediately, or at all.
so instead of waiting months or years for an issue to be fixed, it can be quite
helpful to throw a quick warning on the front page, so at least people are warned
in the meantime. Its just a sign of respect, and of not wasting the users time.
> Imagine if every project came with a list of potential issues you have to form an opinion on
I would be glad if more projects included important to-dos or shortcomings up
front, so that I dont have to discover them myself after a week or month of use.
Further, no one is forcing users to form an opinion, or even read the known
issues. you throw them in a section at the bottom the of README, then they can
read if they want, and form and opinion if they want.
without doing this, you're essentially lying to the userbase, as you are aware of
issues, perhaps even important ones, that are not fixed, and are purposefully
hiding that information, or at least not being as forthcoming with it as you
could be.
> wow. this is such a bad take, it makes me question using Age at all.
I would think it would bolster your confidence in age, as the maintainer is expressing a commitment to fix issues as they arise, not punt indefinitely with TODOs at the bottom of a README.
> > tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user.
You stripped important context from the beginning of this quote, the original reads:
> Security (and security-relevant) tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user.
You might want to read this paragraph from @FiloSottile:
> The only reason to use more than 128 bits of key is to protect against multi-user attacks. […] There are two ways to protect against that: larger keys or nonces. age uses a 128-bit per-file nonce fed into HKDF, making the total search space 128 + 128 = 256 bits, safe in every multi-user scenario, too.
This is big. Without those multi-user attacks Age is much safer than I initially thought. The tiny security increase we'd get by going to 256-bit keys is not worth making a breaking change. Not by itself at least.
FWIW, no cryptographer I know would call 128 bits "sub-standard" and NIST itself is of the opinion that quantum computers will not break 128 bit keys. The links in my other comment get into more details as to why.
I want to mention something about "this issue should be clearly stated in the front page". I've seen this suggestion made many times about many projects, and I disagree with it almost universally, aside from the fact that it's often made about non-issues, such as in this case. Security (and security-relevant) tools should not have issues that need communicating to users, and if they did they should fix them, not delegate a choice to a user. Imagine if every project came with a list of potential issues you have to form an opinion on, and that you're not allowed to complain about because you were warned, after all. It's not a solution! If I thought this was an issue, I would produce a v2 of the spec, and guide users through migrating, instead.