[tor-dev] Shared random value calculation edge cases (proposal 250)
George Kadianakis
desnacked at riseup.net
Thu Nov 19 23:59:30 UTC 2015
David Goulet <dgoulet at ev0ke.net> writes:
> On 19 Nov (14:30:47), Jacob Appelbaum wrote:
>> Hi George,
>>
>> On 11/12/15, George Kadianakis <desnacked at riseup.net> 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.
More information about the tor-dev
mailing list