Verifier local

[themighty1]

A tmp PR to get feedback on the code structure

[sinui0]

Framing

I do not think we can structure the Notarization document around "Rounds", as those are application layer concepts/framing. During the construction of this document the Notary will not have any context, nor should it (for privacy) about the boundaries of messages. A user may send two requests at once, or withhold a response from the Server for some time.

During Notarization I think we have to think of it more like a bidirectional byte stream. We do have some reference of course, the TLS record metadata, ie sequence number, type, length.

Perhaps it can look something like this?

struct OpaqueRecord {
  /// Record sequence number (included in MAC)
  seq: u64,
  /// Record length (included in MAC)
  len: u64,
  /// Encrypted payload
  payload: Vec<u8>
}

/// All the private data held by the User
struct Data {
  // All records sent to the Server
  tx: Vec<OpaqueRecord>,
  // All records received from the Server
  rx: Vec<OpaqueRecord>,

  ...
}

Alternatively we could have the Notary strip the TLS record framing for convenience, then just make sure that they enforce the sequence numbers are contiguous. This may be desirable because there probably won't be much demand for the framing metadata.

/// All the private data held by the User
struct Data {
  // All data sent to the Server
  tx: Vec<u8>,
  // All data received from the Server
  rx: Vec<u8>

  ...
}

Range bounds don't need to be relative to any of the framing. It should all be in the global domain, ie tx[0] is the first byte sent, tx[-1] is the last.

Commitments

If we go with the above structure, then I think it would be a nice simplification (and perhaps more efficient) to just have 2 PRG seeds for the plaintext label commitments. TX + RX.

What's the functional difference between "public" vs "private" commitments? I think I understand that "public" is for data which the User reveals to the Notary so the Notary can sign a commitment directly over the plaintext. I think we can merge this distinction into just another variant in the CommitmentType enum.

[themighty1]

closing, will open a new PR.