A way to get a HashFunction backed by a MessageDigest algorithm

[kevinb9n]

Another way to satisfy #3960

[ritikBhandari]

Is MessageDigest the same as MD5 algo?

[lowasser]

MessageDigest includes, but is not limited to, MD5.

[ritikBhandari]

Among these, which MD algo do we have to back HashFunction with? and which one are we currently using?

[lowasser]

HashFunction is an interface with many implementations, including those three (Hashing.md5(), Hashing.sha1(), Hashing.sha256()). Those three are backed by MessageDigest; the others are not.

[lowasser]

The point is that we don't expose a utility in general to allow any MessageDigest algorithm to be used as a HashFunction.

[ritikBhandari]

HashFunction is an interface with many implementations, including those three (Hashing.md5(), Hashing.sha1(), Hashing.sha256()). Those three are backed by MessageDigest; the others are not.

So now do we have to back the other ones as well according to the issue raised?

[lowasser]

No, there's no plan to change other implementations of HashFunction. This issue is just about whether or not we should expose a way to make a HashFunction from any MessageDigest.

[ritikBhandari]

Okay! Got it.
Thank you :)

[nkkolluru]

@cpovirk Is there any documentation as to what label P3 means?

[nkkolluru]

hello! Is the decision to add new API method(s) to Hashing, to support creating a HashFunction from any MessageDigest algorithm taken? Would there be a design process?

[vorburger]

Just FTR for anyone else looking for this in the future, perhaps this analysis could be useful background:

I've poked around this space while wondering whether to add support for more hash functions here e.g. for this (related to the multihash tagged lines of this table, based on jbenet/random-ideas#1) e.g. for the MessageDigest that Guava does not "expose" (intentionally), but which are available at least in the Java 21+ JDK:

• SHA-224, SHA-384, SHA-512/224, SHA-512/256
• SHA3-224, SHA3-256, SHA3-384, SHA3-512 discussed in Support SHA-3 family of functions in Hashing #3960

I ultimately concluded that, at least for my current application, there was really no need for wanting or needing to do this... but YMMV, of course. It probably boils down to whether you (externally) "have" to support certain hash functions, or whether your application can "choose" which one it wants to support.

In the former case, it could be "handy" to implement was this FR suggests. But in the latter (and my) case, I've opted to not support SHA-224, SHA-384, SHA-512/224, SHA-512/256 and stick to SHA-256 & SHA-512, only. (BTW all those are sometimes called SHA-2 sha2-224, sha2-384, sha2-512-224, sha2-512-256 elsewhere; it took at least me a while to dig this!)

As for SHA3-* (and #3960), after reading "sha3 not being a very good choice" here, and noticing https://developers.google.com/tink/protect-data-from-tampering#java (currently) "recommend[ing] the HMAC_SHA256" (=sha2-256), I didn't see any interest in supporting that either by writing a custom Guava HashFunction for it.

Just recording this here in case it could be of interest to other Guava users who are investigating how to add more JDK MessageDigest-based HashFunction implementations in the future - you may or may not actually need & want to do that.