-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
opaque-ke 2.0.0
is not compatible with Rust 1.81.0
and newer
#359
Comments
Hi @vdhanan -- sorry for the delays in replying. This makes sense, however: do you need an explicit new release on top of |
We need a new release on top of |
@vdhanan Unfortunately, it won't really be possible to release with the latest version of Hence, I would recommend pulling in the latest pre-release for |
https://crates.io/crates/opaque-ke/3.0.0-pre.5 has been published |
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
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. |
This is a breaking protocol change, and may also require servers to reset all user passwords. See facebook/opaque-ke#359 (comment) for context
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:
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) 😅 |
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?) |
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 🙏🏻 |
opaque-ke 2.0.0
explicitly pins an older version ofvoprf
that violates the new lifetime rules (rust-lang/rust#117967)voprf
fixed this issue in version0.5.0
: facebook/voprf#131would it be possible to cut a new release of
opaque-ke 2.0
with the latest version ofvoprf
?also, this issue probably affects the
opaque-ke 3.0
pre-release, too, since it also pins an older version ofvoprf
The text was updated successfully, but these errors were encountered: