Update encryption algorithms in Flume appender

[ppkarwasz]

Description

The Flume appender uses:

Cipher.getInstance("AES");

to encrypt messages

In the default Oracle security providers this uses ECB as cipher mode, which:

• does not provide integrity (cf. CIPHER_INTEGRITY),
• does not provide good confidentiality (cf. ECB_MODE).

If Flume supports it, we should replace it with another cipher mode.

Related to #1707.

[jvz]

Related to LOG4J2-2930 where a more general encryption proposal is made. See also LOG4J2-1000 for an older issue around the same idea. Inspired by this, I developed JCryptoBox (see also https://github.com/o1c-dev/jcryptobox) for a simple API around this sort of thing (either a box when both sides have key pairs or a sealed box when only the recipient has a key pair; this can work with X.509 certificates for additional trust anchoring). In general, though, I think the Flume encryption feature should be entirely replaced as there are very few ways to enhance how it works to use cryptography correctly (we need to define the actual protocol in use here; you can't just specify a secret key and expect that to be all you need to do for encryption because we need a way to derive sub keys, a way to derive or encode IVs or nonces, and whether this data is included in the cipher text or if it can be calculated on the fly, amongst other basic aspects of designing a cryptosystem). Note that RFC 5652 provides for a standard for encrypted messages, though I don't think Java has any support for this beyond something like Bouncycastle (CMS APIs are at least part of the standard macOS and iOS APIs, but I'm not sure how widespread they are elsewhere). If this is done for 3.x, then we also have ChaCha20-Poly1305 available. I don't think EdDSA is in Java until somewhere between 11 and 17, so while we can't use one of the easiest cryptosystems available, it's not like we have to implement the crypto primitives (which is itself a fun project if you're into cryptography, but maintaining a large cryptographic library like OpenSSL is a nightmare of ways to shoot yourself in the foot). It might even be necessary to use something like XChaCha20-Poly1305 which offers a much larger nonce, though if there's a way to keep track of how many IVs a certain sub key has used already, then we can fit in the existing AES/GCM nonce max size of 96 bits (which is shit; XChaCha supports up to 192 bits of nonce; don't get me started about newer encryption standards that are even more useful here which was only just standardized recently, but you can get a preview of some of them in https://github.com/o1c-dev/o1c where I experimented with designing an idiot-proof cryptosystem until discovering that it's impossible as cryptosystems should be specific to each use case).

In my proposal was a mention of the use of something like PURB for handling metadata, though that might be overkill, so no need to worry about that for now.