rustcrypto / pakes Goto Github PK

Let's implement the OPAQUE protocol from this draft

https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/

I'd like to start working on optional no_std support, is there anything major preventing this, and if not, is it the sort of thing you would like to see merged?

There's a typo right in lib.rs: https://github.com/RustCrypto/PAKEs/blob/master/srp/src/lib.rs#L17

RFC5054 refers to RFC2945 for the computation of the 'M' value. However, this implementation does not seem to be following the standard.

'M' should be computed as: M = H(H(N) XOR H(g) | H(U) | s | A | B | K)

But instead, it is computed as: M1 = H(A, B, K)
https://github.com/RustCrypto/PAKEs/blob/master/srp/src/client.rs#L170
https://github.com/RustCrypto/PAKEs/blob/master/srp/src/server.rs#L132

I am not an expert of SRP, but am I missing something? The samples on the wikipedia page match the RFC, but I can't figure out why this implementation differs in that regard.

Thanks for clarifying this portion of the code!

There are methods for much more efficient and cryptographically appropriate modular exponentiation than what is currently implemented.

I'm not familiar enough with the Rust ecosystem to specifically recommend something at this point. (Indeed, I read this code in the hopes of finding the recommended practice.)

Hi team, thanks for your hard work on this library, and so many others.

I'm interested in using the SRP package, and am wondering if you believe it to be production-ready, and what the process would be for getting a third-party audit firm to review it. I have some connections to various well-known firms, but I wonder if you have some in particular that you require.

Thanks!

Hi,

I noticed that the spake2 crate uses HKDF instead of a memory-hard hash function when converting the password to a scalar:

According to the draft specification, as well as this analysis, implementers should use a function like scrypt to slow down brute-force attacks. My guess is that HKDF was used for interoperability with Magic Wormhole's Python implementation, where the one-time nature of passwords means brute force isn't a viable attack. However, this may be a problem for other use cases where a password can be attempted more than once without manual intervention from the other side.

Workarounds include request rate limiting or for callers to send the password through something like scrypt first, using the derived key as input to SPAKE2. However, many users of the library won't know to do this, since the lack of a memory-hard function is not necessarily clear from the documentation.

See https://deps.rs/repo/github/RustCrypto/PAKEs and magic-wormhole/magic-wormhole.rs#114

Hello, I'm writing a client implementation of SRP, but the server I'm connecting to requires that the nousernameinx flag be set. How would I go about doing this, or what would this library have to change to support this?
Thanks!

The SRP crate depends on version 0.8 of the sha2 crate, but version 0.9 has been released since.

I don't know what the Rust convention is, but when I see cargo outdated telling me that there are newer versions of dependencies that we might use, I'm tempted to upgrade. SPAKE2 is currently out-of-date on HKDF and the rand crate.

I've got a PR for spake2's use of HKDF that I'll submit in a minute, but we can't update to rand-0.7 until curve25519-dalek does the same, because the random-element selection API cites a rand_core::CryptoRng trait that must be the same on both sides of the interface.

I haven't looked closely at SRP, but it's behind on both rand (which should be easy) and generic-array (about which I have no idea).

It would be awesome if the function get_password_verifier wouldn't require a client but just had a signature like fn get_password_verifier<D: Digest>(private_key: &[u8], params, &[u8]) -> Vec<u8> or something.

Hello.
I was using your library in my code for a couple of years. I just updated it, and saw that M1 calculation has changed.
I see this comment where it is calculated:

// M1 = H(A, B, K) this doesn't follow the spec but apparently no one does for M1
// M1 should equal = H(H(N) XOR H(g) | H(U) | s | A | B | K) according to the spec

It makes sense that you decided to go with what most of the users prefer, but it is breaking functionality of my code.
I'm suggesting to add those back beside current ones, so there will be a proof() function and maybe a proof_std() that uses standard implementation of M1 calculation, and also there will be a verify_server_std() beside verify_server() that calculates M2 using this new M1.

Or just add a process_reply_std() that returns a SrpClientVerifier with the other M1 and M2.

I can also send a PR if you need me to.
Thanks in advance

In srp/src/server.rs for example, we see

if user_proof == d.result().as_slice() {

where the types are byte slices, &[u8]. I suspect that the same kind of thing appears throughout the code (although I haven't checked).

That will result in a non-constant time comparison, and expose this to timing attacks.

I am new to Rust, so take my suggestion with a large grain of salt. It seems that if we create a trait for secrets and then implement comparison tests for that trait with constant time checks, we could use Rust's type system to enforce that we always have constant time comparisons.

List of "would be nice to have" protocols:

• AuCPace
• CHIP
• CRISP
• OPAQUE
• SPAKE2 (#3)
• SPAKE2+

Why is https://github.com/RustCrypto/PAKEs/blob/master/srp/src/tools.rs#L3 used instead of https://docs.rs/num-bigint/latest/num_bigint/struct.BigUint.html#method.modpow?

I'm going to delete the release tags on spake2 and replace them with signed tags. I had signed tags on https://github.com/warner/spake2.rs , and I forgot to use the -s flag when re-constructing those tags on the new PAKEs repo.

I see SPAKE2+ mentioned in the cargo docs of the SPAKE crate. But it's not implemented yet, is it? It would be cool to have it.