PKC’21 is nearly upon us which – in this day and age – means a new YouTube playlist of talks. Eamonn and Fernando wrote a nice paper on on the success probability of solving unique SVP via BKZ which Fernando is describing here:
Alex is presenting our – with Amit and Nigel – work on round-optimal Verifiable Oblivious PseudoRandom Functions (VOPRF) from ideal lattices here:
Since Alex is doing an amazing job at walking you through our paper I won’t attempt this here. Rather, let me point out a – in my book – cute trick in one of our appendices that may have applications elsewhere.
In a (V)OPRF a client – holding – and a server – holding – engage in a protocol to compute where means evaluating a PRF under the key . The client receives and the server just the information that the PRF has been evaluation. Critically, neither party learns the other party’s input. Finally, the “V” here means that the client also gets an assurance that is indeed . Perhaps the two most prominent examples of (V)OPRFs being used in practice are PrivacyPass and OPAQUE.
Now, in a world where Diffie–Hellman is secure, i.e. where large scale quantum computers do not exist, there are two prominent constructions for OPRFs: multiplicative and exponential blinding.
Multiplicative blinding proceeds as follows. Let
H(⋅) be a hash function and
r some random value picked freshly by Alice:
Client ---> a = H(x)⋅g^r ---> Server <--- b = a^k, g^k <--- H(x)^k = b/v^r
This works out to
which is the PRF evaluation. Similarly, exponential blinding proceeds as follows:
Client ---> a = H(x)^r ---> Server <--- b = a^k <--- H(x)^k = b^(1/r)
This works out to
which again is the PRF evaluation. The two forms of blinding are compared in “On the (In)Security of the Diffie-Hellman Oblivious PRF with Multiplicative Blinding”.
To port either to ring-LWE we may consult a DH to RLWE dictionary:
|DH Land||Ring-LWE Land|
In the table above are all small.
Well, consulting this dictionary we see that multiplicative blinding is supported “out of the box” but exponential blinding is not: there’s no immediate analogue for (see below). Indeed, the current version of our paper uses multiplicative blinding (which in ring-LWE land becomes additive blinding). Note that the non-trivial bit in case of multiplicative blinding is to deal with just how bloody backdoorable LWE is. At some point the server will have to compute for some client provided and some sampled by the server. Multiplying your key with something provided by an untrusted party – here – is a very bad thing to do and we thus rely on heavy zero-knowledge proofs and a special PRF that is relatively easy to prove in our setting to show that is indeed well-formed. See Alex’ talk and our paper for details.
The first version of our paper, though, used exponential blinding (which in ring-LWE land becomes multiplicative blinding) and we thus needed a little trick to make it work. Let’s start by translating the scheme to RLWE directly:
Client ---> a = H(x)⋅r + e ---> Server <--- b = a⋅k + e' <--- H(x)⋅k ≈? b⋅(1/r)
We would like to say that
but that is contingent on being small. There are distributions for where both and are short, but it is not clear that those are good candidates for LWE secrets.
Now, “every problem in computer science can be solved by adding another layer of indirection” and, using a well-known trick for computing “full NTRU” keys, this is what we ended up doing.
- Sample small ring elements and .
- Run the extended GCD algorithm to compute some (this may fail, restart if it does)
- Observe that
- Use Babai’s rounding algorithm to find s.t. and are small. That is, we end up with where are all small;
The protocol then becomes:
Client ---> a_0 = H(x)⋅s + e_0, a_1 = H(x)⋅t + e_1 ---> Server <--- b_0 = a_0⋅k + e_0', b_1 = a_1⋅k + e_1' <--- H(x)⋅k ≈ u⋅b_0 + v⋅b_1
This works out because
Thus we can add another row to our DH-to-RLWE dictionary:
|DH Land||Ring-LWE Land|
|Find small s.t. , then|
Just as in the additive blinding version, we still have to deal with the fact that multiplying our secret by some untrusted (and adding an error) is insecure, so the final version looks like this:
Client ---> a_0 = H(x)⋅s + e_0, a_1 = H(x)⋅t + e_1 ---> Server proof π_1 that a_0, a_1 are well-formed <--- b_0 = a_0⋅k + e_0', b_1 = a_1⋅k + e_1' <--- proof π_2 that b_0, b_1 are well-formed H(x)⋅k ≈ u⋅b_0 + v⋅b_1
Those proofs are also what makes our protocol completely impractical, especially because it needs to attest e.g. without revealing . Again, see Alex’ talk or our paper for the details.