Thanks for the clarification. To sum up for people here, the Grover’s algorithm can’t be easily parallelized. Operating serially, it’s difficult to implement.

Thanks for the clarification. 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).