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
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!
-
Show additional replies, including those that may contain offensive content
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.