7 ms·

> The textual file header wraps the file key for one or more recipients, so that it can be unwrapped by one of the corresponding identities Isn't that what LUK

by theK 4y ago

> The textual file header wraps the file key for one or more recipients, so that it can be unwrapped by one of the corresponding identities Isn't that what LUKS does as well? What's the novelty in this one?

Macha 4y ago
My impression is that the novelty is less about the encryption format and more about the tools and ecosystem being understandable to anyone that has used ssh before (and indeed, in the case of the reference implementation, even letting you use straight up ssh keys)
- fbdab103 4y ago
  Indeed, ease of use is almost more important than security. If the tooling is so hard to use correctly that everyone makes a mistake, users gain little. The interface to age seem so straightforward that as long as the crypto primitives are solid, this would do a lot for making encryption more accessible. Edit: correct an English gaff
- theK 4y ago
  Sorry, I kinda missed that. The "multiple recipient" thing is quite prevalent in the titles (here and on github) so I thought this was supposed to be the key differentiator.
waynesonfire 4y ago
Nice call out. I've seen age come up a few times on hackernews. It's trying so hard to dislodge gpg but I just can't see that happening for me. In order to replace gpg, it would have to be 10x better and that's quite a leap for an encryption tool that requires stability, compatibility. Overcoming the gpg learning curve is do-able. It's worth it. You'll thank yourself in 10 or 20 years when you need to decrypt a file. Get a Yubikey as well, or two.
- fbdab103 4y ago
  I am happy to change with the times and adopt modern tools. Something without all of the sharp edges that make encryption more difficult in practice. If nothing else, by being written in a memory safe language, age is unlikely to ever have a comparable list of CVEs[0] as GPG. A code execution vulnerability was discovered in GPG as recently as this year. Such vulnerabilities could of course still happen in age, but they are always going to be less common. [0]: https://www.cvedetails.com/vendor/4711/Gnupg.html https://www.cvedetails.com/vendor/4711/Gnupg.html
  - loup-vaillant 4y ago
    As the author of a non-negligible amount of peer reviewed cryptographic code, I happen to know a bit about how much safe languages help you. And the answer is, "less than you'd think". Modern cryptographic primitives benefit very little from safe languages like Rust, compared to using C and running the test suite under Valgrind and Clang sanitisers (all 3 of them). Undefined behaviour related errors are stupidly easy to test: no heap allocations, no input dependent branches or indices, pathologically straight-line code, all that makes it fairly easy to implement an extremely effective test suite that is almost impossible to circumvent… except for logic bugs. In fact, the only significant bug I've ever shipped to production was a logic bug Rust or Go wouldn't have saved me from. The real problems start when you start tackling encodings & textual formats. Those are definitely gnarlier, and I personally wouldn't trust myself with an ASN-1 decoder in C. This can be avoided by using simple binary formats instead, but since Age has decided to be a little more advanced using a safe language is definitely a plus.
    - Retr0id 4y ago
      As a text format anti-fan, I recently took a stab at defining a binary file format that's semantically equivalent to Age (more or less) [1]. It's currently just a draft/prototype/PoC, although I'd be interested to get some more eyes on it. Conceptually, it should be possible to implement compatibility with Age's plugin ecosystem, although I haven't done that yet (and I haven't thought about potential cryptographic implications of doing so, either). I've written a bit more about my rationale and why I'd prefer a simple binary format here [2] - notably, I found two text parsing bugs (of low/moderate severity) in existing Age implementations. [1] https://github.com/DavidBuchanan314/bagel https://github.com/DavidBuchanan314/bagel [2] https://github.com/FiloSottile/age/discussions/497 https://github.com/FiloSottile/age/discussions/497
hamandcheese 4y ago
I'm not sure there is any specific feature that is novel, nor do I think any claims as such were made. The novelty is packaging it all together with an easy to use, hard to misuse UX.

by theK 4y ago

Macha 4y ago

My impression is that the novelty is less about the encryption format and more about the tools and ecosystem being understandable to anyone that has used ssh before (and indeed, in the case of the reference implementation, even letting you use straight up ssh keys)

fbdab103 4y ago
Indeed, ease of use is almost more important than security. If the tooling is so hard to use correctly that everyone makes a mistake, users gain little. The interface to age seem so straightforward that as long as the crypto primitives are solid, this would do a lot for making encryption more accessible. Edit: correct an English gaff
theK 4y ago
Sorry, I kinda missed that. The "multiple recipient" thing is quite prevalent in the titles (here and on github) so I thought this was supposed to be the key differentiator.

waynesonfire 4y ago

Nice call out. I've seen age come up a few times on hackernews. It's trying so hard to dislodge gpg but I just can't see that happening for me. In order to replace gpg, it would have to be 10x better and that's quite a leap for an encryption tool that requires stability, compatibility. Overcoming the gpg learning curve is do-able. It's worth it. You'll thank yourself in 10 or 20 years when you need to decrypt a file. Get a Yubikey as well, or two.

fbdab103 4y ago
I am happy to change with the times and adopt modern tools. Something without all of the sharp edges that make encryption more difficult in practice. If nothing else, by being written in a memory safe language, age is unlikely to ever have a comparable list of CVEs[0] as GPG. A code execution vulnerability was discovered in GPG as recently as this year. Such vulnerabilities could of course still happen in age, but they are always going to be less common. [0]: https://www.cvedetails.com/vendor/4711/Gnupg.html https://www.cvedetails.com/vendor/4711/Gnupg.html
- loup-vaillant 4y ago
  As the author of a non-negligible amount of peer reviewed cryptographic code, I happen to know a bit about how much safe languages help you. And the answer is, "less than you'd think". Modern cryptographic primitives benefit very little from safe languages like Rust, compared to using C and running the test suite under Valgrind and Clang sanitisers (all 3 of them). Undefined behaviour related errors are stupidly easy to test: no heap allocations, no input dependent branches or indices, pathologically straight-line code, all that makes it fairly easy to implement an extremely effective test suite that is almost impossible to circumvent… except for logic bugs. In fact, the only significant bug I've ever shipped to production was a logic bug Rust or Go wouldn't have saved me from. The real problems start when you start tackling encodings & textual formats. Those are definitely gnarlier, and I personally wouldn't trust myself with an ASN-1 decoder in C. This can be avoided by using simple binary formats instead, but since Age has decided to be a little more advanced using a safe language is definitely a plus.
  - Retr0id 4y ago
    As a text format anti-fan, I recently took a stab at defining a binary file format that's semantically equivalent to Age (more or less) [1]. It's currently just a draft/prototype/PoC, although I'd be interested to get some more eyes on it. Conceptually, it should be possible to implement compatibility with Age's plugin ecosystem, although I haven't done that yet (and I haven't thought about potential cryptographic implications of doing so, either). I've written a bit more about my rationale and why I'd prefer a simple binary format here [2] - notably, I found two text parsing bugs (of low/moderate severity) in existing Age implementations. [1] https://github.com/DavidBuchanan314/bagel https://github.com/DavidBuchanan314/bagel [2] https://github.com/FiloSottile/age/discussions/497 https://github.com/FiloSottile/age/discussions/497

hamandcheese 4y ago

I'm not sure there is any specific feature that is novel, nor do I think any claims as such were made. The novelty is packaging it all together with an easy to use, hard to misuse UX.