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 :( )
Comments
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 :)