[
https://issues.apache.org/jira/browse/NIFI-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12033:
------------------------------------
Fix Version/s: 2.0.0
1.24.0
(was: 1.latest)
(was: 2.latest)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add Processors Supporting age-encryption.org
> --------------------------------------------
>
> Key: NIFI-12033
> URL: https://issues.apache.org/jira/browse/NIFI-12033
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions, Security
> Reporter: David Handermann
> Assignee: David Handermann
> Priority: Major
> Fix For: 2.0.0, 1.24.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
