Wrapper crate for the srp for easy usage

Overview

The srp crate provides the means for using SRP6a athentication. This crate wraps the srp crate to make the authentication workflows more obvious easy to use.

This is done via the following means:

• provide Workflow structs for the 3 typical workflows:
  • generation of initial registration data
  • client authentication
  • server authentication
• name methods step# with increasing number #, so it is obvious in which phase of the authentication the method needs to be called.
• include automatic random value generation (for ephemeral keys and salt)

Features

• Support for the web via WebAssembly. Therefore, this crate can be used with WASM-based web-UI frameworks like yew.
• Easy to use.

Available rust/cargo features

• client: Include client classes (ClientAuthenticationWorkflow, ClientRegistrationWorkflow, ...).
• server: Include server classes (ServerAuthenticationWorkflow, etc.)
• base64: Include the base64 crate and provide base64 serialization for various byte array parameters.
• serialization: Include the serde crate and add Serialize and Deserialize to various structs. This also enables the base64 feature.
• js: This crate uses the getrandom crate for generating random numbers (salt, client/server ephemeral key). getrandom supports a variety of platforms, including web browsers (in WebAssembly). If easy-srp is used inside the browser, use the js feature to make getrandom use the Crypto.getRandomValues() JavaScript method for random number generation.

Usage

SRP6a protocol

User registration

1. User enters username and password
2. Client generates random salt
3. Client computes verifier from the obove credentials
4. Client sends username, salt and verifier to the server via a secure channel.
5. Server stores these three credentials.

User authentication

1. client sends (username, pub_a) to server.
2. server looks up (salt, verifier)
3. server computes an ephemeral private key b and derives its public key pub_b.
4. server sends (salt, pub_b) to the client.
5. client calculates proof proof_a and sends (proof_a) to the server.
6. server verifies proof_a
7. server computes its own proof proof_b and sends it to the client
8. client verifies proof_b
9. both sides are now able to calculate a common secret key. the size of the key depends on the used digest, e.g. 256 bits (32 bytes) for SHA256

Generate client registration data

Client example

Server example

Dependencies

The following dependencies are included intentionally (aka directly):

• srp
• digest (also included transitively via srp)
• getrandom
• base64 (feature base64)
• serde (feature serde)

Additional dependencies may be included transitively.