From eb7c64b9bacd884b5e7b8b69f3caa614f01d8d86 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Tue, 12 Sep 2017 22:39:29 -0400 Subject: other easier fixes to prop#280 --- proposals/280-privcount-in-tor.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'proposals/280-privcount-in-tor.txt') 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. -- cgit v1.2.3-54-g00ecf