[jira] [Commented] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption

["Andy LoPresto (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164087#comment-17164087 ] 

Andy LoPresto commented on NIFI-7668:
-------------------------------------

The specific algorithm introduced in NIFI-7638 also introduces a ~1 sec delay in every encryption operation (which occurs during every flow synchronization and serialization to disk) due to the Argon2 KDF process. This is an acceptable tradeoff for security-conscious users at this time, but can be improved through a key caching mechanism in memory TBA. 

> 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
>            Priority: Major
>              Labels: aead, configuration, encryption, pbe, security
>
> 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)