[
https://issues.apache.org/jira/browse/NIFI-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7344:
--------------------------------
Description:
While investigating other issues with encryption services, I had serious
difficulty decrypting some content that had been _encrypted_ in NiFi due to
cipher pad block errors (almost always indicate the use of the wrong key or the
application of a key to the wrong cipher text) and block size errors (indicate
invalid cipher text length).
Through manual analysis, I found that when data is encrypted with
{{EncryptContent}}, the data is encrypted correctly and the right bytes are
written to the content flowfile. In this case, using the following values, the
output should always be 139 bytes. The flowfile size attribute indicates that
correctly, and downloading the flowfile content is exactly 139 bytes. However,
viewing the content in the embedded content viewer results in 140 bytes,
introducing a trailing {{0x10}} byte that should not be there.
So far I have only observed this using the {{Bcrypt}} KDF, and not using the
{{PBKDF2}} KDF. I will continue to investigate if other KDFs influence this
outcome.
For plaintext or JSON/XML content, this is a trivial bug. However, when it
silently modifies binary cipher text, this is a critical, near blocker, issue.
*Plaintext*: \{{This is a plaintext message generated at
${now():format('YYYY-MM-dd HH:mm:ss.SSS Z')}. }} -> Resolves to "This is a
plaintext message generated at 2020-04-08 20:11:44.743 Z. " which is *68* bytes
in UTF-8.
*KDF*: Bcrypt
*Encryption Method*: AES-CBC
*Password*: thisIsABadPassword
The resulting cipher text should be 139 bytes (29 bytes of Bcrypt salt, 8 bytes
of NiFi salt delimiter, 16 bytes of IV, 6 bytes of NiFi IV delimiter, and 80
bytes of cipher text [see below for explanation]).
This flow is not reproducible on {{master}} branch but can be done on NIFI-7122
{{}}branch in my repo.
Cipher text length calculation for AES-CBC:
{code:java}
int plaintextBlockLength = Math.ceil(plaintext.length() / 16.0)
boolean plaintextIsExactBlockMultiple = plaintext.length() % 16 == 0
int cipherTextLength = (plaintextIsExactBlockMultiple ? plaintextBlockLength +
1 : plaintextBlockLength) * 16{code}
Given the above formula, a plaintext of length 68 requires 5 blocks, but is not
an even multiple of 16, so does not require an additional padding block.
Rather, 80 bytes (5 * 16) is used.
was:
While investigating other issues with encryption services, I had serious
difficulty decrypting some content that had been _encrypted_ in NiFi due to
cipher pad block errors (almost always indicate the use of the wrong key or the
application of a key to the wrong cipher text) and block size errors (indicate
invalid cipher text length).
Through manual analysis, I found that when data is encrypted with
{{EncryptContent}}, the data is encrypted correctly and the right bytes are
written to the content flowfile. In this case, using the following values, the
output should always be 139 bytes. The flowfile size attribute indicates that
correctly, and downloading the flowfile content is exactly 139 bytes. However,
viewing the content in the embedded content viewer results in 140 bytes,
introducing a trailing {{0x10}} byte that should not be there.
So far I have only observed this using the {{Bcrypt}} KDF, and not using the
{{PBKDF2}} KDF. I will continue to investigate if other KDFs influence this
outcome.
For plaintext or JSON/XML content, this is a trivial bug. However, when it
silently modifies binary cipher text, this is a critical, near blocker, issue.
*Plaintext*: \{{This is a plaintext message generated at
${now():format('YYYY-MM-dd HH:mm:ss.SSS Z')}. }} -> Resolves to "This is a
plaintext message generated at 2020-04-08 20:11:44.743 Z. " which is *68* bytes
in UTF-8.
*KDF*: Bcrypt
*Encryption Method*: AES-CBC
*Password*: thisIsABadPassword
The resulting cipher text should be 139 bytes (29 bytes of Bcrypt salt, 8 bytes
of NiFi salt delimiter, 16 bytes of IV, 6 bytes of NiFi IV delimiter, and 80
bytes of cipher text [see below for explanation]).
This flow is not reproducible on {{master}} branch but can be done on
{{NIFI-7324}} branch in my repo.
Cipher text length calculation for AES-CBC:
{code:java}
int plaintextBlockLength = Math.ceil(plaintext.length() / 16.0)
boolean plaintextIsExactBlockMultiple = plaintext.length() % 16 == 0
int cipherTextLength = (plaintextIsExactBlockMultiple ? plaintextBlockLength +
1 : plaintextBlockLength) * 16{code}
Given the above formula, a plaintext of length 68 requires 5 blocks, but is not
an even multiple of 16, so does not require an additional padding block.
Rather, 80 bytes (5 * 16) is used.
> Flowfile content viewer appends extra bytes to cipher text
> ----------------------------------------------------------
>
> Key: NIFI-7344
> URL: https://issues.apache.org/jira/browse/NIFI-7344
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI, Security
> Affects Versions: 1.12.0, 1.11.4
> Reporter: Andy LoPresto
> Priority: Critical
> Labels: bcrypt, content-viewer, encryption, kdf, security
> Attachments: Screen Shot 2020-04-08 at 7.54.59 PM.png, Screen Shot
> 2020-04-08 at 8.19.06 PM.png, Screen Shot 2020-04-08 at 8.20.02 PM.png,
> flow_20200408-201821_NIFI-7344.xml.gz
>
>
> While investigating other issues with encryption services, I had serious
> difficulty decrypting some content that had been _encrypted_ in NiFi due to
> cipher pad block errors (almost always indicate the use of the wrong key or
> the application of a key to the wrong cipher text) and block size errors
> (indicate invalid cipher text length).
> Through manual analysis, I found that when data is encrypted with
> {{EncryptContent}}, the data is encrypted correctly and the right bytes are
> written to the content flowfile. In this case, using the following values,
> the output should always be 139 bytes. The flowfile size attribute indicates
> that correctly, and downloading the flowfile content is exactly 139 bytes.
> However, viewing the content in the embedded content viewer results in 140
> bytes, introducing a trailing {{0x10}} byte that should not be there.
> So far I have only observed this using the {{Bcrypt}} KDF, and not using the
> {{PBKDF2}} KDF. I will continue to investigate if other KDFs influence this
> outcome.
> For plaintext or JSON/XML content, this is a trivial bug. However, when it
> silently modifies binary cipher text, this is a critical, near blocker,
> issue.
>
> *Plaintext*: \{{This is a plaintext message generated at
> ${now():format('YYYY-MM-dd HH:mm:ss.SSS Z')}. }} -> Resolves to "This is a
> plaintext message generated at 2020-04-08 20:11:44.743 Z. " which is *68*
> bytes in UTF-8.
> *KDF*: Bcrypt
> *Encryption Method*: AES-CBC
> *Password*: thisIsABadPassword
>
> The resulting cipher text should be 139 bytes (29 bytes of Bcrypt salt, 8
> bytes of NiFi salt delimiter, 16 bytes of IV, 6 bytes of NiFi IV delimiter,
> and 80 bytes of cipher text [see below for explanation]).
>
> This flow is not reproducible on {{master}} branch but can be done on
> NIFI-7122 {{}}branch in my repo.
>
> Cipher text length calculation for AES-CBC:
> {code:java}
> int plaintextBlockLength = Math.ceil(plaintext.length() / 16.0)
> boolean plaintextIsExactBlockMultiple = plaintext.length() % 16 == 0
> int cipherTextLength = (plaintextIsExactBlockMultiple ? plaintextBlockLength
> + 1 : plaintextBlockLength) * 16{code}
> Given the above formula, a plaintext of length 68 requires 5 blocks, but is
> not an even multiple of 16, so does not require an additional padding block.
> Rather, 80 bytes (5 * 16) is used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
