[jira] [Resolved] (NIFI-6669) Allow arbitrary IV values in EncryptContent processor when running in decrypt mode

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

     [ https://issues.apache.org/jira/browse/NIFI-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Handermann resolved NIFI-6669.
------------------------------------
    Resolution: Won't Do

> Allow arbitrary IV values in EncryptContent processor when running in decrypt mode
> ----------------------------------------------------------------------------------
>
>                 Key: NIFI-6669
>                 URL: https://issues.apache.org/jira/browse/NIFI-6669
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: 1.9.2
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Major
>              Labels: encryption, initialization-vector, security
>
> As discussed in the Apache NiFi Slack instance recently:
>  
> {quote}
> [RuthMizzi|https://app.slack.com/team/UN6KDKGMB]  [3 days ago|https://apachenifi.slack.com/archives/C0L9VCD47/p1568103042185700]
> Hello - wondering whether anyone can help me with question I have using the EncryptContent nifi component for decryption of messages received from maxwell daemon .. has anyone ever done this before?
>  
> [Andy LoPresto|https://app.slack.com/team/U0LA8HR55]  [3 days ago|https://apachenifi.slack.com/archives/C0L9VCD47/p1568138070190500?thread_ts=1568103042.185700&cid=C0L9VCD47]
> This won’t work out of the box. Maxwell’s Daemon uses {{AES/CBC/NoPadding}} cipher mode of operation ([https://maxwells-daemon.io/encryption/]), which NiFi does support, but it generates a unique IV and sends both encoded in Base64. The underlying code in NiFi supports unique IVs but it is not currently exposed to the {{EncryptContent}} processor.  I would suggest the following approach:
> 1. Submit a Jira requesting this feature and assign it to me. By adding an optional IV property, we can allow unique input for every decryption operation, and this value can be extracted from the JSON to a flowfile attribute in a preceding {{EvaluateJsonPath}} processor. We will need to eagerly detect Base64 encoding vs. Hex encoding for this input.
> 2. Write an {{ExecuteScript}} processor which consumes the two JSON values and calls simple decrypt logic in Groovy. I can help generate this if you need it.
>  
> [RuthMizzi|https://app.slack.com/team/UN6KDKGMB][9 hours ago|https://apachenifi.slack.com/archives/C0L9VCD47/p1568361404228800?thread_ts=1568103042.185700&cid=C0L9VCD47]
> thanks so much for your detailed response! In the meantime we convinced our data sources to send the data unencrypted but over a secured ssl kafka connection and therefore got around the issue -- but i really appreciate the knowledge shared. Thanks again
> {quote}
>  
> The IV property descriptor should not be required, should support Expression Language, and should detect Base64 and Hex encoded values and validate them against the correct block length for the selected mode of operation via custom validation. 
>  
> We may also want a dropdown of "IV strategies" such as "IV prepended", "IV prepended with delimiter", etc. to handle incoming flowfile content which already has a per-ciphertext IV prepended. 
>  



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