2 ms·
> The current design uses the same key for both ChaCha20 and Poly1305, but my recent rereading of the Poly1305-AES paper seems to imply that the Poly1305 key sh
by zeveb 10y ago
> The current design uses the same key for both ChaCha20 and Poly1305, but my recent rereading of the Poly1305-AES paper seems to imply that the Poly1305 key shouldn't be used for anything else. Guidance from actual cryptographers would be appreciated here; the ChaCha20/Poly1305 AEAD RFC appears to be silent on the matter.
As a general rule, a key for one thing shouldn't be used for the other. However, one take some key material and calculate HMAC("ChaCha20", key material) and HMAC("Poly1305", key material) and use those keys for the two algorithms.
> Currently, the Poly1305 MAC is truncated to 64 bits - due to a desire not to inflate our metadata any more than necessary. Guidance from cryptographers is requested as to whether this is a reasonable option; do note that the MAC is not stored with the data, but is itself stored encrypted elsewhere in the btree.
I really think that's a poor idea. A 64-bit MAC provides 32-bit security (due to the birthday attack), which is … poor. You want at least 128 bits in a modern system, and perhaps even more.
You may wish to take a look at NSA's Suite B for good key & hash lengths.
I am not a cryptographer, nor have I read the rest of your proposal in-depth; those two comments just leapt out at me.
There are disk-encryption algorithms which may serve to provide low-level encryption, upon which you could build authenticated, encrypted storage by using MACs at a higher level (e.g. a MAC per file maybe?).
Please try not to roll your own encryption. It's frightening how easy it is to get this sort of thing completely wrong.
- CiPHPerCoder 10y ago> However, one take some key material and calculate HMAC("ChaCha20", key material) and HMAC("Poly1305", key material) and use those keys for the two algorithms. See also: HKDF
- koverstreet 10y agoBirthday attack doesn't apply here; the HMAC an attacker would be trying to collide with is fixed and stored elsewhere, encrypted. Don't give me the "don't roll your own encryption", I've been doing my homework and I've been very explicit about what I'm not confident enough to analyze myself. If you're even suggesting a MAC per file, honestly you're not qualified here.
- orf 10y agoThat is a terrible comment to make and comes across as overly hostile to someone who is only trying to help. Cool project though.
- EdHominem 10y agoHow HN. Someone offers canned advice and the project maintainer's reasonable response gets hellbanned. The real joke is that the advice to not roll your own came with the poster's own half-baked suggestion...
- orf 10y agoNobody got hellbanned, and the response was less than reasonable as you can well see. Even more so given that the post was asking for feedback. The only content was that the birthday attack doesn't apply. If the comment was so canned and pointless then don't reply.
- geofft 10y ago> Please try not to roll your own encryption. It's frightening how easy it is to get this sort of thing completely wrong. He's not rolling his own encryption. That advice dates from the mid-'90s when people were inventing their own block ciphers. The state of the art in disk encryption technology is absymal, e.g, no MACs at all, just some voodoo block ciphers that maybe offer tamper-resistance. If you want to do this sort of thing properly, you must roll your own cryptosystem. There's the significant danger that the "don't roll your own crypto" mantra has separated the crypto-implementing community into two groups: one that's too self-confident to listen to any advice, and one that's too afraid to do anything but use existing crypto code that's probably been written by group 1. That's basically the story of SSL today, for instance. Let's not let that be the case any more.