commit c590145e6d3212a1c8802360e5a1d3e777306eb6 Author: Nick Mathewson nickm@torproject.org Date: Tue Jul 10 19:58:34 2018 -0400
Correct a point in proposal 288.
Previously our design had called for considering a SHAKE output B bits at a time, but bitwise slicing is a pain. Instead, consider the output 64 bits at a time, mask off the high bits, and discard values that lie outside the prime field. Since P is very close to 2^B, nearly all values should be okay. --- proposals/288-privcount-with-shamir.txt | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/proposals/288-privcount-with-shamir.txt b/proposals/288-privcount-with-shamir.txt index 76a065d..62faa1d 100644 --- a/proposals/288-privcount-with-shamir.txt +++ b/proposals/288-privcount-with-shamir.txt @@ -118,13 +118,16 @@ Status: Accepted
1. For every Tally Reporter with index i, the client constructs a random 32-byte random value SEED_i. The client then generates - a pseudorandom bitstream of C*B bits using the SHAKE-256 + a pseudorandom bitstream of using the SHAKE-256 XOF with SEED_i as its input, and divides this stream into C values, with the c'th value denoted by MASK(i, c).
- [Because P is very close to a power of 2, nearly all seeds will - produce MASK values in range 0...(P-1). If any does not, the - client picks a new seed.] + [To divide the stream into values, consider the stream 8 bytes at a + time as unsigned integers in network (big-endian) order. For each + such integer, clear the top (64-B) bits. If the result is less than + P, then include the integer as one of the MASK(i, .) values. + Otherwise, discard this 8-byte segment and proceed to the next + value.]
2. The client encrypts SEED_i using the public key of Tally Reporter i, and remembers this encrypted value. It discards