How close to production is libhydrogen? about libhydrogen HOT 7 CLOSED

I didn't see any significant advantage over Gimli, but seeing more small permutations, and the confirmation that they are viable as a PRF, is encouraging.

from libhydrogen.

Hi Matt!

And thanks for your interest.

The cryptographic constructions are still likely to change. But a great thing in the current design is that this will not affect the API.

For the presently available operations, the current API could be considered stable, if there wasn't still an open question that recently kept coming: shall we type everything?

Currently, a key resembles the following:

uint8_t key[hydro_secretbox_KEYBYTES]

Shall we use a dedicated structure instead?

hydro_secretbox_key key

The main argument favoring this is that it will prevent mixing keys, i.e. a key designed to be used for hashing won't be accept for encryption. People may also be less inclined to use hard-coded keys. It may also help linters.

A counter argument is that raw access to the bytes remains mandatory. It's nice to have opaque structures, but keys still have to be loaded and saved, or copied from previous operations. If the key material is already available somewhere, this would require extra code and copies.

My take on this is that this is not necessary. I rarely saw a key being used in place of another in real world apps, and when it was the case, it was intentional, and if there is a way to work around the type system (and there has to be one), it will keep happening no matter what.

Your input on that subject would be very welcome!

from libhydrogen.

What other structures are there that you want to think about whether to hide or not? For instance ciphertext parcels, password-based hashes?

If you chose one way, but then later decide you wish to add the other for [convenience / safety], which would be easier to add on to the API after the fact?

Also want to look at what encodings might want to be available to pass this data around. Someone, for example, perhaps wants to communicate everything in base64, just as an easy way to make sure it's not mangled by machine / network / decoding boundaries. Or another format which they know they can "safely" get from one place to another with zero hassle. Would using these, for a majority of "simple, one-time use cases (not relying hugly on speed or power consumption)" trump wanting raw data types most of the time?

Answering some of those questions might help you.

My personal interest was trying to find some safe, stable primitives to add to arduino and esp8266/esp32 projects. Currently it seems very little attention has been paid to the situation in that embedded ecosystem, so everything available is a hodge-podge of small personal libraries in which people have copied code for algorithms over and hoped for the best, or even on the official libraries things have been added one-at-a-time, on a as-needed basis, with little consideration paid to consistency or safety in APIs.

Unfortunately I might not be as interested in libhydrogen for this, simply because it is betting the house on a single, extremely new and non-reviewed algorithm. If that algorithm turned out to be a peer-reviewed miracle in 3 years, then libhydrogen could make a lot of sense at that time. But for now I feel some more mainstream elements (such as what was present in the v0 branch) are wanted for a mainstream project.

I saw your comment on a libsodium issue that embedded people might want to use this library instead, but I'm not sure people would want YET to rely on this for embedded projects they might want to deploy and hope not to have to touch again, or only bugfix.

You can see a comment I made suggesting some things for this platform here; I would guess this sort of end goal is what libhydrogen is aimed at, but it could need a lot of time to mature to be considered for such purposes?

from libhydrogen.

Strong typing is really only be useful with keys. But we can't have some functions use byte buffers directly, and other ones use structures. At ABI level, it would work, but it would be very confusing.

Gimli has interesting properties, especially on microcontrollers. But indeed, it's fairly new.

However, it is straightforward to replace that permutation with one that has received more analysis such as NORX or Keccak-p. There is a price to pay (performance, especially with Keccak on software), but this is something that can be a compile-time option. Besides the permutation implementation and the rate&size constants, nothing else needs to be changed, the constructions can remain the same.

Except for compatibility with legacy protocols, primitive soups make less and less sense nowadays, especially in constrained environments. You don't need a dedicated hash function if you have a permutation. You don't need Ed25519 if you already have X25519 (see qDSA as an example). ChaChaPoly's is not ideal on a microcontroller. Its security will be instantaneously destroyed if you don't have a way to generate unique nonces, if there is a bug in your code, or if a power glitch occurs. Argon2 requires way more memory that you will ever have on these systems, and is heavily optimized for modern Intel processors.

from libhydrogen.

Two questions:

• Have you thought about doing Keccak with 12 rounds instead of 24? as is done in KangarooTwelve
• What about keccak-p[400] or keccak-p[800] ?

from libhydrogen.

I didn't consider 24 rounds Keccak even once :)

12 rounds remain slower than Gimli, but recent results posted on the linux-arm list on ARMv8.4 are very exciting. So, the plan remains to keep Gimli by default, but make it simple to replace with NORX or Keccak-p[400], just with a compile-time flag.

from libhydrogen.

Just heard about XOODOO today. Thoughts?

from libhydrogen.