# Tag Info

10

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

7

Do all TLS cipher suites using "ChaCha20-Poly1305" use Poly1305-AES? Nope, AES is indeed replaced with ChaCha20 in TLS. The Poly1305 one-time key is generated pseudorandomly using the ChaCha20 block function. The ChaCha20-Poly1305 TLS cipher suite spec draft uses the AEAD construction from RFC 7539, which defines exactly how this works: The ChaCha20 ...

7

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

6

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

5

Yes, Poly1305-AES can safely be modified to use AES-256 rather than AES-128; but if AES is implemented in software beware of not introducing a timing vulnerability in the implementation. Change of the cipher in Poly1305-AES is explicitly endorsed; quoting D. J. Bernstein's The Poly1305-AES message-authentication code There is nothing special about AES ...

4

One particularly interesting aspect of Poly1305 is that its security is guaranteed, assuming the underlying cipher is secure. In other words, Poly1305-AES is guaranteed to be secure, as long as AES has not been broken. In the event that AES is broken, AES could be replaced with another cipher, and get a similar security guarantee. DJB talks about his ...

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

You can use methods for hiding the output of the polynomial hash that don't require nonces, such as encrypting with a block-cipher of matching block-size or hashing it with a keyed hash (PRF). Not using a nonce reduces the security bounds (security decreases as the attacker sees more messages using the same key), makes it incompatible with stream ciphers ...

4

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

3

In your link next to the cipher suites with poly1305 you find a link to http://www.iana.org/go/draft-ietf-tls-chacha20-poly1305 That in turn links to rfc7539 which in Section 2.6 describes generating the key for poly1305 using chacha20. So my answers would be: No. It is being used so it's probably and hopefully not a problem.

3

ChaCha20-Poly1305-SIV is not well defined, and does not have the advantages of SIV-mode if you do define it. The SIV mode is essentially MAC-then-encrypt, with the MAC reused as nonce. The MAC in ChaCha20-Poly1305 requires a nonce, because it uses ChaCha20 to encrypt the Poly1305 authenticator (you cannot reveal the raw authenticator). So you cannot use it ...

3

At least in the case of NaCl, Poly1305's "sudden death" properties aren't much worse than XSalsa20's. With any stream cipher, if you reuse the same stream with two messages, then the XOR of the ciphertexts gives you the XOR of the plaintexts. So your security is already ruined by nonce reuse, whether or not you rely on Poly1305.

2

The reason for the padding (and re-positioning of the AAD length) in the later draft is to make implementations easier and faster - i.e. not for a security reason. The rationale for this change was actually documented on the CFRG mailing list by Alyssa Rowan: Instead of the lengths directly following their ciphertexts: ...

2

If you reuse a nonce, you lose confidentiality for the messages with that nonce. Messages with other nonces retain their confidentiality. However, the attacker can also attack the MAC part (Poly1305) and generate a third and more messages with the same nonce. See: Why is Poly1305 popular given its 'sudden death' properties? So unless you have a way ...

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

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