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.

[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

[AndersSteenNilsen]

Would multimixer-128 be of any interest? Give me a thumbs up and I'll finnish my PR #591.
It's quite fast. From the paper:

Abstract. In this paper we introduce a new keyed hash function based on 32-bit
integer multiplication that we call Multimixer-128
. . .
There are vector instructions for fast 32-bit integer multiplication on many CPUs and
in such platforms, Multimixer-128 is very efficient. We compare our implementation
of Multimixer-128 with NH hash function family that offers similar levels of security
and with two fastest NIST LWC candidates. To the best of our knowledge, NH
hash function is the fastest keyed hash function on software and Multimixer-128
outperforms NH while providing same levels of security

[newpavlov]

@AndersSteenNilsen
I responded in the PR.

[AnarchistHoneybun]

I have a working implementation of Kupyna_512 (working as in it passes all tests for this mode, as mentioned in the paper).
Would someone be willing to review this code and tell me how it stands against the standards that this repo requires, things like traits it should implement or features it should have, and the like?
Currently it is almost a 1-to-1 implementation of the paper, and I'm yet to add comments to some functions, but it would be great if someone could guide me a bit on this. tia!

edit: typo

[newpavlov]

@AnarchistHoneybun
Can you create a PR? It will be easier to review the code this way. As for traits, you can follow the other crates in this repository, md5 and sha1 will be the simplest to start with. Your current implementation is quite inefficient, migrating to our crates should help with it a bit.

[AnarchistHoneybun]

@AnarchistHoneybun
Can you create a PR? It will be easier to review the code this way. As for traits, you can follow the other crates in this repository, md5 and sha1 will be the simplest to start with. Your current implementation is quite inefficient, migrating to our crates should help with it a bit.

Sure, I'll open a new pr in a bit.
What do you mean when you say "migrating to our crates should help with it a bit"

(ESL, so apologies if this sounds rude, I'm trying to phrase the question but I can't come up with a way to do it without sounding awkward or rude)

[newpavlov]

I meant "migrating to our traits". With them you essentially need to define hash initialization, block compression, and hash finalization. Buffering, data chunking, and everything else will be handled by CoreWrapper. After migrating to the traits your implementation should be completely heap allocation free. Also, do not mind the MAX_MESSAGE_LENGTH limit. We assume that these limits can not be achieved it practice (even with hardware acceleration you will need decades of computations), so we ignore them.

[AnarchistHoneybun]

I meant "migrating to our traits". With them you essentially need to define hash initialization, block compression, and hash finalization. Buffering, data chunking, and everything else will be handled by CoreWrapper. After migrating to the traits your implementation should be completely heap allocation free. Also, do not mind the MAX_MESSAGE_LENGTH limit. We assume that these limits can not be achieved it practice (even with hardware acceleration you will need decades of computations), so we ignore them.

just opened a new pr for it, and I will keep working on the required changes. as for discussion on it, should I open a new issue and link the pr to that, or just under the pr would serve well?

[newpavlov]

You can open a new PR with implementation draft without a separate issue.