# Wrapper crate for the `srp` for easy usage
## Overview
The [srp](https://crates.io/crates/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](https://crates.io/crates/yew).
* Easy to use.
## Available rust/cargo `features`
* `client`: Include client classes (`ClientAuthenticationWorkflow`,
`ClientRegistrationWorkflow`, ...).
* `server`: Include server classes (`ServerAuthenticationWorkflow`, etc.)
* `base64`: Include the [base64](https://crates.io/crates/base64) crate
and provide `base64` serialization for various byte array parameters.
* `serialization`: Include the [serde](https://crates.io/crates/serde) crate
and add `Serialize` and `Deserialize` to various structs. This also
enables the `base64` feature.
* `js`: This crate uses the [getrandom](https://crates.io/crates/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
| `(username, pub_a)` | -> | |
| | <- | `(salt, pub_b)` |
| `(proof_a)` | -> | |
| | <- | `(proof_b)` |
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](https://crates.io/crates/srp)
* [digest](https://crates.io/crates/digest) (also included transitively
via `srp`)
* [getrandom](https://crates.io/crates/getrandom)
* [base64](https://crates.io/crates/base64) (feature `base64`)
* [serde](https://crates.io/crates/serde) (feature `serde`)
Additional dependencies may be included transitively.