hdevalence / danake Goto Github PK

§7.3

#18 (comment)

The current API takes a Transcript parameter, as recommended by the Merlin API. This is good because it means that applications can add arbitrary data and are required to give a domain separator. But it also allows the potential for misuse, since if the arbitrary data is identifying, this compromises the anonymity properties of the system.

The current text has all of the required details but they're not well-presented; rewrite them after the whole library is complete.

This corresponds to removing the (WIP) marker on the CMZ13 credentials section in the notes.

§7.4

This is partially done already, but it should have a second pass after the implementation is filled out.

Fill in §7.4.

§7.2

§7.1

#18 (comment)

The domain separators in the protocol description and the implementation could be changed to match the Rust style for module paths, e.g., wallet::rollover::client instead of WalletRollover_Client.

Fill in §7.2.

§6.2

This should exercise the protocol by:

• defining a sequence of "moves" that a client could perform (state transitions),
• defining how those moves affect the client's state,
• writing code that can execute a sequence of moves against a server.

Then this can be hooked up to proptest to do automatic exploration of the protocol's state space.

Fill in §7.3.

Basically this will be a duplicate of the work of #2.

This is described in §6.3. The structure should probably follow along the lines of the topup and issuance protocols, namely, there should be a wallet::rollover module that contains all of the functions, messages, and intermediate states for the rollover protocol.

For instance, in the topup protocol, this ends up with topup::{Request, AwaitingResponse, Response} types, which represent respectively the user's request message for a topup, their state while awaiting a response, and the server's response message. The module has impl blocks on the Wallet and Secrets structs to generate the request and process it into a response respectively. Impl blocks can go anywhere in the module tree, which lets us group the implementations of the functions for each protocol into that protocol's submodule.

Implement §6.1.

Very rough notes:

The epoch mechanism requires that new issuance parameters be generated for every epoch. These issuance parameters may need some number of secret bytes, but since we can symmetrically expand a short secret into as much data as we need, we only have to consider how we generate a secret seed for each epoch.

Loss of key material means loss of availability, since all existing credentials can no longer be verified. Compromise of key material means credentials can be forged.

Forward security for issuance secrets requires that we have additional random inputs, but this cuts against ease of maintaining availability, since if there was no forward secrecy, all keys could be derived from a single seed that can be backed up by the issuer.

For now, deriving all keys from a single seed is the easiest thing to do.

Note: because this is the key schedule for the issuer's side, it's all hidden from the client anyways, so it can be changed later without breaking anything (though doing so in an existing deployment would be awkward / horrible).

As the first "real" test of the zkp crate's API, this is likely to reveal a bunch of places that that API should be changed for the 0.8 release. Fill them in here.

§6.4