[
https://issues.apache.org/jira/browse/NIFI-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291256#comment-17291256
]
ASF subversion and git services commented on NIFI-7668:
-------------------------------------------------------
Commit 5608f4389aa5509f5c19bbcba207dfc37b5674cc in nifi's branch
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5608f43 ]
NIFI-7668 Implemented support for additional AEAD property encryption methods
- Added support for PBKDF2 and Scrypt property encryption methods in addition
to Argon2
- Refactored StringEncryptor class to PropertyEncryptor interface with
implementations
- Added PasswordBasedCipherPropertyEncryptor and KeyedCipherPropertyEncryptor
- Replaced direct instantiation of encryptor with PropertyEncryptorFactory
- Refactored applicable unit tests to use mocked PropertyEncryptor
NIFI-7668 Consolidated similar methods to CipherPropertyEncryptor
NIFI-7668 Updated AbstractTimeBasedSchedulingAgent with PropertyEncryptor
NIFI-7668 Added support for bcrypt secure hashing algorithm
NIFI-7668 Updated comments to clarify implementation of bcrypt key derivation
Signed-off-by: Nathan Gough <thena...@gmail.com>
This closes #4809.
> Add configurable PBE AEAD algorithms to flow encryption
> -------------------------------------------------------
>
> Key: NIFI-7668
> URL: https://issues.apache.org/jira/browse/NIFI-7668
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Core Framework
> Affects Versions: 1.12.0
> Reporter: Andy LoPresto
> Assignee: David Handermann
> Priority: Major
> Labels: aead, configuration, encryption, pbe, security
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit
> keys) which provided AEAD semantics using Argon2 for key derivation and
> AES-G/CM for authenticated encryption. This solution was a stop gap to allow
> more robust encryption than AES-CBC without modifying the
> {{EncryptionMethod}}, which is a single definition of encryption algorithms
> and (supposed) KDFs referenced throughout the codebase.
> Introducing changes to {{EncryptionMethod}} would have required massive
> regression testing, further support changes to {{EncryptContent}}, encrypted
> repository implementations, multiple documentation changes, etc. This change
> allows for a single custom algorithm which makes reasonable default decisions
> around cost parameters and algorithm selection, meeting the user requirements
> without demanding far-reaching changes.
> Instead, this ticket proposes an intentional enhancement to the
> {{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
> property to complement the existing {{nifi.sensitive.props.algorithm}}
> property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
> PBKDF2) to be specified with custom cost parameters and combined with any
> keyed encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and
> encrypt the flow sensitive properties.
> For backward compatibility, as this is likely to go in a 1.13.0 release, not
> a major release, an existing {{nifi.properties}} file will work fine. If the
> {{nifi.sensitive.props.kdf}} value is not specified, it will not be used,
> which is acceptable for all existing {{EncryptionMethod}} values which are
> already supported by the {{StringEncryptor}} class. If a _new_ algorithm is
> specified (e.g. one of the raw keyed algorithms), the KDF will need to be
> present and will be checked for appropriateness and cost parameter validity.
> No default value changes will be made. Thus, this will only affect
> security-conscious users who explicitly change those values to reflect more
> robust key derivation and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
