It bugs me that so many of the input words are mostly zero. Using the TLS Sequence Number for the nonce is certainly going to be mostly zero bits. And the block counter is almost all zero bits, as you note,
(In the case of the TLS, limits on the plaintext size mean that the first counter word will never overflow in practice.) Heck, since the average IP packet length is 43, the average TLS record is likely shorter than that! At least half the connection directions, it's going to be rare that the counter itself exceeds 1! In my PPP ChaCha variant of this that I started several months ago, the nonce input words were replaced with my usual CBCS formulation. That is, invert the lower 32-bits of the sequence number, xor with the upper 32-bits, add (mod 2**64) both with a 64-bit secret IV, count the bits, and variably rotate. This gives more diffusion, at least 2 bits change for every packet, ensure a bit changes in the first 32-bits (highly predictable and vulnerable), and varies the bits affected among 64 positions. Note that I use a secret IV, a cipher key, and an ICV key for CBCS. However, to adapt your current formulation for making your ICV key, ChaCha20 is run with the given key and nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The remainder of the output is discarded. I suggest: ChaCha20 is run with the given key and sequence number nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305. The next 8 bytes of the output are saved to become the per-record input nonce for this ChaCha20 TLS record. Or you could use 16 bytes, and cover all the input fields.... There's no reason the counter part has to start at 1. Of course, this depends on not having a related-key attack, as mentioned in my previous message. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography