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