8 ms·

_o/ hi all, age author here! The OP link is the spec, here's a few other things you might find interesting - the Go reference implementation https://age-encry

• loup-vaillant 4y ago
  Hi, something is bothering me here: https://github.com/C2SP/C2SP/blob/main/age.md#file-key https://github.com/C2SP/C2SP/blob/main/age.md#file-key > Each file is encrypted with a 128-bit symmetric file key. Did you meant 256 bits instead? Or is this a deliberate choice? As far as I can tell the body is encrypted with a 256-bit key derived from the file key, and using a 128-bit file key would limit the security of the whole scheme when using it with X25519 (its ~128 bits of collision resistance is better than the 128 bits of preimage resistance of the file key), or with extremely strong passwords. The only rationale for this choice I can think of is saving space, but your choice of a textual format with base64 encoded keys & nonces suggests you didn't care that much about space… I'm confused here, what did I miss?
  • Retr0id 4y ago
    I can't answer the why, but I can confirm that it's not a typo, the file key is indeed 128-bit as-implemented. However, the "payload key" is 256-bit, derived from the 128-bit file key via HKDF-SHA256. It's the "payload key" that keys the ChaCha20Poly1305 cipher, which encrypts the file payload itself.
  • FiloSottile 4y ago
    This is a common question! It's a deliberate choice. The notion of security levels is somewhat in disuse. It's impossible to do any operation, even moving a single electron, 2^128 times so anything that actually has 128 bits of security is "secure enough" for any requirement. This is not a new idea, see agl's post from 2014. [https://www.imperialviolet.org/2014/05/25/strengthmatching.html https://www.imperialviolet.org/2014/05/25/strengthmatching.h...] There are arguments that boil down to "more is always better" but I am unconvinced by them as they could be used to argue for 512, 1024, 4096 bit symmetric keys as well, why stop at 256 bits. Part of what changed is that fundamental cryptographic primitives break a lot less than they used to do. "Too much crypto" is a good read about this. [https://eprint.iacr.org/2019/1492 https://eprint.iacr.org/2019/1492] The only reason to use more than 128 bits of key is to protect against multi-user attacks. That's a situation where an attacker is trying to break one of a very large number of ciphertexts or keys, and would be satisfied with breaking any of them. If you are trying to break one of 2^52 ciphertexts encrypted with 128-bit keys, you can theoretically do it in 2^76 time, which might be doable! (Major asterisks, like that they all need to have encrypted the same plaintext, but anyway.) 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. Why use a nonce and not a bigger key? That works out to the same file size overhead! The difference is that the key is repeated for every recipient while the nonce is only serialized once. That means that if a file has 65 recipients, this will let us save about a kilobyte. Is it worth a lot? Not really, but it was free. It also makes most stanza bodies a single line, which is nice. There's also a misconception that 128 bits are not enough for post-quantum resistance. I also thought that, but it turns out to be based on a simplistic understanding of Grover's algorithm. I wrote about it in the context of age specifically [https://words.filippo.io/dispatches/post-quantum-age/#128-bits-are-enough https://words.filippo.io/dispatches/post-quantum-age/#128-bi...] but if you don't trust me you can also check the very last FAQ on NIST's PQC page. [https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs https://csrc.nist.gov/Projects/post-quantum-cryptography/faq...] (I am not sure what you mean by X25519's "collision resistance" vs the file key's "preimage resistance". Those are hash function security notions and this is a more complex setting. As you know, X25519 is a key exchange algorithm, not a hash function, and ~128 bits is the amount of work required to reverse the private key into the public key. Anyway, to get a collision in the derived file key, both the key and the nonce would have to collide (128 + 128 = 256 bits) so the "collision resistance" of the whole age scheme is still 128 bits.)
• aborsy 4y ago
  I have concerns about the symmetric encryption with a 256 bits password in Age. The File Key is 16 bytes, or 128 bits. So, although ChaCha20-Poly1305 can protect data with 256 bits of security, the symmetric encryption in Age is essentially 128 bits. This is sub-standard. In particular, files encrypted with Age may be decrypted with quantum computers in the future (for example cloud backups). There is little reason to use 128 bits symmetric encryption these days when 256 bits is far more secure and almost equally performant. I understand the file format is designed around 128 bits asymmetric encryption. Still it would be great if the format/software could be updated so that the symmetric encryption with a 256 bits password is 256 bits (not silently falling back to 128 bits). At least, this issue should be clearly stated in the front page.
  • FiloSottile 4y ago
    I've responded to these concerns in my reply to the sister comment. https://news.ycombinator.com/item?id=34949197 https://news.ycombinator.com/item?id=34949197 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.
    • Reptur 4y ago
      [flagged]
    • 2h 4y ago
      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.
• raggi 4y ago
  What was the motivation for introducing C2SP and CCTV as concepts? Are there immediate plans to introduce more than Age?
  • FiloSottile 4y ago
    Yes, they are broader projects, although it's too early for a proper announcement. They make sense together, hence why CCTV is under C2SP, but they have different motivations. C2SP is an experiment in producing specifications applying techniques from software development, including semantic versioning and the concept of a maintainer. It was borne out of displeasure with the pace and output of the IETF's CFRG, which is taking years to publish ready-made documents like ristretto255, and makes complex protocols with lots of sharp edges and moving parts, as well as being generally a pain to engage with. CCTV is a place to pool test vectors, so we don't have to keep reinventing them for each implementation and we can cross-pollinate our test coverage. It's also a place to drop new vectors to test for newly found edge cases or issues. You can think of it as an open Project Wycheproof.
    • raggi 4y ago
      Thank you!
• d-z-m 4y ago
  Classic McEliece age plugin...thoughts? ;)