SHA1 and MD5

[amitmurthy]

Some of Amazon's APIs, S3 for example, only supports HMAC-SHA1 signatures.

Will libsodium ever include support for creation of HMAC-SHA1 digests?
Also MD5 hashing. Again, it used with AWS S3 to verify correctness of uploaded data.

[jedisct1]

Adding SHA1 and MD5 implementations to libsodium is sad. But required for Amazon APIs and a lot of legacy software. They might be part of the next libsodium version. Only because the only thing that could be possibly worse is using OpenSSL to do that.

[amitmurthy]

:-)
I feel your pain. Maybe you can just hide them in utils!

[stouset]

Why increase the scope of libsodium to support these types of hashes? One of the main draws of NaCl (to me, at least) is that it's extremely focused on fast, quality implementations of high-level cryptographic tasks built on best-of-breed primitives. I don't want to see libsodium turned into yet another library of every crypto primitive under the sun.

If people want a library for building software that's interoperable with broken or outdated primitives, or with completely custom protocols, there are already dozens of existing libraries that are up to the task. In my opinion, NaCl is (and by extension, libsodium should be) about enabling developers to build future cryptographic products.

As for a concrete example of how this may affect perception of this project, on the cryptography StackExchange, people trying to build their own implementations of message authentication and encryption are frequently advised to just use NaCl. I would love to see people begin recommending libsodium instead. But the entire reason NaCl is recommended so frequently is because it makes it difficult for novice cryptographers to go too far off the rails (at least insofar as making obvious, known-bad choices like non-authenticated encryption, appending data to a key before hashing for authentication, or using weak primitives like MD5 or SHA1). Using something like NaCl obviously won't ensure that a novice will get it right, but it can absolutely prevent entire known classes of getting it wrong. And I don't want to see libsodium give up that inherited advantage like seemingly every other crypto library.

Consider also: would you expose an implementation of AES in ECB mode in this library? What about DES? If not, why MD5 and SHA-1? If so, what then is your vision of what differentiates this library from numerous others?

Sorry if this was rambling. I understand if my vision of the library differs from yours (after all, you're the author, it's your project to do with as you like).

[jedisct1]

Nothing has been added yet, and I'm still wondering whether it should be done or not.
Users are encouraged to use high-level operations, not specific primitives and I'm keen to document only the former.

[stouset]

Understood. Just wanted to make my opinions known. :)

[tarcieri]

I am also in favor of not including MD5 and SHA1. Getting people to abandon OpenSSL is an admirable goal, but MD5 is known broken, and SHA1 is in the "walk, don't run from SHA1" brokenness phase.

Blake2b, on the other hand, was an awesome inclusion! SHA3 might also be an appropriate generichash to include, for those who need to do the NIST thing (not me)

[jedisct1]

Ok, these will not be added to libsodium.

[kkimdev]

Random passing by comment: Even algorithms that's considered secure today can be broken over time. I think it will be good to establish "supported" -> "obsolete/insecure" -> "removed" process. If we once have that, then I guess it's OK to put MD5 / SHA in "obsolete/insecure" category.