search

briansmith / ring

Safe, fast, small crypto using Rust
Other
3.75k stars 704 forks source link

Add SHA3-256, SHA3-384, and SHA3-512 support #59

Open briansmith opened 8 years ago

briansmith commented 8 years ago

At this point, it doesn't matter if the implementation is particularly fast. It's more important to have a pure Rust fallback implementation than to have the assembly-optimized implementation. There are a few open-source or public domain SHA-3 implementations in Rust already, so it might make sense to integrate one of them.

briansmith commented 8 years ago

Note that NIST SHAVS doesn't seem to publish test vectors for SHA-3 in the same form as they do for SHA-2. They do have some "examples" that should be included in the tests at http://csrc.nist.gov/groups/ST/toolkit/examples.html#aHashing.

ring already has an extensive set of tests for SHA-1 and SHA-2 (SHA-256, SHA-384, and SHA-512). The tests for SHA-3 should be similar.

briansmith commented 8 years ago

Removing good-first-bug. Although it is an easy bug to fix, there doesn't seem to be any demand for SHA-3 right now. See the discussion in #169.

FredericJacobs commented 7 years ago

Hey Brian,

I'm willing to spend some time on a SHA-3 Rust implementation for Ring. Would you be interested to provide feedback and merge the code when you're satisfied with the code?

briansmith commented 7 years ago

We should have a library/application that needs SHA-3 support in ring to justify adding it. If you have a use case, please share it.

My understanding is that OpenSSL is working on a set of optimized SHA-3 assembly-language implementations now. It is almost definitely the case that they are going to have something that is super fast and likely even the fastest implementations. So it seems like it might be better to see what the result of that is before implementing Keccak ourselves, as we are probably better off just using the OpenSSL code.

Besides implementing Keccak, there's also considerations about how SHA-3 would be integrated into the rest of ring. For example, does it make sense to expose HMAC-SHA3-{256,384,512} or should we instead expose (only?) an interface for using keyed Keccak? If we look at #169 and #293, it seems like we may need to generalize the HMAC API (ring::hmac) to accommodate non-HMAC MACs, and similarly we may need to generalize the HKDF API (ring::hkdf) to make it not HMAC-specific in a similar way.

I'd prefer to have any API refactoring happen sooner than later. In particular, if we decide not to expose HMAC-SHA3, then functions that take a &digest::Algorithm like hmac::SigningKey::new(digest_alg: &'static Algorithm, key_value: &[u8]) would be problematic if/when we add SHA-3. So, at the very least, we need to sort this out beforehand.

Thoughts?

heartsucker commented 7 years ago

It seems like there is some interest for Sha3 here: https://github.com/heartsucker/rust-tuf/issues/5. Since ring is the only crypto lib I want to use for this, this ticket would block adding Sha3 to rust-tuf.

rubdos commented 6 years ago

For example, does it make sense to expose HMAC-SHA3-{256,384,512} or should we instead expose (only?) an interface for using keyed Keccak?

I feel like it doesn't really make sense to expose HMAC-SHA3-*, now that we got KMAC. It indeed would mean a new API, I suppose.

I think it makes sense to expose KMAC, even if no-one explicitly needs it yet. For new designs, it makes sense to use Keccak based hashing.

I wonder whether KMAC can perform better than a standard SHA-2 HMAC?

In any case, I am currently working on a new design, and I'm currently using the sha3 crate. I'd rather have this in ring. Can I help getting it in; how do I proceed?

Lemonzyy commented 3 years ago

No news for the implementation of these algorithms? :(