Missing hash functions

[newpavlov]

List of "would be nice to have" hash functions:

• BLAKE add blake #46
• cSHAKE
• ParallelHash
• FSB FSB hash function #256
• Grøstl Implemented Grostl #10
• JH JH hash implementation #484
• HAS-160
• KangarooTwelve Add k12 #45
• Kupyna
• MarsupilamiFourteen (section 5, also see Rust and C versions of KangarooTwelve and MarsupilamiFourteen  XKCP/XKCP#54)
• MD2 Added MD2 hash function #7
• MD6
• Poseidon
• Poseidon2
• RIPEMD-128
• Skein Skein hash implementation #483
• Tiger add tiger hash from https://gitlab.com/rawler/tiger #229
• VSH

It can be changed based on discussion.

[adrianbrink]

MD2 explanation
General information from wikipedia

The first link has an example of an implementation in C of MD2. Overall the implementation is around 100 lines of code and hence should be doable for anyone that knows a bit of rust.

[felipeamp]

I am somewhat new to Rust but I believe I can do this. Can I take MD2?

[newpavlov]

Moved Grostl discussion to #8.

[faineance]

I'd like to take a shot at Tiger.

[cseale]

I'll take a shot at MD6

[lilianmoraru]

I think bcrypt is a must-have.

[tarcieri]

bcrypt is a password hashing function. Perhaps those deserve their own toplevel project, as they are functionally different from hash functions (among other things they are PRFs, not hash functions)

[newpavlov]

@lilianmoraru
There is already bcrypt crate, but it needs a bit of work before publishing. And as tarcieri mentioned, bcrypt is better to be placed in the different repo. I was thinking about RustCrypto/kdf and I was planning to work on it after I'll finish with block modes for block ciphers. (bcrypt depends on blowfish after all)

[tarcieri]

nit about "kdf": bcrypt isn't a KDF

[newpavlov]

I think it's "close enough". Also wiki. Either I am open to suggestions, but I think it's better to continue this discussion in the IRC.

Edit: after discussion I think we will go with "password-hashing" instead of "kdf"

[lilianmoraru]

@newpavlov There is also this implementation and this one(which seems better but I'd switch it from trait IntoBcryptSetup to the yet nightly TryInto/TryFrom).
The second also has the 72 bytes limit on the password... I'd rather go with SHA512 + bcrypt(512 bit as input from SHA512) - that's why I also thought that bcrypt would be good in combination with these crates, otherwise you'd have to recommend any random SHA crate, without a specific example of correct usage.

[newpavlov]

Thank you for the links! I will definitely check them!

[pedrocr]

+1 for KangarooTwelve, seems like a great option for hashing files very quickly for content addressable filesystem situations (e.g., git, backups, etc).

[tarcieri]

Of this list, KangarooTwelve is the only one I'm even remotely interested in.

[rubdos]

+1 for KangarooTwelve.

Is it a good idea to add the TupleHash family too?

[spebern]

Hi,

Are you interested in Shabal?
I have an implementation that would be fully compatible with
the library. (https://github.com/spebern/shabal-rs)

All the best

[newpavlov]

@spebern
Yes, please submit a PR if you'll have time!

[felixrabe]

Current link for KangarooTwelve: https://keccak.team/kangarootwelve.html. (Old link redirects there.)

[myers]

Any interest in TTH?

[tarcieri]

Sure. It seems like you could put it in the tiger crate (possibly feature-gated)

[vschwaberow]

I would like to propose the hash algorithm Argon2 for inclusion in RustCrypto.

[tarcieri]

We have an Argon2 implementation here: https://github.com/RustCrypto/password-hashes/tree/master/argon2

[vschwaberow]

We have an Argon2 implementation here: https://github.com/RustCrypto/password-hashes/tree/master/argon2

Oversaw it. Thanks for the link.

[dcow]

Is the blake3 crate something that should be moved here https://github.com/BLAKE3-team/BLAKE3? I know it does runtime cpu detection and calls out to hand-tuned asm so that may be a problem. But it does work fine without the asm and has a pure feature (which is for "testing only" at the moment) that disables any of the assembly.

[tarcieri]

If the BLAKE3 team is interested in doing that, we'd love to have it. But they may not want to.

They do implement traits from the crypto-mac and digest crates, which means they're otherwise "compatible" with the other RustCrypto crates.

[iquerejeta]

I've published a PR for the implementation of the FSB hash function. Seems to work as expected compared to the reference implementation. It still does not have the testing framework in the rest of the crates, nor the quality standards (code style, optimisations, proper README and documentation), but I'd be happy to change that and maintain if you want to include this implementation in the crate.

[gavadinov]

I have implemented the RIPEMD-256 hash function based on the existing RIPEMD-320 in RustCrypto - https://github.com/gavadinov/ripemd256
I would love to get some feedback on it and possibly move it to this project 🤞

[tarcieri]

@gavadinov great! if you open a PR to this repo, we can review it

[gavadinov]

@tarcieri done: #278

[ethindp]

Any chance we can get IFSB, RFSB, and S-FSB? Wikipedia indicates nothing about IFSB's performance, but states that S-FSB is 30 percent faster than FSB and that RFSB is 10x faster than FSB-256. I would implement these myself but I have no knowledge of cryptography -- or at least not the mathematics and such. :-(

[elichai]

I've implemented cSHAKE, and I have a few open questions before I can open a PR:

1. Do we want to expose N to the user? I think not, because it's technically reserved for NIST to define new functions.
2. How do the tests work? Is it written anywhere how do I add new test vectors? (what's this "blob" serialization?)

EDIT: Should we open a Zulip stream for RustCrypto? or is there a Discord/Matrix channel somewhere that I can join to ask these kinds of questions?

[newpavlov]

@elichai

Do we want to expose N to the user?

I think we can start without it and potentially expose it later if someone will request it.

How do the tests work? Is it written anywhere how do I add new test vectors? (what's this "blob" serialization?)

The format is described in the blobby crate docs. You can convert hex-encoded files into the blobby format using utility in examples/convert.rs. Input file should contain pairs of input data and resulting hash separated by new lines:

input data 1
hash for data 1
input data 2
hash for data 2

You can create PR with several test vectors and I can convert the rest for you.

Should we open a Zulip stream for RustCrypto?

We already have Zulip (note README badges): https://rustcrypto.zulipchat.com/

[lumag]

RIPEMD-128: #406

[laudiacay]

found an md6 but it's via FFI: this isn't what you want, is it?
https://github.com/nabijaczleweli/md6-rs

tapping in: @nabijaczleweli

[newpavlov]

@laudiacay
Yes, our project is about pure Rust implementations, so an FFI crate would be out of scope.

[ashWhiteHat]

How about poseidon hash?
https://eprint.iacr.org/2019/458.pdf
Not mainstream?

[newpavlov]

@ashWhiteHat Added.

[ashWhiteHat]

Thank you!

[Saphereye]

HAS-160 Specification
HAS-160 Specification pdf

The original specification has been taken down, so I have linked to the wayback machine page. I have also updated the link on the wikipedia page of HAS-160. The paper also contains pseudocode and explains the algorithm in-depth.

[ethanbarry]

I see POSEIDON in here, and I'm interested in working on it for GSoC, but while I was researching it, I found this recent video on their faster version of the hash function. It uses a special matrix to speed up multiplication, and they call it POSEIDON2.

Could this be added to the list?
EDIT: Here's the paper: https://eprint.iacr.org/2023/323

[tarcieri]

I added Poseidon2 to the list as well as a link to the HAS-160 spec