Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard implementation option #153

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

masihyeganeh
Copy link
Contributor

Added an option to use the implementation in the spec
also added an option to omit username when calculating X

It's a draft implementation to start conversation on it.
Please let me know what you think about it.

closes #152

srp/src/utils.rs Outdated
Comment on lines 65 to 67
// M1 = H(H(N) XOR H(g) | H(U) | s | A | B | K) this follows the spec
#[must_use]
pub fn compute_m1_std<D: Digest>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Spec" doesn't say which spec, and std in particular is easily confused with the Rust standard library.

Perhaps use RFC5054 instead?

Suggested change
// M1 = H(H(N) XOR H(g) | H(U) | s | A | B | K) this follows the spec
#[must_use]
pub fn compute_m1_std<D: Digest>(
/// M1 = H(H(N) XOR H(g) | H(U) | s | A | B | K) following RFC5054
#[must_use]
pub fn compute_m1_rfc5054<D: Digest>(


/// SRP client state before handshake with the server.
pub struct SrpClient<'a, D: Digest> {
params: &'a SrpGroup,
by_the_spec: bool,
no_user_in_x: bool,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this a separate variable?


/// SRP client state before handshake with the server.
pub struct SrpClient<'a, D: Digest> {
params: &'a SrpGroup,
by_the_spec: bool,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An enum might be nice here for clarity

@masihyeganeh
Copy link
Contributor Author

OK, I decided to change my implementation completely.
Sorry, but your comments are outdated now.
Instead of choosing the implementation in the instantiation phase, I decided to go with having two different process_reply and process_reply_rfc5054 method.
The thing is that RFC5054 calculates M1 (and accordingly M2) using session_key (hash of premaster secret) instead of the premaster secret, so I had to define SrpClientVerifierRfc5054 and SrpServerVerifierRfc5054 beside SrpClientVerifier and SrpServerVerifier that also returns the session_key.
We can have this extra field in those structs, but I believe it would be a breaking change.
I leave it to you to decide.

Please review this new code and let me know you like this approach better or not.

Thanks

m1: Output<D>,
m2: Output<D>,
key: Vec<u8>,
session_key: Vec<u8>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can use D::Output for session_key.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think we can use D::Output as long as we have a getter method that returns this in a more primitive type, because at least in my use-case, this session key is used for every encryption after the key agreement.
It is nicer to hide away all these types used internally before the output

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

srp: why M1 is not calculated according to the spec?
3 participants