[tor-commits] [torspec/master] Correct a point in proposal 288.
nickm at torproject.org
nickm at torproject.org
Wed Jul 11 00:00:38 UTC 2018
commit c590145e6d3212a1c8802360e5a1d3e777306eb6
Author: Nick Mathewson <nickm at 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
More information about the tor-commits
mailing list