6

The Poly1305-AES paper summarizes the MAC as

$$ \mathrm{Poly1305}(m, \mathrm{AES}_k(n)) = {H_r(m) + \mathrm{AES}_k(n)} \mod 2^{128} $$

Can I presume that $+$ here is just meant as a form of 16-byte mixing $H_r(m)$ and $\mathrm{AES}_k(n)$, and that XOR would be equally effective (since both already are 16 bytes)?

Now following from that, if I were to use Poly1305-ChaCha, could I simply append $H_r(m)$ to the plaintext and XOR it with the cipherstream just like regular plaintext? Because the cipherstream is already a function of the key and the nonce this seems safe.

CodesInChaos
  • 25,121
  • 2
  • 90
  • 129
orlp
  • 4,355
  • 21
  • 31

2 Answers2

6

To answer your original question: no, you can't presume that you can replace the addition mod $2^{128}$ within $Poly1305$ with XOR, and not change the security properties (at least, not without some serious analysis).

The security of the MAC depends on the fact that, given any two distinct messages $M_1$ and $M_2$, and any integer $\Delta$, then the following is true only for a limited number of values of $r$:

$H_r(M_1) - H_r(M_2) \equiv \Delta\bmod 2^{128} $

In other words, if you treat this as an equation in one unknown $r$, then there is only a small set of solutions, no matter that $M_1$, $M_2$ and $\Delta$ are (assuming $M_1 \neq M_2$)

If you replace the addition in $Poly1305$ with exclusive or, then the corresponding relationship would be:

$H_r(M_1) \oplus H_r(M_2) = \Delta $

It may be the case that one might be able to find clever values of $M_1$, $M_2$ and $\Delta$ where this holds for a number of values of $r$; if this is possible, then this would cut severely into the security properties.

Now, it is possible that this altered equation also has a bounded number of solutions in $r$; unless someone does some analysis and shows that, it seems unwise to trust it.

poncho
  • 154,064
  • 12
  • 239
  • 382
1

I'll follow CodesInChaos's advice. Just for reference, this is what NaCl does (the paper is rather confusing on this):

  1. Expand the key with the 24 byte nonce into the regular XSalsa20 cipherstream (though it does seem to use some strange key expansion using HSalsa with a 0 nonce as a first step, I have no idea why).
  2. Take the first 16 bytes of the cipherstream as $r$, the next 16 bytes as $c$.
  3. The authenticator of the message is $H_r(m) + c \mod 2 ^ {128}$, the encrypted message is $m$ XOR'ed with the rest of the cipherstream.
orlp
  • 4,355
  • 21
  • 31