why does DJ Bernstein advocate using a counter for r (see section 3 of the poly1305 paper)? this RFC uses a random value (derived from the one-time key), which seems reasonable to me (i think there are 106 bits available, so you're getting a collision in 53 bits, which at 1000 connections a second is over 10^5 years).
just seems odd to go to the effort of specifying how to safely implement a counter in some detail in the paper when a random value seems fine (it's also quite possible i've misunderstood something - these are all new to me).
The paper specifies Poly1305-AES, which is a little different.
In Poly1305-AES, the point at which the polynomial is evaluated (r) is random, but the value added at the end is calculated as AES_k(nonce). Basically, AES was used to map from a counter to a secret value. It's very important that that value not be reused, because the security the system falls apart.
In my draft, I'm not using AES. Rather I use a block of ChaCha20 to generate the value to add at the end and a different r value for each message.
But there is essentially the same problem: an nonce still needs to be fed into the cipher and it must not repeat. (Additionally, repeating the nonce here breaks confidentiality too as the keystream will repeat and the attacker gets the XOR of the two plaintexts.)
TLS already has a counter for this, which is used here.
(Alternatively, some AES-GCM implementations in TLS use an 8-byte, random value as the nonce, which stands a good chance of repeating after 232 records :( )
As far as I have understood the draft in the context of my mental model of TLS, there already is a counter available for every message to prevent replay attacks. And if you get one for free then using it is definitely better than using a random number.
Comments
why does DJ Bernstein advocate using a counter for r (see section 3 of the poly1305 paper)? this RFC uses a random value (derived from the one-time key), which seems reasonable to me (i think there are 106 bits available, so you're getting a collision in 53 bits, which at 1000 connections a second is over 10^5 years).
just seems odd to go to the effort of specifying how to safely implement a counter in some detail in the paper when a random value seems fine (it's also quite possible i've misunderstood something - these are all new to me).
The paper specifies Poly1305-AES, which is a little different.
In Poly1305-AES, the point at which the polynomial is evaluated (r) is random, but the value added at the end is calculated as AES_k(nonce). Basically, AES was used to map from a counter to a secret value. It's very important that that value not be reused, because the security the system falls apart.
In my draft, I'm not using AES. Rather I use a block of ChaCha20 to generate the value to add at the end and a different r value for each message.
But there is essentially the same problem: an nonce still needs to be fed into the cipher and it must not repeat. (Additionally, repeating the nonce here breaks confidentiality too as the keystream will repeat and the attacker gets the XOR of the two plaintexts.)
TLS already has a counter for this, which is used here.
(Alternatively, some AES-GCM implementations in TLS use an 8-byte, random value as the nonce, which stands a good chance of repeating after 232 records :( )
For anyone wondering, Cryptography in NaCl [1] goes in to some detail about the benefit of generating a per-message r vs a static r in section 9.
[1] http://cr.yp.to/highspeed/naclcrypto-20090310.pdf
2^32 I assume? 232 seems a little small :)
As far as I have understood the draft in the context of my mental model of TLS, there already is a counter available for every message to prevent replay attacks. And if you get one for free then using it is definitely better than using a random number.
How do you know the random value used by the other end is actually random, and not backdoored?