A few comments on ‘age’ | Hacker News Reader

A few comments on ‘age’

neilmadden.blog

77 pointsbeefhash18 comments

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

It's not meant to really replace GnuPG. It doesn't sign, it does not handle trust - it simply encrypts/decrypts.

The gpg/gpg2 UX is pretty simple for this use case of just encrypting files, particularly if you are doing symmetrical.

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.

> 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.

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-...

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...

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.

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.”

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.

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

Yes, I raised an issue on github. But I think there are general points raised that are more widely applicable than just to age.

The author has detailed reply https://groups.google.com/forum/#!msg/age-dev/r-gwwcN3L-0/Eh...

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.

I updated the blog post, I had misunderstood that part of the age spec.

>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.

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/73yb5a9pz2... [2]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-02

Edit: clarify ambiguous use of “their”

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?

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

Reply on news.ycombinator.com