6 ms·

A few comments on ‘age’

77 points by beefhash 7y ago

noelwelsh 7y ago
The real issue with gpg / pgp is the terrible UX. If this new tool doesn't address that it isn't much use.
- eliaspro 7y ago
  It's not meant to really replace GnuPG. It doesn't sign, it does not handle trust - it simply encrypts/decrypts.
- upofadown 7y ago
  The gpg/gpg2 UX is pretty simple for this use case of just encrypting files, particularly if you are doing symmetrical.
- eximius 7y ago
  That's not true. It also has old, deprecated crypto. It still works, but it has problems, and not all installations support the same things. I am not well versed enough to regurgitate what other cryptographers here and elsewhere have said about it, but there are lots of problems.
  - upofadown 7y ago
    > It also has old, deprecated crypto. That entirely works.Any sort of realistic crypto standard is going to have to support older systems right up to the point where any problems with those systems actually reduce security in some way. To do otherwise would be irresponsible to your users.
geoah 7y ago
I'm wondering if this feedback has been shared with age's author. To me at least is seems like a better place for this would be age's github issues instead of the author's blog.
- ChrisGranger 7y ago
  I saw these comments on age's GitHub page before seeing this post on HN, so not to worry. https://github.com/FiloSottile/age/issues/59 https://github.com/FiloSottile/age/issues/59
- nmadden 7y ago
  Yes, I raised an issue on github. But I think there are general points raised that are more widely applicable than just to age.
- nabla9 7y ago
  The author has detailed reply https://groups.google.com/forum/#!msg/age-dev/r-gwwcN3L-0/EhEvUbG5AwAJ https://groups.google.com/forum/#!msg/age-dev/r-gwwcN3L-0/Eh...
FiloSottile 7y ago
Happy to see discussion of the age design. I replied on the age-dev mailing list. https://groups.google.com/d/msgid/age-dev/505e74e5-1385-4055-9a8f-bd41cd20a409%40www.fastmail.com https://groups.google.com/d/msgid/age-dev/505e74e5-1385-4055... tl;dr: we seem to disagree on what users should want from age—confidentiality or also authentication—and that would lead not only to different design choices, but to drastically different UXs.
- Terretta 7y ago
  I had a diff tl;dr: > ”Unfortunately, the age spec doesn’t document its threat model or the security goals it is intended to achieve ... Most importantly, the spec should define its security goals.”
bscphil 7y ago
IMO the criticisms here make more sense if you also read the author's article series "Public key authenticated encryption and why you want it". https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and-why-you-want-it-part-i/ https://neilmadden.blog/2018/11/14/public-key-authenticated-...
AgentME 7y ago
>or I need to define my own chunked streaming signature verification tool and combine that with age (and hope the chunk sizes line up). Wouldn't you just need a tool that only outputs chunks after they're verified, and then you pipe that tool's output to age? I'm not sure that signify or minisign currently support this streaming operation though.
- nmadden 7y ago
  Yes, but no such tool exists (yet) as far as I’m aware. You also need to tie the chunks together so that they cannot be rearranged, duplicated, or deleted. You also need to be careful about what you think this tells you. For example, suppose you ran a competition where the winner is the first person to upload an encrypted+signed correct answer to a shared folder. An attacker can wait for somebody to upload the winning answer and then simply strip the real winner’s signature off and sign the encrypted blob (which they can’t decrypt) with their own private key - hurray, the attacker has now won the prize! If you reverse the order of signing and encryption you can run into bugs like [1]. You can securely combine public key encryption and signatures by including extra metadata fields inside each layer. Or you can use a function that provides public key authenticated encryption like NaCl’s crypto_box or the mode I’ve proposed for JOSE [2]. [1]: https://groups.google.com/forum/m/#!msg/sci.crypt/73yb5a9pz2Y/LNgRO7IYXOwJ https://groups.google.com/forum/m/#!msg/sci.crypt/73yb5a9pz2... [2]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 Edit: clarify ambiguous use of “their”
AgentME 7y ago
I have a lot of trouble understanding the issue in the comparison with JOSE. The problem with JOSE's header was that many libraries offered an API that was "validate that this is a valid token using one of these keys", but a key was just one part of the unauthenticated header. An attacker could create a token that used one of the keys with an algorithm it didn't belong to and create a token that was signed by one of the whitelisted keys in a wrong algorithm. The solution was to make sure all the libraries had the API where the user whitelisted allowed values of the entire header: "validate that this is a valid token using one of these headers (alg+key)". I'm not sure what the corresponding version of the first issue would be in age, and then why the answer wouldn't be for age to make sure to check the entire header against a whitelist instead of considering just a subset of it.
- nmadden 7y ago
  I updated the blog post, I had misunderstood that part of the age spec.
zeroimpl 7y ago
As a user, if I have a key and an encrypted file, aside from actually decrypting the file, all I care about is ensuring that the software can confirm that the encrypted file was encrypted using the same key. Why should this be complicated?
- nmadden 7y ago
  If this is all you need use age with a password/passphrase (scrypt). It does exactly what you want.

77 points by beefhash 7y ago

noelwelsh 7y ago

The real issue with gpg / pgp is the terrible UX. If this new tool doesn't address that it isn't much use.

eliaspro 7y ago
It's not meant to really replace GnuPG. It doesn't sign, it does not handle trust - it simply encrypts/decrypts.
upofadown 7y ago
The gpg/gpg2 UX is pretty simple for this use case of just encrypting files, particularly if you are doing symmetrical.
eximius 7y ago
That's not true. It also has old, deprecated crypto. It still works, but it has problems, and not all installations support the same things. I am not well versed enough to regurgitate what other cryptographers here and elsewhere have said about it, but there are lots of problems.
- upofadown 7y ago
  > It also has old, deprecated crypto. That entirely works.Any sort of realistic crypto standard is going to have to support older systems right up to the point where any problems with those systems actually reduce security in some way. To do otherwise would be irresponsible to your users.

geoah 7y ago

I'm wondering if this feedback has been shared with age's author. To me at least is seems like a better place for this would be age's github issues instead of the author's blog.

ChrisGranger 7y ago
I saw these comments on age's GitHub page before seeing this post on HN, so not to worry. https://github.com/FiloSottile/age/issues/59 https://github.com/FiloSottile/age/issues/59
nmadden 7y ago
Yes, I raised an issue on github. But I think there are general points raised that are more widely applicable than just to age.
nabla9 7y ago
The author has detailed reply https://groups.google.com/forum/#!msg/age-dev/r-gwwcN3L-0/EhEvUbG5AwAJ https://groups.google.com/forum/#!msg/age-dev/r-gwwcN3L-0/Eh...

FiloSottile 7y ago

Happy to see discussion of the age design. I replied on the age-dev mailing list. https://groups.google.com/d/msgid/age-dev/505e74e5-1385-4055-9a8f-bd41cd20a409%40www.fastmail.com https://groups.google.com/d/msgid/age-dev/505e74e5-1385-4055... tl;dr: we seem to disagree on what users should want from age—confidentiality or also authentication—and that would lead not only to different design choices, but to drastically different UXs.

Terretta 7y ago
I had a diff tl;dr: > ”Unfortunately, the age spec doesn’t document its threat model or the security goals it is intended to achieve ... Most importantly, the spec should define its security goals.”

bscphil 7y ago

IMO the criticisms here make more sense if you also read the author's article series "Public key authenticated encryption and why you want it". https://neilmadden.blog/2018/11/14/public-key-authenticated-encryption-and-why-you-want-it-part-i/ https://neilmadden.blog/2018/11/14/public-key-authenticated-...

AgentME 7y ago

>or I need to define my own chunked streaming signature verification tool and combine that with age (and hope the chunk sizes line up). Wouldn't you just need a tool that only outputs chunks after they're verified, and then you pipe that tool's output to age? I'm not sure that signify or minisign currently support this streaming operation though.

nmadden 7y ago
Yes, but no such tool exists (yet) as far as I’m aware. You also need to tie the chunks together so that they cannot be rearranged, duplicated, or deleted. You also need to be careful about what you think this tells you. For example, suppose you ran a competition where the winner is the first person to upload an encrypted+signed correct answer to a shared folder. An attacker can wait for somebody to upload the winning answer and then simply strip the real winner’s signature off and sign the encrypted blob (which they can’t decrypt) with their own private key - hurray, the attacker has now won the prize! If you reverse the order of signing and encryption you can run into bugs like [1]. You can securely combine public key encryption and signatures by including extra metadata fields inside each layer. Or you can use a function that provides public key authenticated encryption like NaCl’s crypto_box or the mode I’ve proposed for JOSE [2]. [1]: https://groups.google.com/forum/m/#!msg/sci.crypt/73yb5a9pz2Y/LNgRO7IYXOwJ https://groups.google.com/forum/m/#!msg/sci.crypt/73yb5a9pz2... [2]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02 Edit: clarify ambiguous use of “their”

AgentME 7y ago

I have a lot of trouble understanding the issue in the comparison with JOSE. The problem with JOSE's header was that many libraries offered an API that was "validate that this is a valid token using one of these keys", but a key was just one part of the unauthenticated header. An attacker could create a token that used one of the keys with an algorithm it didn't belong to and create a token that was signed by one of the whitelisted keys in a wrong algorithm. The solution was to make sure all the libraries had the API where the user whitelisted allowed values of the entire header: "validate that this is a valid token using one of these headers (alg+key)". I'm not sure what the corresponding version of the first issue would be in age, and then why the answer wouldn't be for age to make sure to check the entire header against a whitelist instead of considering just a subset of it.

nmadden 7y ago
I updated the blog post, I had misunderstood that part of the age spec.

zeroimpl 7y ago

As a user, if I have a key and an encrypted file, aside from actually decrypting the file, all I care about is ensuring that the software can confirm that the encrypted file was encrypted using the same key. Why should this be complicated?

nmadden 7y ago
If this is all you need use age with a password/passphrase (scrypt). It does exactly what you want.