[jira] [Created] (NIFI-12033) Add Processors Supporting age-encryption.org

["David Handermann (Jira)" <ji...@apache.org>]

David Handermann created NIFI-12033:
---------------------------------------

             Summary: Add Processors Supporting age-encryption.org
                 Key: NIFI-12033
                 URL: https://issues.apache.org/jira/browse/NIFI-12033
             Project: Apache NiFi
          Issue Type: Improvement
          Components: Extensions, Security
            Reporter: David Handermann
            Assignee: David Handermann
             Fix For: 1.latest, 2.latest


The [age-encryption.org/v1|https://age-encryption.org/v1] specification provides a modern alternative to protocols such as OpenPGP for encrypting and decrypting files. The age specification uses [ChaCha20-Poly1305|https://en.wikipedia.org/wiki/ChaCha20-Poly1305] for authenticated encryption of file payloads, and supports asymmetric key pairs using the [Curve25519|https://en.wikipedia.org/wiki/Curve25519] algorithm with Diffie-Hellman key exchange, known as X25519. The age X25519 recipient type represents public and private keys using a human-readable encoding named [Bech32|https://en.bitcoin.it/wiki/Bech32]. The age command is available on all modern operating systems. These security and usability properties make it a better solution for file encryption use cases than current custom processing strategies in Processors such as EncryptContent.

The [Jagged|https://github.com/exceptionfactory/jagged] project provides an implementation of the age encryption specification for Java. New EncryptContentAge and DecryptContentAge Processors should be implemented that support the X25519 recipient type, with options for property-based or file-based keys. The age standard supports ASCII armored encoding, which is helpful for some use cases that cannot handle raw binary. The default file encoding setting should be binary for optimal size and performance characteristics.

Java 11 and 17 support ChaCha20-Poly1305 and X25519, but Java 8 requires another Security Provider, such as Bouncy Castle. Cryptographic algorithm support can be checked at runtime to support transparent fallback to Bouncy Castle. These new Processors should be functional on both the support branch and main branch to provide a migration path from other solutions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)