Does Java SunJCE Provider use AES for encrypting nonce in Poly1305?

Question

RFC 8439 states:

AES is used there for encrypting the nonce, so as to get a unique (and secret) 128-bit string, but as the paper states, "There is nothing special about AES here. One can replace AES with an arbitrary keyed function from an arbitrary set of nonces to 16-byte strings."

If an implementation like SunJCE uses AES, ChaCha20-Poly1305 may not have any performance advantage over AES in non-Intel architecture

Answer 1

If we look into the source code of the JDK 11 where this feature was introduced, we can see it is based on RFC 7539, not on RFC 8439. However, a quick look showed that they may be compatible none-the-less.

• although the Poly1305 MAC is defined using AES, the AEAD cipher is not;
• the AEAD construction is defined in section 2.8 and points to 2.6: Generating the Poly1305 Key Using ChaCha20.

So the nonce is taken directly as a parameter, and it is not generated by the application at all. However, the Poly1305 key is generated from this nonce. Note that a MAC does not require an IV or nonce otherwise, only a key. For Poly1305 that key needs to be unique, which is why it is calculated from the nonce used by the ChaCha20-Poly1305 AEAD cipher.

---

So the authentication tag is protected using a ChaCha20 block encrypt rather than AES:

    authenticator = new Poly1305();

    // Derive the Poly1305 key from the starting state
    byte[] serializedKey = new byte[KEYSTREAM_SIZE];
    chaCha20Block(startState, 0, serializedKey);

    authenticator.engineInit(new SecretKeySpec(serializedKey, 0, 32,
            authAlgName), null);

In other words, the ChaCha20Cipher class which implements the ChaCha20-Poly1305 AEAD cipher (using the Poly1305 authenticator class) doesn't mention or reference the AES or any other block cipher.

---

Note that I've previously mentioned in a deleted answer that stream ciphers can generally not be used to perform this kind of key derivation from the nonce. This is correct; however, ChaCha20 operates on blocks underneath, which makes these kinds of operation possible none-the-less.

What was correct in the deleted answer is that the block encrypt for creating the key for Poly1305 is performed only once, so any speed difference between block ciphers to derive the key is inconsequential for larger messages. Only the Poly1305 calculation is performed over the whole message - that's the whole idea of these fast MAC implementations that enable "1.5 pass authenticated ciphers".