AEADUtil: Clarify, that we don't need a dedicated JCA/JCE implementation

[vanitasvitae]

Let me know if you think the reasoning given here does not apply.

[peterdettman]

Firstly, there's already a BcAEADUtil.deriveMessageKeyAndIv with very similar code, so probably this AEADUtil could be deleted. There is also JceAEADUtil.deriveMessageKeyAndIv, with the comment: "TODO: needs to be JCA based".

The purpose of the operator API is to allow a choice in where the backing cryptographic implementations come from. e.g. instead of PGPEncryptedDataGenerator calling AEADUtil.deriveMessageKeyAndIv directly, it would ideally be configured with a KDF operator and call that to perform the derivation.

In general, the JCA/JCE operators further delegate the implementation choice to the Provider configuration. For crypto that lacks a standard JCA API, there's not much point in having a JCA operator, which could essentially only use the BC provider anyway, and so less reason to use an operator at all. Anyway, I think a KDF API was just added in Java 25, so a JCA KDF operator is now possible, and so a suitable operator API should be added in due course.

TL;DR: we actually do want a JCA implementation, in the form of a (new) KDF operator implementation, supporting the new Java 25 KDF API where possible. In the meantime it's OK to use a hardcoded implementation from BcAEADUtil.

[vanitasvitae]

Thanks for the clarification. I'll close this then :)