Missing hash functions

Question

Missing hash functions

newpavlov opened this issue 8 years ago · 49 comments

Answer 1 · 2016-12-29T12:51:33.000Z

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.

Answer 2 · 2017-01-08T20:50:50.000Z

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

Answer 3 · 2017-01-11T10:08:04.000Z

Moved Grostl discussion to #8.

Answer 4 · 2017-01-11T10:50:26.000Z

I'd like to take a shot at Tiger.

Answer 5 · 2017-01-12T22:50:05.000Z

I'll take a shot at MD6

Answer 6 · 2017-06-02T10:15:30.000Z

I think bcrypt is a must-have.

Answer 7 · 2017-06-02T17:31:01.000Z

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)

Answer 8 · 2017-06-02T18:39:00.000Z

@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)

Answer 9 · 2017-06-02T18:40:32.000Z

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

Answer 10 · 2017-06-02T18:52:43.000Z

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"

Answer 11 · 2017-06-02T21:23:05.000Z

@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.

Answer 12 · 2017-06-02T21:37:12.000Z

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

Answer 13 · 2017-07-03T19:57:03.000Z

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

Answer 14 · 2017-07-04T01:12:08.000Z

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

Answer 15 · 2018-03-22T10:06:54.000Z

+1 for KangarooTwelve.

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

Answer 16 · 2019-02-25T19:37:05.000Z

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

Answer 17 · 2019-03-11T13:40:26.000Z

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

Answer 18 · 2019-04-22T14:28:14.000Z

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

Answer 19 · 2021-02-05T16:06:54.000Z

Any interest in TTH?

Answer 20 · 2021-02-05T16:10:51.000Z

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

Answer 21 · 2021-03-16T06:57:38.000Z

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

Answer 22 · 2021-03-16T12:50:25.000Z

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

Answer 23 · 2021-03-16T15:54:23.000Z

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

Oversaw it. Thanks for the link.

Answer 24 · 2021-04-14T17:53:08.000Z

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.

Answer 25 · 2021-04-14T17:58:11.000Z

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.

Answer 26 · 2021-05-02T09:59:12.000Z

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.

Answer 27 · 2021-05-18T16:01:21.000Z

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 🤞

Answer 28 · 2021-05-18T16:07:08.000Z

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

Answer 29 · 2021-05-18T16:47:27.000Z

@tarcieri done: #278

Answer 30 · 2021-10-11T15:05:06.000Z

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. :-(

Answer 31 · 2021-11-09T17:22:20.000Z

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

Do we want to expose N to the user? I think not, because it's technically reserved for NIST to define new functions.
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?

Answer 32 · 2021-11-11T14:49:29.000Z

@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/

Answer 33 · 2022-09-11T07:55:15.000Z

RIPEMD-128: #406

Answer 34 · 2023-01-29T20:37:35.000Z

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

Answer 35 · 2023-01-29T21:29:14.000Z

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

Answer 36 · 2023-11-11T08:41:18.000Z

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

Answer 37 · 2023-11-12T06:24:22.000Z

@ashWhiteHat Added.

Answer 38 · 2023-11-12T06:42:04.000Z

Thank you!

Answer 39 · 2024-02-24T07:59:02.000Z

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.

Answer 40 · 2024-02-26T19:38:46.000Z

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

Answer 41 · 2024-02-26T19:56:34.000Z

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

Answer 42 · 2024-06-15T16:50:48.000Z

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

Answer 43 · 2024-06-17T00:46:30.000Z

@AndersSteenNilsen
I responded in the PR.

Answer 44 · 2024-06-27T07:45:42.000Z

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

Answer 45 · 2024-06-27T13:50:50.000Z

@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.

Answer 46 · 2024-06-27T13:56:11.000Z

@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)

Answer 47 · 2024-06-27T14:25:11.000Z

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.

Answer 48 · 2024-06-27T16:01:47.000Z

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?

Answer 49 · 2024-06-27T18:47:33.000Z

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