David Goulet <dgoulet@xxxxxxxxx> writes:On 19 Nov (14:30:47), Jacob Appelbaum wrote:
Hi George,
On 11/12/15, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
Hello there believers of prop250,
you can find the latest version of the proposal in the upstream torpec
repo:
https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-consensus.txt
I reviewed your fine document and I wondered about section 4.1.1. and
specifically about the generation of RN "where RN is a 256-bit random
value."
I'd like to propose a change that is minimal and adds only one small change:
The value REVEAL is computed as follows:
REVEAL = base32-encode( TIMESTAMP || H(RN) )
where RN is a 256-bit random value and where H is the hashing
algorithm "sha256".
This would ensure that the raw random bytes from the PRNG are never
revealed to the network which seems like a reasonable thing[0] to
prevent.
Interesting! This sounds like a good thing to do and very little change
needed for additional security.
George, if you are OK with this, I can change the proposal and push it
upstream. Will change the code after that.
Sounds good to me.The commitment structure will also have to change to commit H(H(RN)).For spec readability, maybe we could have:RN = 255-bit random number REVEAL_VALUE = H(RN)and then use REVEAL_VALUE in REVEAL and COMMIT.
Jacob/David/George,
We typically add a distinguishing value to hashes and signatures in prop224 - can/should we do that for the shared random proposal as well?
It would look like:
RN = 255-bit random number
REVEAL_VALUE = H("derive-reveal" | RN)
COMMIT_VALUE = H("derive-commit" | REVEAL_VALUE)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP 968F094B
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
|