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.

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

Implement key sharing #294

Closed
wants to merge 4 commits into from
Closed

Implement key sharing #294

wants to merge 4 commits into from

Conversation

rillian
Copy link
Contributor

@rillian rillian commented Aug 10, 2023

Implement private key import/export so identical instances can be created for horizontal scaling.

In support of brave/star-randsrv#175

Support private key extraction so multiple instances of the same
ppoprf::Server can be created, for example to support a cluster
of indistinguishable instances to scale throughput.

Adds a new `ServerPrivateKey` which can be extracted and converted
to a byte slice. Since it just wraps `RistrettoScalar` I picked this
over serde traits.

Also add a new `ppoprf::Server` contstructor which accepts a
key rather than generating a new one.

NB: This only represents the `oprf_key` field of the `Server`
struct. The `GGM` instance has its own random internal state,
so this commit IS NOT SUFFICIENT for repeatable behavior.
A more complex key structure is necessary.
Confirm the various new methods work.
Verify that a `ppoprf::Server` created from a `ServerPrivateKey`
produces identical output to the original.
@rillian rillian self-assigned this Aug 10, 2023
@rillian
Copy link
Contributor Author

rillian commented Aug 10, 2023

Unfortunately, oprf_key is only part of the key material, as the failing unit test reveals. the GGM instance also has randomly-initialized state we need to export.

One design question is whether get_private_key should return the current PPOPRF state, including punctures, or a fresh copy just as it was initialized. star-randsrv has code to do catch-up puncturing at startup to align the metadata tags with an external schedule, so a fresh copy is fine for that application. However, it somewhat tarnishes the appeal of the proof-of-puncture.

The `ristretto::Scalar` type is an array, which are `Copy` up to 32
bytes, so the clone() call is unnecessary. Addresses a clippy lint.
@DJAndries
Copy link
Contributor

superseded by #384

@DJAndries DJAndries closed this Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants