[
https://issues.apache.org/jira/browse/NIFI-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16607701#comment-16607701
]
ASF GitHub Bot commented on NIFI-5147:
--------------------------------------
Github user thenatog commented on the issue:
https://github.com/apache/nifi/pull/2980
Tested out the HashAttribute processor. This all worked fine:
- MD5 and creating a new attribute
- MD5 and overwriting the attribute with hashed value
- SHA256 and creating a new attribute
- MD5 of chinese characters using UTF-8 (matched web tool hasher and
command line md5 utility)
UTF-16 is where I came unstuck:
- MD5 of simple string using "UTF-16" encoding, I get a different hash to
what I expect.
- MD5 of simple string using "UTF-16BE" and "UTF-16LE" encoding DO match
what I expect.
Test input string in all cases: “hehe”
NiFi CalculateAttributeHash:
UTF-8:MD5 = 529ca8050a00180790cf88b63468826a
UTF-16BE:MD5 = b0ed26b524e0b0606551d78e42b5b7bc
UTF-16LE:MD5 = 2db0ecc27f7abd29ba95412feb3b5e07
UTF-16:MD5 = 9b6dcd3887ebdb43d66fb4b3ef9c259b
CyberChef
(https://gchq.github.io/CyberChef/#recipe=Encode_text('UTF16BE%20(1201)')MD5()&input=aGVoZQ):
UTF-8:MD5 = 529ca8050a00180790cf88b63468826a
UTF-16BE:MD5 = b0ed26b524e0b0606551d78e42b5b7bc
UTF-16LE:MD5 = 2db0ecc27f7abd29ba95412feb3b5e07
I found that “UTF-16” is different because when encoding, Java adds a
big-endian BOM: _“When decoding, the UTF-16 charset interprets the byte-order
mark at the beginning of the input stream to indicate the byte-order of the
stream but defaults to big-endian if there is no byte-order mark; when
encoding, it uses big-endian byte order and writes a big-endian byte-order
mark.”_ As expected, adding the BOM changes the output bytes which are then
hashed, resulting in a different hash to “UTF-16BE” encoding. Is this a problem
or is this simply expected behaviour - ie. should the user realize that there
will be a difference between UTF-16 and UTF-16BE encoding and the resulting
hash?
> Improve HashAttribute processor
> -------------------------------
>
> Key: NIFI-5147
> URL: https://issues.apache.org/jira/browse/NIFI-5147
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: 1.6.0
> Reporter: Andy LoPresto
> Assignee: Otto Fowler
> Priority: Major
> Labels: hash, security
> Fix For: 1.8.0
>
>
> The {{HashAttribute}} processor currently has surprising behavior. Barring
> familiarity with the processor, a user would expect {{HashAttribute}} to
> generate a hash value over one or more attributes. Instead, the processor as
> it is implemented "groups" incoming flowfiles into groups based on regular
> expressions which match attribute values, and then generates a
> (non-configurable) MD5 hash over the concatenation of the matching attribute
> keys and values.
> In addition:
> * the processor throws an error and routes to failure any incoming flowfile
> which does not have all attributes specified in the processor
> * the use of MD5 is vastly deprecated
> * no other hash algorithms are available
> I am unaware of community use of this processor, but I do not want to break
> backward compatibility. I propose the following steps:
> * Implement a new {{CalculateAttributeHash}} processor (awkward name, but
> this processor already has the desired name)
> ** This processor will perform the "standard" use case -- identify an
> attribute, calculate the specified hash over the value, and write it to an
> output attribute
> ** This processor will have a required property descriptor allowing a
> dropdown menu of valid hash algorithms
> ** This processor will accept arbitrary dynamic properties identifying the
> attributes to be hashed as a key, and the resulting attribute name as a value
> ** Example: I want to generate a SHA-512 hash on the attribute {{username}},
> and a flowfile enters the processor with {{username}} value {{alopresto}}. I
> configure {{algorithm}} with {{SHA-512}} and add a dynamic property
> {{username}} -- {{username_SHA512}}. The resulting flowfile will have
> attribute {{username_SHA512}} with value
> {{739b4f6722fb5de20125751c7a1a358b2a7eb8f07e530e4bf18561fbff93234908aa9d2577770c876bca9ede5ba784d5ce6081dbbdfe5ddd446678f223b8d632}}
> * Improve the documentation of this processor to explain the goal/expected
> use case (?)
> * Link in processor documentation to new processor for standard use cases
> * Remove the error alert when an incoming flowfile does not contain all
> expected attributes. I propose changing the severity to INFO and still
> routing to failure
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
