Hot take: cryptography engineering wouldn’t be that hard if we all just commented our damn code. A lot of the magic _makes sense_!
-
Show this thread
-
To prove that crypto code can be understandable, I gave my best shot at writing a readable Poly1305 implementation. It tries to explain both what it’s doing and how. (It’s also 75% faster than the current one.)https://blog.filippo.io/a-literate-go-implementation-of-poly1305/ …
10 replies 208 retweets 567 likesShow this thread -
Replying to @FiloSottile
Some suggestions: * put it on GitHub or similar so it can be reviewed there * RFC 7539 is obsoleted by RFC 8439 (fixes bugs; still has 1 erratum) * would be nice to have a ref to explanation/security analysis of Carter-Wegman * no tests/evidence of checking against test vectors.
1 reply 0 retweets 1 like -
Replying to @feministPLT @FiloSottile
Also, no warning that this isn't secure unless you encrypt the tag. (Yeah if someone reads the RFC then they would know that, but considering that most application crypto bugs are due to misuse, seems important to reiterate.)
1 reply 0 retweets 0 likes -
Replying to @feministPLT @FiloSottile
Incidentally, the proof in https://eprint.iacr.org/2014/613.pdf is missing any discussion of injectivity of the plaintext/AD encoding, or why the high-order 1 bit is needed.
1 reply 0 retweets 0 likes -
Replying to @feministPLT
The real implementation lives at https://go-review.googlesource.com/c/crypto/+/169037 …, there are tests in the package. I think proofs are too high level to discuss in the implementation itself, they are not required to understand the code. What do you mean encrypt the tag? (Will fix the RFC ref, thanks!)
1 reply 0 retweets 2 likes -
Replying to @FiloSottile @feministPLT
GHASH and POLYVAL values have to be encrypted with AES to become MAC tags. Neither function on its own is a MAC and the key is reversible. I think naked Polyval1305 is also not a MAC, but it needs the nonce to be encrypted, rather than the output, to make it one.
1 reply 0 retweets 0 likes -
Replying to @colmmacc @feministPLT
Naked Poly1305 is a MAC AFAIK, it just has single-use keys and no nonce, which is why the original Poly1305-AES construction uses AES to derive them from (key, nonce).
1 reply 0 retweets 2 likes -
Replying to @FiloSottile @colmmacc
I stand corrected, the tag isn't encrypted in RFC 8439. (You can do it that way, but AEAD_ChaCha20_Poly1305 doesn't.) In any case the article doesn't mention single-use keys.
1 reply 0 retweets 1 like -
Replying to @feministPLT @FiloSottile
It's confusing now that I look more closely. The key can only be used once ... but that's not a nonce? ok it's not public .. so we have a "konce" which fragiley combines secrecy of keys and uniqueness of nonces .. so the AEAD uses the Salsa20 derived key? That's encryption!
1 reply 0 retweets 0 likes
O.k. o.k. it's more like KDF than encryption .. but it still seems like it probably makes naked Poly1305 unsafe. Safe key reuse is a totally standard capability of cryptographic primitives.
-
-
Replying to @colmmacc @FiloSottile
I wouldn't say it's a problem with Poly1305 itself, but the requirement for single-use keys is uncommon enough that it should certainly be reiterated whenever Poly1305 is described.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.