Provide hash functions in addition to HMAC functions

[adepasquale]

Hello,
any particular reason why you're using HMAC functions (which need a key) and do not offer the possibility of using a plain hash functions?

In other words, would you be interested in a pull request that offers OpenSSL::Digest in addition to OpenSSL::HMAC? 😄

[jordansissel]

I'm open to it.

What's your proposed behavior? If a user specifies a method like SHA256 but without specifying a key we would default to using Digest instead?

[adepasquale]

Yeah @jordansissel, I would do like you suggested.

Another option would be using different method names, like SHA256-digest and SHA256-hmac. This would break existing configurations though, so I don't like it too much.

[atnak]

An empty key defaulting to plain old digests sounds terrific!

I've always wondered why key is required because the documentation doesn't make it clear that fingerprint is actually doing HMAC. I think this is a trap initial users currently run into, because hashes are usually associated with digests rather than HMACs. I think this confusion can be averted if key is made optional in favour of plain digests.

With the apparent deprecation of checksum, I think fingerprint should at least be able to create compatible hashes.

[adepasquale]

Exactly @atnak, I've run exactly into that trap the first time I used this plugin. I had to check out the code in order to better understand the documentation.

[yuri-sergiichuk]

I do also run into same trap with key is not required.

I also agree with @atnak that changing algorithm when key smells really bad.

@jordansissel, @adepasquale IMO, as SHA-256, SHA1, etc are just plain hash functions, better algorithm naming would be to leave current names as plain hash functions and follow commonly used names for HMAC: HMAC-SHA1, HMAC-SHA-256, etc.

[adepasquale]

as SHA-256, SHA1, etc are just plain hash functions, better algorithm naming would be to leave current names as plain hash functions and follow commonly used names for HMAC: HMAC-SHA1, HMAC-SHA-256, etc.

@IuriiSergiichuk I agree with you about the bettern naming, but as this will break existing configurations I think it would be better to use *-digest and *-hmac to make it more explicit.

SHA1-digest
SHA1-hmac
SHA256-digest
SHA256-hmac

@jordansissel Any more thoughts about the issue? Can I send you a pull request?

[jakelandis]

I just re-discovered this ...

Spoke briefly with @suyograo on this subject, and was about to log the issue (till I found this one).

Basically, rather then changing the configuration names, simply use HMAC if the key is present, Digest otherwise. While not as explicit, it can be implemented passively.

---

For all but the MURMUR3 hash algorithims (SHA1, SHA256, SHA384, SHA512, MD5), a key is required.

If not provided, the following error will occur upon startup:

Cannot register filter fingerprint plugin. The error reported is:
Key value is empty. Please fill in an encryption key

We should allow for the absense of of the key, yet still support the hashing algorithms. For example, when a key is provided, the HMAC-SHA1 will be used, and when a key is not provided, simply use SHA1. I don't believe that there is any performance difference using the keyed version or not. However, if the filter is used soley for collision free uniqueness, as opposed to as a means of cyprotgraphic signature, then a key for the hash is an unecessary configuration option.

Also, we should change the error to refrain from the wording 'encryption' key, in favor of 'cryptographic' or 'HMAC' or 'signature' key since hashing is not encryption.

[praseodym]

Opened a PR to fix this: #37

[jakelandis]

This has been released in 3.2.0 of the plugin.

To update run the following command:

bin/logstash-plugin update logstash-filter-fingerprint

Thanks again @praseodym !