[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Shared random value calculation edge cases (proposal 250)
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.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev