Daninet / hash-wasm

Lightning fast hash functions using hand-tuned WebAssembly binaries
https://npmjs.com/package/hash-wasm
Other
881 stars 49 forks source link

Expose the Argon2 version number constant? #43

Closed getify closed 1 year ago

getify commented 1 year ago

I know this library currently implements version 0x13 (aka 19) of Argon2, which seems like the latest reference version (from 2016?).

I dunno if version 19 is the last version that will ever be released... perhaps?

But to be as future proof as possible, the encoded output already preserves the version number used with a hashed value (along with the salt and params), so that in the future you would either be able to select the proper version from multiple algorithm implementations, or AT LEAST be able to know that your version of the algorithm is mismatched to the version used to create a hashed value.

However, right now, to perform such a check/match of version number, it seems like there's no way to "extract" the current version of the algorithm from this library's implementation, except to attempt a throw-away hashing and parse out the 19 from the encoded output.

That seems rather hacky (and inefficient). I wonder if that version number could be exposed as a property or constant in some way, so that I could just look at the version in an encoded hash output of some message, and compare that to the version exposed on the library, to double-check that it's valid to attempt a match of two hashes.

I'd be happy to provide a simple PR for that, if that seems reasonable?

Daninet commented 1 year ago

I will consider adding that constant in the next version. However, in case of argon2, I recommend using the encoded version only, because it also contains all of the parameters required to validate the hash. You not only need to have the version number there, but also the other parameters like the number of iterations and degree of parallelism.

Daninet commented 1 year ago

Maybe it would be better to implement a new option which returns an object with all of those parameters which are required to validate the hash.

getify commented 1 year ago

As far as I can tell, version is the only non-configurable "parameter", so having it externally helps the check.

On validating an incoming message, I parse the parameters and check that the values are each in a valid/acceptable range, then I use the indicated parameters for the call. But I can't send in a version as part of the parameters.

As an alternative to exposing the version, the parameters could include a version and could check the passed version against the internal one to make sure they match, and return an immediate error if not. That would accomplish my same goal: to validate that it's valid/worthwhile to attempt the hashing before I've paid the cost of doing so (memory/cpu time delay).