Skip to content
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.

Sign up for GitHub

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

Adding comment which caveats OPRF seed usage #455

Merged
merged 1 commit into from
May 21, 2024
Merged

Adding comment which caveats OPRF seed usage #455

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 24 additions & 2 deletions draft-irtf-cfrg-opaque.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,19 @@ protocols"
seriesinfo: Eurocrypt
date: 2006

DL24:
title: "(Strong) aPAKE Revisited: Capturing Multi-User Security and Salting"
author:
-
ins: D. Dayanikli
name: Dennis Dayanikli
-
ins: A. Lehmann
name: Anja Lehmann

seriesinfo: https://eprint.iacr.org/2024/756
date: 2024

FK00:
title: Server-assisted generation of a strong secret from a password
author:
Expand Down Expand Up @@ -808,8 +821,11 @@ At the end of this interaction, the server stores the `record` object as the
credential file for each client along with the associated `credential_identifier`
and `client_identity` (if different). Note that the values `oprf_seed` and
`server_private_key` from the server's setup phase must also be persisted.
The `oprf_seed` value SHOULD be used for all clients; see {{preventing-client-enumeration}}.
The `server_private_key` may be unique for each client.
The `oprf_seed` value SHOULD be used for all clients; see {{preventing-client-enumeration}}
for the justification behind this, along with a description of the exception in which
applications may choose to avoid the use of a global `oprf_seed` value across clients
and instead sample OPRF keys uniquely for each client. The `server_private_key` may
be unique for each client.

Both client and server MUST validate the other party's public key before use.
See {{validation}} for more details. Upon completion, the server stores
Expand Down Expand Up @@ -2243,6 +2259,12 @@ response during registration as an oracle for whether a given client identity is
registered. Applications should mitigate against this type of attack by rate
limiting or otherwise restricting the registration flow.

Finally, applications that do not require protection against
client enumeration attacks can choose to derive independent OPRF keys for different
clients. The advantage to using independently-derived OPRF keys is that the server
avoids keeping the `oprf_seed` value across different clients, which if leaked would
compromise the security for all clients reliant on `oprf_seed`, as noted in {{DL24}}.

## Protecting the Registration Masking Key

The user enumeration prevention method described in this document uses a
Expand Down
Loading