Prefer libhydrogen for new apps?

[Ramblurr]

(I first wrote this as an issue on the libhydrogen repo, but felt bad because it clearly isn't an "issue", so I'm here on the discussion forum of libsodium instead)

Hi Frank,

Thanks for your efforts on libsodium and your other projects over the years 🙏 .

In the context of providing high-level crypto operations for standard line of business web applications which need:

• password hashing
• session cookie encryption
• database field encryption
• file-at-rest encryption

...libhydrogen can provide all of these^† and indeed over the years you've mentioned you use libhydrogen more than libsodium, and from your positive comments about it leads me to believe that perhaps libhydrogen is a better foundation for apps in the context above to start with.

Those, comments combined with the facts that (1) libhydrogen doesnt accept nonces as input and (2) it has a nice small API that we can expose directly to developers, make libhydrogen a very attractive target for building in at the foundation.

However, there are several things that make us think twice:

• no version numbers / no git tags and no changelog (excepting git history)
  • I expect this is why no major distributions have packaged it
  • and it makes distributing the shared libs a bit scary if version numbers can't be easily compared
  • (especially if Xoodoo replaces Gimli suddenly)
• recent comments from you that hint Gimili might be swapped with Xoodoo (if that happens in 5 years that's fine, if it happens in 2025, that would be a pain)

Do you recommend libhydrogen for the above use cases? If yes, would you consider tagging a version every now and then?

Or is there a "libsodium the good parts" doc/comment somewhere that identifies a subset of the API that is safe and can be exposed to devs directly (though #392 makes me think that might not be in scope for libsodium)?

---

^† the "only" thing libhydrogen doesn't provide which is occasionally useful is libsodium's secretstream for en/decrypting datasets that cannot fit into memory.

[jedisct1]

libhydrogen is great for its portability, simplicity and compactness. It's also a good option on constrained environments.

It doesn't have secretstream, but hydro_secretbox accepts a counter that can simply be incremented after each chunk. This is exactly what encpipe does.

You're right about version numbers. There's been two major versions (v0 and v1), but no minor versions tagged along the way. Even though there haven't been breaking changes, this is something I'll try to do.

As it's a single C file, libhydrogen is usually directly copied into apps, rather than shipped as a library, though.

If performance is a concern, and it seems to be the case according to your list of use cases, libhydrogen may not be a good fit. Especially if you're not targeting constrained environments, libsodiium will be way faster.

[Ramblurr]

Many thanks for the reply, did not expect to me so quickly.

I overlooked that bit of the secretbox api, nice to know in case it's needed.

And yea, just tossing a tag out there every now and then would be great as a sanity check to help us know when to pay attention to changes.

Currently we embed libhydrogen in a library jar, which is working as intended. But from a maintainer's point of view, if I see a new tag of libhydrogen appear that's a nicer signal than having to trawl the commits to see if there's any reason to update.

If performance is a concern, and it seems to be the case according to your list of use cases, libhydrogen may not be a good fit. Especially if you're not targeting constrained environments, libsodiium will be way faster

This part has thrown me...
Can you elaborate on why libhydrogen might actually be slower than libsodium? My (apparently false) understanding was that since libhydrogen targets resource consteaines environments, it would actually be faster (and less memory intensive) than libsodium.

We've used libhydrogen for file encryption where perf wasn't that important, and have liked it a lot, hence the idea to bake it in for more common crypto use cases and reduce our crypto dependencies. But password hashing and cookie verification are definitely perf sensitive.

[jedisct1]

If breaking changes occur, such as replacing the Gimli permutation with a different one, they will be introduced in a separate branch, such as v2.

There are several reasons why libhydrogen (or any library designed to function well in constrained environments) may be slower:

• High performance typically requires more memory. For example, AES-GCM relies on extensive precomputations to achieve good performance.
• libhydrogen is designed to be compact, using only two building blocks for all operations. In contrast, libsodium includes specialized functions for each operation. While this specialization results in a larger codebase and higher memory usage, it also enables better performance.
• libhydrogen is designed to remain secure even on systems that cannot reliably generate random numbers. This necessitates multiple passes over the data. On the other hand, libsodium assumes a system where this issue does not exist.