
ChaCha20 and Poly1305 for IETF Protocols - conductor
https://tools.ietf.org/html/rfc8439
======
beefhash
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/cor...](https://github.com/timw/bc-java/blob/feature/simon-
speck/core/src/main/java/org/bouncycastle/crypto/engines/SpeckEngine.java#L264-L272)

[3] [https://www.spinics.net/lists/arm-
kernel/msg633602.html](https://www.spinics.net/lists/arm-
kernel/msg633602.html)

------
FullyFunctional
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?

------
tptacek
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
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
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
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.

