4 ms·

ChaCha20 and Poly1305 for IETF Protocols

64 points by conductor 8y ago

tptacek 8y ago
Not to take away anything from Nir and Langley's work here, which I can only assume was heroic, but: - It is insane that this is only being published now. - It is insane if this document means anything or enables anything (other than, I suppose, providing a new, IETF-formatted reference for Chapoly). Chrome has supported Chapoly since (apparently) 2013. Why did it take 5 years to standardize it? Does standardization mean anything? I'm O.K. if the answer is "no, not in any practical sense". (But: see below.)
- gok 8y ago
  This obsoletes another RFC [1] from 2015 and that RFC had many errata [2], so maybe coming up with a non-buggy standard does take time? [1] https://tools.ietf.org/html/rfc7539 https://tools.ietf.org/html/rfc7539 [2] https://www.rfc-editor.org/errata_search.php?rfc=7539 https://www.rfc-editor.org/errata_search.php?rfc=7539
  - tptacek 8y ago
    It is also possible that, as I am heads down in a very tedious code review and coming up for air only to write random HN comments until my brain cools off, that I am just 100% wrong about this. I am prepared to be comically wrong!
    - tialaramex 8y ago
      Yeah, I think not spotting the Obsoletes: header on the RFC header counts as comically wrong. I couldn't have told you the old RFC number off the top of my head, but it's right in the header and I know you know how to read that header. Chalk it up to a neural misfire.
- pera 8y ago
  2013 or 2014? (https://security.googleblog.com/2014/04/speeding-up-and-strengthening-https.html https://security.googleblog.com/2014/04/speeding-up-and-stre...). This RFC is a revision of 7539, which was published in 2015.
  - cesarb 8y ago
    Following the links at the top of the tools.ietf.org interface, you can arrive at the earliest draft of that earlier RFC, which was indeed from January 27, 2014: https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-00 https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305...
- tptacek 8y ago
  Stop upvoting this! I was comically wrong! :)
beefhash 8y ago
I'd just like to take a minute to appreciate the quality of this RFC. You can implement the whole algorithm, start to finish, without referencing anything else for the most part. This is a good quality to have. Nonetheless, this is only really valuable for learning and for toys. In production, you should use existing, tried and true libraries. For an example of a hard-to-implement spec, see e.g. SPECK[1]. The order of everything is confusing: endianness, x/y variables in the pseudocode, and so on[2,3]. [1] https://eprint.iacr.org/2013/404.pdf https://eprint.iacr.org/2013/404.pdf [2] https://github.com/timw/bc-java/blob/feature/simon-speck/core/src/main/java/org/bouncycastle/crypto/engines/SpeckEngine.java#L264-L272 https://github.com/timw/bc-java/blob/feature/simon-speck/cor... [3] https://www.spinics.net/lists/arm-kernel/msg633602.html https://www.spinics.net/lists/arm-kernel/msg633602.html
FullyFunctional 8y ago
I don't understand why they decided to create an incompatible protocol without changing the name. The problem is the reallocation of bits from the block counter to the nonce, which they even admit might be problematic: "The amount of encrypted data possible in a single invocation is 2^32-1 blocks of 64 bytes each, because of the size of the block counter field in the ChaCha20 block function. This gives a total of 274,877,906,880 bytes, or nearly 256 GB. This should be enough for traffic protocols such as IPsec and TLS, but may be too small for file and/or disk encryption." Are you kidding me? WHY, would anyone deliberately put in a flaw that wasn't there originally? And introduce an completely pointless incompatibility?

64 points by conductor 8y ago

Not to take away anything from Nir and Langley's work here, which I can only assume was heroic, but: - It is insane that this is only being published now. - It is insane if this document means anything or enables anything (other than, I suppose, providing a new, IETF-formatted reference for Chapoly). Chrome has supported Chapoly since (apparently) 2013. Why did it take 5 years to standardize it? Does standardization mean anything? I'm O.K. if the answer is "no, not in any practical sense". (But: see below.)

gok 8y ago
This obsoletes another RFC [1] from 2015 and that RFC had many errata [2], so maybe coming up with a non-buggy standard does take time? [1] https://tools.ietf.org/html/rfc7539 https://tools.ietf.org/html/rfc7539 [2] https://www.rfc-editor.org/errata_search.php?rfc=7539 https://www.rfc-editor.org/errata_search.php?rfc=7539
- tptacek 8y ago
  It is also possible that, as I am heads down in a very tedious code review and coming up for air only to write random HN comments until my brain cools off, that I am just 100% wrong about this. I am prepared to be comically wrong!
  - tialaramex 8y ago
    Yeah, I think not spotting the Obsoletes: header on the RFC header counts as comically wrong. I couldn't have told you the old RFC number off the top of my head, but it's right in the header and I know you know how to read that header. Chalk it up to a neural misfire.
pera 8y ago
2013 or 2014? (https://security.googleblog.com/2014/04/speeding-up-and-strengthening-https.html https://security.googleblog.com/2014/04/speeding-up-and-stre...). This RFC is a revision of 7539, which was published in 2015.
- cesarb 8y ago
  Following the links at the top of the tools.ietf.org interface, you can arrive at the earliest draft of that earlier RFC, which was indeed from January 27, 2014: https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-00 https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305...
tptacek 8y ago
Stop upvoting this! I was comically wrong! :)

beefhash 8y ago

I'd just like to take a minute to appreciate the quality of this RFC. You can implement the whole algorithm, start to finish, without referencing anything else for the most part. This is a good quality to have. Nonetheless, this is only really valuable for learning and for toys. In production, you should use existing, tried and true libraries. For an example of a hard-to-implement spec, see e.g. SPECK[1]. The order of everything is confusing: endianness, x/y variables in the pseudocode, and so on[2,3]. [1] https://eprint.iacr.org/2013/404.pdf https://eprint.iacr.org/2013/404.pdf [2] https://github.com/timw/bc-java/blob/feature/simon-speck/core/src/main/java/org/bouncycastle/crypto/engines/SpeckEngine.java#L264-L272 https://github.com/timw/bc-java/blob/feature/simon-speck/cor... [3] https://www.spinics.net/lists/arm-kernel/msg633602.html https://www.spinics.net/lists/arm-kernel/msg633602.html

FullyFunctional 8y ago

I don't understand why they decided to create an incompatible protocol without changing the name. The problem is the reallocation of bits from the block counter to the nonce, which they even admit might be problematic: "The amount of encrypted data possible in a single invocation is 2^32-1 blocks of 64 bytes each, because of the size of the block counter field in the ChaCha20 block function. This gives a total of 274,877,906,880 bytes, or nearly 256 GB. This should be enough for traffic protocols such as IPsec and TLS, but may be too small for file and/or disk encryption." Are you kidding me? WHY, would anyone deliberately put in a flaw that wasn't there originally? And introduce an completely pointless incompatibility?