Update client and server APIs #62
Conversation
piotr-roslaniec
force-pushed
the
client-server-api
branch
from
2539dfc
to
8d5bef8
Compare
# Conflicts: # Cargo.lock # tpke/src/ciphertext.rs # tpke/src/lib.rs
| Self(dkg) | ||
| } | ||
|
|
||
| pub fn final_key(&self) -> DkgPublicKey { |
There was a problem hiding this comment.
i think i'd prefer a name that made it clear this was a public key
There was a problem hiding this comment.
Could be just public_key
tpke/src/api.rs
Outdated
| aad: &[u8], | ||
| public_key: &TpkeDkgPublicKey, | ||
| ) -> Ciphertext { | ||
| // TODO: Should rng be a parameter? |
There was a problem hiding this comment.
why a parameter? i guess it could make certain tests easier to write, but are there other benefits?
There was a problem hiding this comment.
tpke is a library and api.rs is supposed to be used in bindings. So maybe the library user/bindings user should have the choice of managing randomness themselves. Should the cryptographic library ship with a baked-in source of randomness or should that be left to the user? What if the user of the binding wants to test this library in a controlled environment (with controlled randomness, i.e. a hardcoded seed)?
tpke::api#59ferveo::api#60ferveocrate #56tpke-wasm, client API in TypeScriptferveo-python, server API in Pythonferveo::apiandtpke::apicontain APIs for consumption in client and server APIstpke-wasm,tpke-python, andferveo-pythonuse those APIs to implement concrete APIs with language bindings