commit eb7c64b9bacd884b5e7b8b69f3caa614f01d8d86 Author: Roger Dingledine arma@torproject.org Date: Tue Sep 12 22:39:29 2017 -0400
other easier fixes to prop#280 --- proposals/280-privcount-in-tor.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/proposals/280-privcount-in-tor.txt b/proposals/280-privcount-in-tor.txt index 716b48e..9b1a8b5 100644 --- a/proposals/280-privcount-in-tor.txt +++ b/proposals/280-privcount-in-tor.txt @@ -220,7 +220,7 @@ Status: Draft [Exactly once]
The curve25519 public key of the tally reporter who is intended - to receive an decrypt this document. The key is base64-encoded + to receive and decrypt this document. The key is base64-encoded with padding stripped.
"count-document-digest" SP "sha3" Digest NL @@ -259,7 +259,7 @@ Status: Draft instance of that keyword's blinded counter.
For example: if the count document lists the keywords "b", "x", "g", - and "a" (in that order), and lists instances "0", and "2", then the + and "a" (in that order), and lists instances "0" and "2", then the decrypted data will hold the blinding values in this order: b, instance 0 b, instance 2 @@ -308,7 +308,7 @@ Status: Draft
6. An optimized alternative
- As an alternative, the sequences of blinding values is NOT transmitted + As an alternative, the sequences of blinding values are NOT transmitted to the tally reporters. Instead the client generates a single ephemeral keypair sk_c, PK_c, and places the public key in its counts document. It does this each time a new round begins.