[Cryptography] Evaluating draft-agl-tls-chacha20poly1305

William Allen Simpson william.allen.simpson at gmail.com
Tue Sep 10 22:59:05 EDT 2013


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.



More information about the cryptography mailing list