Browse Source

Minor touchups to README.md

Ian Goldberg 3 months ago
parent
commit
ceaebe7dc1
1 changed files with 3 additions and 3 deletions
  1. 3 3
      README.md

+ 3 - 3
README.md

@@ -55,7 +55,7 @@ For the 1-of-2 OT protocol, we base it on the simple one from the 1989 paper of
 
   * Mihir Bellare and Silvio Micali, "Non-Interactive Oblivious Transfer and Applications".  CRYPTO 1989.  paper: [https://cseweb.ucsd.edu/~mihir/papers/niot.pdf](https://cseweb.ucsd.edu/~mihir/papers/niot.pdf)
 
-We slightly optimize the protocol in that instead of the client sending both β0 and β1 to the server, and the server checking that their sum (in elliptic curve terms) is C, the client just sends β0 and the server computes β1 = C-β0.  In addition, the server sends back the two keys ElGamal-encrypted to the keys β0 and β1, where the client can know the private key for at most one of them.  Bellare and Micali's paper does this as (r0\*G, H(r0\*β0) XOR K0, r1\*G, H(r1\*β1) XOR K1), whereas we use the slightly more efficient (r\*G, H(r\*β0) XOR K0, H(r\*β1) XOR K1).
+We slightly optimize the protocol in that instead of the client sending both β0 and β1 to the server, and the server checking that their sum (in elliptic curve terms) is C, the client just sends β0 and the server computes β1 = C-β0.  In addition, the server sends back the two keys ElGamal-encrypted to the keys β0 and β1, where the client can know the private key for at most one of them.  Bellare and Micali's paper does this as (s0\*G, H(s0\*β0) XOR K0, s1\*G, H(s1\*β1) XOR K1), whereas we use the slightly more efficient (s\*G, H(s\*β0) XOR K0, H(s\*β1) XOR K1).
 
 ## Running the code
 
@@ -74,7 +74,7 @@ To run the Rust test program:
 
 `./target/release/spiral-spir 20 4 100 2`
 
-TO run the C++ test program:
+To run the C++ test program:
 
 `./cxx/spir_test 20 4 100 2`
 
@@ -90,7 +90,7 @@ Here:
     most the number of preprocessed queries, and defaults to that
     number
   
-Each entry is 8 bytes.  There are three phases of execution: a one-time Spiral public key generation (this only has to be done once, regardless of how many SPIR queries you do), a preprocessing phase per SPIR query (this can be done _before_ knowing the contents of the database on the server side, or the desired index on the client side), and the runtime phase per SPIR query (once those two things are known).
+Each entry is 8 bytes.  There are three phases of execution: a one-time Spiral public key generation (this only has to be done once, regardless of how many SPIR queries you do), a preprocessing phase per SPIR query (this can be done _before_ knowing the contents of the database on the server side, or the desired index on the client side, as as above, the preprocessing for all of the SPIR queries are all done in a single round trip), and the runtime phase per SPIR query (once the contents of the database and the desired index are known).
 
 A sample output (for r=20, 4 threads, 100 preprocessed SPIR queries, 2
 SPIR queries performed):