A blog post was recently published with some comments on the age design. I think it's awesome that people are looking at and discussing the design. Here are my initial thoughts on it.
Authenticated encryption This is a core disagreement on what age should do, or even on what users should want to do, I think. We designed age as a confidentiality tool, to replace the very very common task of encrypting a file to a PGP public key. I believe it delivers strictly better security guarantees than that, and I don't think the author disputes that. AEADs are required for confidentiality to defeat oracle attacks, so of course we use AEADs, but we are intentionally making no claim of sender authentication.
Solving for sender authentication instantly makes the UX and UI far more complicated. You can see that already in the author's post, where he finds themselves suggesting TOFU and filesystem keyrings. That's not just a confidentiality tool anymore.
Still, what the author suggests is not signing: anyone who could decrypt the file could alter it. I can't think of any way to communicate to a user who's specifying a verification key that the file is not actually guaranteed to come from the holder of the verification key. I'd fully expect users to shoot themselves in the foot with it, making it a bad security UX.
(I think there's actually a chance that the public key is required to generate a file that will decrypt for a certain secret key, making it an authenticator key already, but I'd be reticent to document that even if it turned out to be true, not to overload the semantics.)
Threat model The spec should absolutely explicitly address the threat model and security goals, agreed.
crypto_box As an aside, I am no fan of crypto_box. It fails to separate sender key and recipient key, leading for example to trivial reflection attacks, similarly to the verification key issue above. (The docs delegate responsibility to the application: "just use odd nonces for the lexicographically lower key!") It's also a ludicrous C API, but libsodium fixed that.
Just use libsodium I don't think designing a new format is a good time to follow the overused "don't roll your own crypto" mantra. I stuck to the most boring thing that would do the job. We disagree on what the job should be, but that decision shouldn't be made based on what is available in libsodium.
JOSE alg header I don't see the parallel: keys are indeed tied to a single algorithm, like the linked post suggests. The algorithm names in the header don't instruct the implementation on how to process the message, they are just there to easily match to the available user-provided identities.
In particular this bit seems like a misunderstanding:
In order to decrypt the file key it trusts the header to tell it what algorithm to use.
The implementations trust the configured identities, and then match them to the header recipients.
Cryptographic Doom Principle Heh, I remember thinking about this when adding the header MAC, but this is unavoidable: you always need to do key establishment before you can check a MAC.
Happy new year to all. I wrote a brief response in the comments on my blog, but I thought I’d send a more detailed response here.
On Tuesday, 31 December 2019 10:55:50 UTC, Filippo Valsorda wrote:
> A blog post was recently published with some comments on the age design. I think it's awesome that people are looking at and discussing the design. Here are my initial thoughts on it.
>
> Authenticated encryption This is a core disagreement on what age should do, or even on what users should want to do, I think. We designed age as a confidentiality tool, to replace the very very common task of encrypting a file to a PGP public key. I believe it delivers strictly better security guarantees than that, and I don't think the author disputes that. AEADs are required for confidentiality to defeat oracle attacks, so of course we use AEADs, but we are intentionally making no claim of sender authentication.
What oracle attacks are you worried about in an offline file encryption tool?
--
You received this message because you are subscribed to the Google Groups "age-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to age-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/age-dev/e2ec4400-b3e8-462c-8ff3-1c29266a6def%40googlegroups.com.
One comment on use cases; I will leave the cryptography to the cryptographers.On Wed, Jan 1, 2020, 12:01 AM Neil Madden <neil.e...@gmail.com> wrote:Happy new year to all. I wrote a brief response in the comments on my blog, but I thought I’d send a more detailed response here.
On Tuesday, 31 December 2019 10:55:50 UTC, Filippo Valsorda wrote:
> A blog post was recently published with some comments on the age design. I think it's awesome that people are looking at and discussing the design. Here are my initial thoughts on it.
>
> Authenticated encryption This is a core disagreement on what age should do, or even on what users should want to do, I think. We designed age as a confidentiality tool, to replace the very very common task of encrypting a file to a PGP public key. I believe it delivers strictly better security guarantees than that, and I don't think the author disputes that. AEADs are required for confidentiality to defeat oracle attacks, so of course we use AEADs, but we are intentionally making no claim of sender authentication.
What oracle attacks are you worried about in an offline file encryption tool?I guarantee that someone is going to hook it up to a web server, that's just what people do these days :)
You can imagine an interface like SecureDrop that allows anonymous submission of encrypted files.