Conversation
robinhundt
left a comment
robinhundt
left a comment
There was a problem hiding this comment.
Thank you for this extensive documentation! It makes the protocol implementation much easier to understand.
A few of my comments are related to the inputs/outputs of the functions and their corresponding descriptions in the paper. I was wondering, is there a reasoning for these changed interfaces, e.g. why does beaver_aand require authenticated shares from fashare which are then passed down into the callstack, instead of calling it in flaand... and I think I found the answer while looking at the paper, PI_aShare is called directly in Pi_LaAND and also indirectly in Pi_HaAND. The implementation just does one larger call to fashare if I undestand it right.
If that is correct, could you add it to the documentation?
| //! preprocessing is function-independent, meaning the same authenticated shares and multiplication | ||
| //! triples can be used for any boolean circuit of appropriate size. |
There was a problem hiding this comment.
The beaver_aand preprocessing is function-dependent, right? Its input depends on the concrete topology of the circuit and not just its size.
| //! The preprocessing phase generates shares of **authenticated multiplication triples** (x, y, z) where z = x ∧ y: | ||
| //! Each share consists of: | ||
| //! - A secret bit value held by the party | ||
| //! - MACs on the bit values held by other parties | ||
| //! - Keys held by the bit holder for verifying the MACs |
There was a problem hiding this comment.
I think it might be more clear to first mention the authenticated bits which are returned by beaver_aand which internally uses authenticated multiplication triples to derive them. But my understanding might be slightly wrong here.
| //! - [`beaver_aand`]: Transforms random AND triples into specific triples needed for computation, i.e., | ||
| //! where x and y are shares of specific input values |
There was a problem hiding this comment.
The output of beaver_aand is not a triple, but for each AND gate a single authenticated share which is the AND of this gates random input shares (t = r & s in the f_pre functionality of the paper).
|
|
||
| /// Implements the verification step of broadcast with abort based on Goldwasser and Lindell's protocol. | ||
| pub(crate) async fn broadcast_verification< | ||
| /// Performs the verification step of *broadcast with abort* following the |
There was a problem hiding this comment.
As I understand it, this is actually a slight variation of the Protocol 1 on page 16 from the paper which didn't use hashes but the actual messages. Is there something that could be cited for this variant of the protocol?
Alternatively, a note that it is based on this protocol with a link to the paper and short explanation how it is changed would also be good.
| /// Performs a *combined* verified broadcast and scatter. | ||
| /// | ||
| /// Each party provides a vector of tuples `(T, S)`. | ||
| /// - must be *identical across all parties* at each position `k`. |
There was a problem hiding this comment.
| /// - must be *identical across all parties* at each position `k`. | |
| /// - `T` must be *identical across all parties* at each position `k`. |
| /// Transforms random authenticated AND triples into AND triples for specific inputs | ||
| /// using Beaver’s method (https://securecomputation.org/docs/pragmaticmpc.pdf#section.3.4). |
There was a problem hiding this comment.
The inputs and outputs are not triples. beaver_aand takes the random input authenticated shares sampled during the preprocessing (initialized in step 2 in Figure 2, then computed depending on the topology of circuit in step 3 and 4a. This is the alpha_beta_shares parameter, which is actually function-dependent) and it also takes a sufficient number of authenticated shares from fashare which is used as input for fashare (the abc_shares parameter).
The output are the authenticated shares of the AND of the alpha_beta_shares computed using triples, but these are not the result.
| buckets: &[Bucket<'_>], | ||
| ) -> Result<Vec<Vec<bool>>, Error> { | ||
| // Step (a) compute and check macs of d-values. | ||
| // Step (a) Compute and verify d-values for each bucket. |
There was a problem hiding this comment.
In this function, several times the first element of each bucket is XORed with each following element, resulting in vectors of size b-1. Can't we aggregate each bucket into one d share which we reveal and check the MAC of? If secure, this would significantly reduce the communication from this method and likely also reduce the computation.
There was a problem hiding this comment.
If possible, this should be done in a follow up PR, I was just a bit confused by the implementation.
There was a problem hiding this comment.
This is wrong, see the comment in combine_bucket.
| @@ -1102,6 +1346,7 @@ | |||
| } | |||
There was a problem hiding this comment.
See here, where b - 1 elements are pushed to d_values[j].
| for (triple, d) in bucket.zip(d_vec.into_iter()) { | ||
| result = combine_two_leaky_ands(i, n, result, triple, d)?; | ||
| } |
There was a problem hiding this comment.
Now I see why we need all the d values for the pairs in the bucket. This is required for the iterative combination of the leaky ANDs.
|
#350 provides some suggestions for doc clarifications. I'm a bit unsure how to handle the cases where the function parameters don't reflect the protocols in the paper and require authenticated shares to be passed in instead of computed in the function itself. We could make this difference more clear in the docs or refactor the protocols to call fashare internally. This would increase the number of calls to fashare, but I don't expect that to impact performance much. I'm leaning towards improving the documentation. |
polytune: faand doc clarifications
3 participants
This PR adds better docs to the preprocessing part of the protocol, indicating differences from the paper with (!). This is for better understanding of the protocol and better signalling any changes from the paper WRK17b.