# Tag Info

5

The first 32 bytes of XSalsa20 output are used as key for the one-time-mac Poly1305. Poly 1305 needs a new 32 byte key for each message, using part of the key-stream is a natural way to obtain those. Requiring those empty bytes makes implementing the API easier. The implementer only needs to call XSalsa20 on the zero padded input buffer once, receiving both ...

4

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 ...

4

No, they are not distinguishable from random. The Poly1305-AES authenticator is defined as: $$(((c_1 r^q + c_2 r^{q−1} + ... + c_q r^1 ) \bmod {(2^{130} - 5)}) + \operatorname{AES}_k (N)) \bmod 2^{128}$$ Since it is the sum of an AES output and some other number modulo $2^{128}$, it is PRF if: the AES output is PRF and the two numbers are independent. ...

3

Numbers get represent as in base 256, i.e. $h = \sum_{i=0}^{17} h_i \cdot 256^i$. Since ints are used which are significantly larger than bytes you don't need to propagate carries immediately. If you forget about modular reduction, then the $i$th digit of the result is computed as $\sum_{j=0}^i h_j\cdot r_{i-j}$. Apart from the lack of carry this is pretty ...

2

I don't know if this is the standard way, but I do know that poly1305 is a single-use-only MAC function. You can never use the same poly1305 key twice for different messages or an attacker could forge MACs, apparently. So this sounds like an easy, safe, and computationally inexpensive way to use the encryption cipher you're going to use anyway to generate a ...

2

I'll follow CodesInChaos's advice. Just for reference, this is what NaCl does (the paper is rather confusing on this): 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). Take the first 16 bytes of the ...

1

$Poly1305_{k,r}(N,M)$ is a Carter-Wegman nonce-based MAC, whose security crucially depends on the uniqueness of nonce $N$ for every message $M$. It is defined as $$Poly1305_{k,r}(N,M) = f(M,r) + AES_k(N),$$ where $f(M,r)$ is a polynomial of $r$ with coefficients derived from the binary representation of $M$, and $AES_k(N)$ is the encryption of nonce $N$ ...

1

$Poly1305_{{r,s}}(m)$ is a one-time authenticator - it can be used to authenticate only a single message with any given key $(r,s)$ without violating the security guarantees (the violation is immediate - only two authenticated messages with the same key are required to create a forgery according to the nacl docs). There are two 128 bit key values to this ...

1

Q2: No, Poly1305 not limited to stream ciphers. Yes, Poly1305 can be used with block ciphers running in CTR mode, if you use it appropriately. I don't know whether the NaCl use is secure (whether NaCl uses it appropriately); I haven't tried to analyze NaCl. Given that NaCl was built by reputable cryptographers, I would be inclined to guess that it's ...

Only top voted, non community-wiki answers of a minimum length are eligible