[Enhancement] Parameterization through optional values

[bytemare]

#73 introduced KSF parameters, modified and expanded in #100. This shows that parameterization can be necessary but also highlights there's not an obvious approach to it.

In this issue, I'd like to explore what makes most sense and what can be done to make the API user-friendly and enables dependants, rather than block them.

Core configuration

The core opaque.Configuration structure is meant to represent the minimal necessary definition of an OPAQUE instance, as defined in the current state of the draft.

3.1 Setup states:

client and server agree on a configuration that fully specifies the cryptographic algorithm dependencies necessary to run the protocol.

To me, it makes sense to keep it like so.

Optional parameters

Currently, every protocol step method for both a client and server supports injecting optional values to override default values or using newly randomly generated ones. This holds mostly for the client, as the server only accepts overrides for KE2.

But this leads to API complexity, duplication of some structures (e.g. ClientRegistrationFinalizeOptions and GenerateKE3Options, handling and parsing multiple structures, and ad-hoc adaptions for callers.

Also, for values that need to be reused or persisted, it shifts that responsibility to the caller. That's something I considered ok when designing the first versions of the API. But maybe better support can make the API and usage more robust.

Going further

I'm not sure, yet, what the best approach would be, though I have some ideas. One approach could be to have one structure for the client to hold all these values relative to the client, with an effort to make their usage phase obvious (registration vs. login vs. all-the-time). Their serialization could take an argument to not include secret values (e.g. blind, nonces, keys), but I'm not even sure their serialization is a desirable feature. The essence of OPAQUE is that the client doesn't need any other secret or key than its password, otherwise one might just use mTLS if persistent key material is possible.

@DJAndries and @claucece, since you've had recent experience with that, do you have an opinion on this you'd like to discuss?

[DJAndries]

Also, for values that need to be reused or persisted, it shifts that responsibility to the caller. That's something I considered ok when designing the first versions of the API. But maybe better support can make the API and usage more robust.

IMO, keeping the status quo in regards to caller responsibilities is just fine. It grants each application flexibility in how states and options are serialized, stored, processed, etc.

I'm not sure, yet, what the best approach would be, though I have some ideas. One approach could be to have one structure for the client to hold all these values relative to the client, with an effort to make their usage phase obvious (registration vs. login vs. all-the-time).

Perhaps it would make sense to create a distinct high-level API for what you're describing, while preserving the current lowish-level API. Developers of applications who choose to use the simpler and more standardized high-level API may see benefit in reduced cognitive load when integrating the protocol for their use case. I really like the existing API, so hopefully the solution could either preserve the current API in some way, or preserve the flexibility-related qualities of the current API.

Their serialization could take an argument to not include secret values (e.g. blind, nonces, keys), but I'm not even sure their serialization is a desirable feature.

From my perspective, I don't see any benefit in allowing serialization of those secret values, but you would know better than me. 🙂

[claucece]

One thing that we have also been wondering @bytemare is the ability to pass the OPRF seed from outside (like this brave-experiments@9e22239). What you think?

[bytemare]

Hi @claucece :)
That should be possible through the existing SetKeyMaterial server method. Is that what you're looking for?

[DJAndries]

Hi @claucece :) That should be possible through the existing SetKeyMaterial server method. Is that what you're looking for?

We're trying to find a way to specify the client-specific OPRF seed (we call it the oprf_client_seed). In our fork (see brave-experiments#5 for more information), we added an additional argument to SetKeyMaterial as a quick hack.

In our application, we have a separate "key service" own the main OPRF seed, which executes in a separate compute environment in order to reduce the attack surface for our user-facing service. In other words, we're trying to reduce the risk of theft of the global OPRF seed. This key service takes a credential identifier as input and returns the client-specific seed as output. The main service continues the OPAQUE process using this output.

[claucece]

100% to what @DJAndries said. In the future, we are also thinking on proving the oprf_seed in a threshold manner even. But the idea is:

• Having a separate service that has higher security to be able to store and provide this seed.

What you think @bytemare ?

[bytemare]

Hi 👋
It's very interesting you're taking this approach, as we've only theorised it to be an option, but I haven't tested or deployed it in real life conditions.

That's why I expanded the VOPRF implementation, enabling threshold OPRF on the base mode. It's compatible with a FROST inspired DKG.

The design choice on how to integrate it within OPAQUE is not trivial, though. Ideally, the app running OPAQUE would never even handle any secrets in itself, and run the OPRF and AKE on distributed HSM (but I don't know any HSM that supports common operations on ristretto). So, it could make sense externalising critical key operations and it could look like injecting some sorts of handlers for these steps.

For now, this was too much of a breaking change and without any interest of real-world application I didn't want to over complicate things. This can change, of course.

If I understand correctly, you want to provide this implementation with the user derived seed, after key derivation and before mapping to a scalar. Is that correct? Or do you want to completely outsource that part (KDF + Hash to scalar + OPRF), so you don't have to transmit any direct secret at all?

[bytemare]

My apologies for my delayed response @DJAndries 🙏 I haven't had the time recently to come back to this. How pressing are these things on your side, time-wise?

[claucece]

Thank you @bytemare

That's why I expanded the VOPRF implementation, enabling threshold OPRF on the base mode. It's compatible with a FROST inspired DKG.

For the time being, we are keeping the details on this private ;)

If I understand correctly, you want to provide this implementation with the user derived seed, after key derivation and before mapping to a scalar. Is that correct? Or do you want to completely outsource that part (KDF + Hash to scalar + OPRF), so you don't have to transmit any direct secret at all?

We want to be able to pass the 'oprf_seed' prior to any operation. See the PR: brave-experiments@9e22239

[bytemare]

Hi @claucece and @DJAndries ,

I've had a look at your PR. I'm uncomfortable with adding the client specific oprf seed in SetKeyMaterial, as its intend is to set the generic key material for the server. I don't think that client specific input should be added here.

We want to be able to pass the 'oprf_seed' prior to any operation

Is it acceptable for you to have the derived seed given to RegistrationResponse and GenerateKE2?

[DJAndries]

Is it acceptable for you to have the derived seed given to RegistrationResponse and GenerateKE2?

One alternative to consider: Adding a server method like SetOPRFClientSeed. I figured that since SetAKEState exists (which also contains per-user, session state), it might be appropriate. This could be a good alternative if you want to avoid increasing the parameter count of the methods that you mentioned.

Either solution would be fine for our needs. 😃

[claucece]

what you think @bytemare ? that seems to be better I agree. if you like that one, we can code it up!

[bytemare]

Hi @DJAndries and @claucece,

I'm currently thinking about simplifying the API, with fewer methods and moving parts, and hope I'll get there somehow.
I'm curious, what do you think in providing the OPRF Key for a client directly, instead of its seed?

So you have your seed, derive it into a key on your side, and then provide it to OPAQUE.