What happened to Poly1305AES? Is it obsolete?

Question

I've been told that Poly1305AES is a great choice of MAC for constrained (embedded) environments. I'd checked out DJB's writing on it briefly, and have to say that I found its simplicity likeable, performance convincing & security proofs rigorous enough.

But also, libsodium author has told me today that his library won't support this construction.
Because... "it's not used anywhere". I'm baffled by this scarce an explanation.

I'm also confused, since libsodium does support XChaCha20-Poly1305, and AES sure thing — so it has all the primitive pieces; but won't give the combined construction.

Frank Denis also said:

There is nothing wrong with [poly1305aes], but it's not used anywhere, and it wouldn't have any benefits over existing constructions.

What are those existing constructions? Do I guess correctly, HMAC-SHA2?..

Please shed some light onto the algo; I'm pretty far from advanced cryptography, and this interaction (+ my followup research) only makes me feel "I know that I don't know much".

Answer 1

Poly1305 is a universal hash function. The output of that function cannot be used safely without being encrypted.

In order to encrypt it, any cipher can be used. AES was used as an example in the paper, but the very same paper mentioned:

Users can switch from Poly1305-AES to Poly1305-AnotherFunction, with an identical security guarantee. All the efforts invested in the non-AES part of Poly1305-AES can be reused; the non-AES part of Poly1305-AES cannot be broken.

In fact, even Bernstein didn’t use this function with AES. The first real-world instantiation of Poly1305 was with Salsa20.

Poly1305 is widely used today, mainly with ChaCha20, a Salsa20 variant.

With AES, it never saw much real-world deployment, and Poly1305-AES has never been part of any standards.

GMAC is very similar to Poly1305, but can benefit from hardware acceleration on many platforms that also provide AES acceleration. This is probably the most commonly used construction today.

On constrained systems, constructions such as AES-CCM are better candidates as the AES core function can be used both for encryption and authentication instead of having to implement two completely different functions.

To recap, Poly1305-AES was just an example. That particular example was not used in practice, as standardized and widely deployed constructions with AES already existed. These were either more compact, or eventually got very efficient due to hardware support.

But Poly1305 is good, especially on hardware that lacks what is required to implement GMAC efficiently (carry less multiplication). So, it is used with ciphers that are also efficient without hardware support, not with AES.

Answer 2

What are those existing constructions?

Usually people consider three to four scenarios for authenticated encryption for embedded environments:

• Constrained for ROM + RAM In this case you probably would want to use as few primitives as possible and using something like the EAX or CCM mode to use your block cipher for both authentication and encryption. (Example: Cheap IoT devices)
• Constrained for runtime (w/o accelerators) In this case you can do probably make a better pick than AES by using the 32-bit optimized Salsa / ChaCha stream ciphers with lightweight authentication, e.g. Poly1305 resulting in (X)ChaCha-Poly1305 / (X)Salsa20-Poly1305. (Example: File encryption on old phones)
• Constrained for runtime (w/ an AES accelerator) In this case you probably want to take full advantage of your accelerator und use something like AES-EAX or AES-CCM again or depending on the benchmarks possibly AES-GCM. (Example: Some IoT devices with better silicon)
• Constrained for runtime (w/ AES and carryless multiplication hardware) In this case you would probably just pick AES-GCM (because of the full acceleration of both parts of the operation) unless you had some more exotic requirements like encrypting stupidly large amounts of data or some other constraints (like no message expansion).

To be more concrete: The only case were you probably would prefer AES-Poly1305 over AES-GCM is if you don't have hardware acceleration for carryless multiplication but even then the standards compliance is probably more valuable than the bit of speed you gain by using AES-Poly over AES-GCM. If you don't have AES acceleration there's typically no reason to pick AES-Poly1305 over some only-AES modes like CCM or EAX or some 32-bit optimized ciphers like ChaCha-Poly1305.

Answer 3

Poly1305 today is generally used as part of some AEAD construction alongside Salsa20/ChaCha20, because the key advantage of all of these algorithms is excellent performance in platforms that don't have hardware AES support. Most notably these days, that would be low-end phones and tablets. And one of the big pushers for the standardization and adoption of ChaCha20/Poly1305 has been Google, because many of those are Android devices.

But platforms with hardware AES acceleration generally also have acceleration for GCM, which means that if you're using AES at all there's little incentive to use anything other than AES-GCM.