Allow providing (idU, idS) at ClientRegistrationFinish phase (sometimes also named RegistrationUpload in the doc)

[PaulGrandperrin]

As far as I understand the OPAQUE protocol (which is very little..), the idU and idS are only used at the second step of the client processing.
If this is correct, it would be quite nice to be able to provide those values at this time, just when they are needed.

Here is a description of my use case, which I suppose to be quite common:

My users will identify themselves with an email but I also want them to be able to change their email without deleting+recreating their account from scratch.
A common solution to this problem is to assign a unique user_id to each user and then map each emails to a single user_ids.
To make it possible for a user to change its email without redoing the Registration phase of OPAQUE (and therefore asking his password again), the user_id must be used as idU instead of email.
Using user_id as idU also allows users to login with different identifiers, like a unique pseudo or a phone number, another email...

With the current opaque-ke API, I must do one RPC (like rpc::get_user_id_from_email(email: &str) -> UserId) before I can use ClientRegistration::start()...

If the (idU, idS) could be supplied later, I could factor out this RPC like so (pseudocode):

fn rpc::registration_start(opaque_registration_request_bytes: &[u8], email: &str) -> (registration_response_bytes: &[u8], user_id: UUID)

and then go on with the rest of the protocol.

Also as a small aside, it would be nice if you could wait for rand_core to be released in version 0.6 (rust-random/rand#1072) before releasing your 0.3 version. The new version makes it possible to use rand_core::OsRng on wasm.

[PaulGrandperrin]

Some precision:

• The expected benefices are:
  • a simplification of the registration protocol in the use case I described: one less RPC to define
  • lower latency: one less round trip
  • is more transparent about what is needed at which stage / how things really work:
    • less confusing for developers trying to understand the OPAQUE protocol while using this library
    • more flexible to factorize RPCs with other data

It also seems that the password could be provided at the second phase too, I don't see a use case for that now, but more flexibility is probably a good thing.
EDIT: I incorrectly inferred that from tracing the call to CipherSuite::SlowHash... but I now understand that password is indeed used during the first phase through CipherSuite::Hash.

[kevinlewi]

Thank you very much for bringing up this issue! This is an excellent point -- will address this and the rand_core issue as well!