Andy LoPresto created NIFI-7668:
-----------------------------------

             Summary: 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.11.4
            Reporter: Andy LoPresto
            Assignee: Andy LoPresto


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)

Reply via email to