-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shares of even gcm powers can be computed locally. #3
Comments
Let me think about it and double check. What I am not sure is why Basically, if H^2 = H_a XOR H_b, we can say indeed H^2 = H_a + H_b in GF(2^{128}) So, my first impression is that H^4 cannot be simply computed from the "squared" XOR shares of H^2. Let me see if we can find some examples. |
Ah you are right, 2H_aH_b = 0 as always. |
So this clearly is good enough for the semi-honest case. (Are you using it in the semi-honest case?) I will see whether it has an influence on the malicious case. |
My use case is semi-honest. I'm doing block multiplication of 2 by H_a and then block-multiply the result by H_b. Does the result check out for you with real numbers? |
Let me play with the Sage scripts a little bit to confirm it. But often in GF(2^{128}), "XOR" is the same as "+", so 2H_aH_b = H_aH_b + H_aH_b = H_aH_b XOR H_aH_b = 0 Note that GF(2^{128}) is not a prime field with modulus 2^{128}. Rather, it is an extension field of prime 2. |
Ah, that makes perfect sense when written out like that. |
There is an optimization with which we need only 17 block multiplications in MPC in order to compute the whole ghash sequence for the longest possible TLS record size of 16KB. After the parties started out with shares of H^1 and computed other shares locally using the above mentioned free squaring: H2, H4, H8, H16 etc, they proceed to compute H3X3 + H5X5, where H3/5 is H^3/5 and X3/5 are corresponding ciphertext blocks. Expanding:
Let K*_a be all values which Alice can compute locally We'll rewrite the above:
The parties jointly need to compute only the middle cross-terms:
They will compute it in MPC in this way The parties could have computed H3X3 + H5X5 + H9X9 + H17X17 in the same MPC circuit with only 2 block multiplication. Having run the numbers, I see that the best strategy is for the parties to first compute (in MPC) shares of powers 3,5,7,9,11 ..., then apply "free squaring" to those shares and then run the method described above in this post. 6 block multiplications in MPC will give us 239 powers of H. |
This is a very novel observation. Let me calculate how many {H^?} need to be precomputed, and then how many {H^? X^?} are needed... |
Just wanted to make a note here that the technique we discussed here was implemented in the latest version of TLSNotary and described here https://tlsnotary.org/how_it_works#section4 |
Also, to correct my previous statement - the amount of block multiplications needed in 2PC setting to compute 1026 powers of H with the technique and optimizations described in the link above is ~100. (I haven't run the numbers for the MPC setting yet). But then again, those block multiplication can be done with OT which is fairly cheap. |
Sorry for the late reply. I guess when I come back to this project one day, I may need to use a lot of your code. I want to credit you. Let me know what would be the best way: themighty1? Dan from TlsNotary? My email address is w.k@berkeley.edu |
Let H be ghash's encrypted zero.
I noticed that if two parties have XOR shares of H^2 = H_a xor H_b, then
H_a*H_a xor H_b*H_b = H^4
H_a*H_a*H_a*H_a xor H_b*H_b*H_b*H_b = H^8 ... etc for powers 2*2, 2*4, 2*8...
The same can be done if parties start out with shares of H^3, H^5 etc
At the end both parties will have shares of locally computed even powers.
Having to compute only odd powers in MPC, gives a nice 50% reduction.
The text was updated successfully, but these errors were encountered: