`opaque-ke 2.0.0` is not compatible with `Rust 1.81.0` and newer

[vdhanan]

opaque-ke 2.0.0 explicitly pins an older version of voprf that violates the new lifetime rules (rust-lang/rust#117967)

voprf fixed this issue in version 0.5.0: facebook/voprf#131

would it be possible to cut a new release of opaque-ke 2.0 with the latest version of voprf?

also, this issue probably affects the opaque-ke 3.0 pre-release, too, since it also pins an older version of voprf

[kevinlewi]

Hi @vdhanan -- sorry for the delays in replying. This makes sense, however: do you need an explicit new release on top of opaque-ke 2.0, or would it suffice to just include this in an update to the pre-release for opaque-ke 3.0? There are protocol changes between 2.0 and 3.0, and at this point I am hoping it makes sense for applications to work off of 3.0 if they can upgrade.

[vdhanan]

We need a new release on top of 2.0 if possible!

[kevinlewi]

@vdhanan Unfortunately, it won't really be possible to release with the latest version of voprf 0.5 on top of opaque-ke 2.0 since opaque-ke 2.0 pins voprf 0.4.0-pre.3, which is a different (and incompatible) protocol when compared with voprf 0.5.

Hence, I would recommend pulling in the latest pre-release for opaque-ke v3, which I can update to include the latest voprf dependency shortly.

[kevinlewi]

https://crates.io/crates/opaque-ke/3.0.0-pre.5 has been published

[drey7925]

Is there some sort of format conversion we would need to do to make a stored ServerSetup and ServerLogin produced by a v2 client/server work with a v3 client/server?

I tried just changing 2.0.0 to 3.0.0-pre.5 at both the client and the server of my application, and unless I'm doing something wrong on my end, it looks like existing logins no longer work. In case it matters, my parameters are

impl CipherSuite for MyApplicationAuth {
    type OprfCs = opaque_ke::Ristretto255;
    type KeGroup = opaque_ke::Ristretto255;
    type KeyExchange = opaque_ke::key_exchange::tripledh::TripleDh;
    type Ksf = argon2::Argon2<'static>;
}

At least in my case, my application doesn't have any real users yet so I can wipe and recreate everything, but I suspect that there may be other users of this crate that are in the same situation.

I wonder if it may instead be possible/easier to backport the lifetimes fix on voprf 0.4 and then pin the updated voprf 0.4 in a new opaque-ke2.0 release, but I may also be misunderstanding the situation.

[cyyynthia]

There has been breaking changes introduced in the OPRF protocol, so yes all previous records need to be updated somehow (FYI #365 will introduce further breaking changes).

This process of updating records due to such type of changes are mentioned under application considerations, and some valuable discussions have happened over cfrg/draft-irtf-cfrg-opaque#394 (and other issues referenced there) about how to handle such type of updates.

Long story short, the protocol itself doesn't make any recommendation about how to proceed as it's inherently application specific and depends on what your needs are, how you're using OPAQUE, what security needs you have, etc. In all cases, re-registration is required. For live applications, available options include:

• Authenticate using the old record (via an old build of the lib for instance), and perform re-registration
  • Make sure to do it securely, i.e. validating the public key matches. So long it's implemented correctly I think it may be acceptable to do it mostly automatically, thanks to OPAQUE's mutual authentication properties (the server also authenticates itself during the auth flow).
• Drop records and require a re-registration
  • This should always come with another authentication factor, such as via a OTP sent by email or through any other applicable mean. This option is basically a forced password reset, which is an extremely sensitive point of failure and must be secured accordingly. Be careful not to introduce client enumeration risks while implementing such measure.

There's likely more, depending on your needs. Make sure whatever you pick doesn't introduce a problematic point of failure, and that it's safe for your use case. I'm also not necessarily a security expert, so double check the options I've cited if considering them, just in case I missed something obvious (or not so obvious) 😅

[drey7925]

Thanks, that makes sense from a protocol standpoint.

However, to validate both 2.0.0 and 3.0.0, I'd still need to be able to build 2.0.0 (which prevents me from using any new rust versions especially if everything is in one static binary unless a fix is backported to make opaque_ke 2.0.0 and voprf 0.4 build, right?)

[cyyynthia]

That is very true. I opened facebook/voprf#135, so hopefully it can be released as 0.4.1 and opaque-ke 2.x can then be updated to this version without creating breaking changes 🙏🏻

[drey7925]

I tried to prep a patch to pick up the new voprf but ran into CLA issues on my end; would you be able to bump the dependency from this crate to voprf when you have a chance?

[kevinlewi]

https://crates.io/crates/opaque-ke/2.1.0-pre.1 has been released, which should hopefully address this issue -- @drey7925, @vdhanan let me know if this works!