Currently in authdecode, the Notary generates random arithmetic labels and encrypts them with binary labels as the keys. Then the ciphertext are sent on the wire.
A better approach would be to just hash the binary label and use the hash as the arithmetic label. Then there is no need for the Notary to send the ciphertexts, since the User can now generate arithmetic labels locally from his binary labels.
Moreover, this approach opens up a possibility to create authdecode zk proofs about the User's request (or even about the server response, if it has a predictabe structure) even before the TLS session starts:
the User knows the plaintext of the request even before the TLS session starts
the User performs OT with the Notary to get the GC input labels for the plaintext
the User hashes the binary input labels and converts them into arithmetic labels
The parties run the authdecode protocol and the Notary reveals all the arithmetic labels to the User. Note that now (for each label pair) the User known his active binary label and only the hash of the other binary label but not the other binary label itself. Thus GC security remains intact.
The User generates zk proofs.
The User does NOT yet send those proofs but just stores them and sends them at the end of the TLSNotary protocol after committed GC and committed OT checks are over.
sinui0
commented
1 year ago
Currently in authdecode, the Notary generates random arithmetic labels and encrypts them with binary labels as the keys. Then the ciphertext are sent on the wire.
A better approach would be to just hash the binary label and use the hash as the arithmetic label. Then there is no need for the Notary to send the ciphertexts, since the User can now generate arithmetic labels locally from his binary labels.
Moreover, this approach opens up a possibility to create authdecode zk proofs about the User's request (or even about the server response, if it has a predictabe structure) even before the TLS session starts: