Andy LoPresto created NIFI-6669:
-----------------------------------
Summary: 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
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.3.2#803003)
