[tor-dev] Shared random value calculation edge cases (proposal 250)

[Tim Wilson-Brown - teor]

> On 22 Nov 2015, at 01:09, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> 
>> We typically add a distinguishing value to hashes and signatures in prop224
>> - can/should we do that for the shared random proposal as well?
> 
> I don't think so?

I tend to agree - there's no need for a distinguishing value here.

As far as I understand, a distinguishing value is used to make hashes used for different purposes unique, even if they have the same input data. It also means that any precomputed matches or hash confirmations have to be done for each hash and purpose.

But random inputs don't suffer from either of these issues (the input is random, and precomputing 256 random bits is infeasible). Also, adding a distinguishing value would mean that more than 256 bits are hashed into 256 bits, which I assume would be slower, for no net gain.

>> It would look like:
>> 
>> RN = 255-bit random number
>> REVEAL_VALUE = H("derive-reveal" | RN)
>> COMMIT_VALUE = H("derive-commit" | REVEAL_VALUE)
>> 
> 
> My suggestion shouldn't impact such a choice in any case. I merely
> suggest that the 256-bit (surely you don't mean 255 bit?) random
> number is hashed before we consider it a valid candidate RN value.

Ugh, I copy-pasted the original mistake. You're right, it should be 256.

> The following are equivalent and should be indistinguishable uniformly
> random values:
> 
> (RN = H(gen_random(256)) ~= (RN = gen_random(256))
> 
> The cost is an extra full sha256 but the resulting output is
> different. The key difference is that we do not reveal the raw outputs
> of the (P)RNG directly to the network or to a potential adversary.

I'll see if I can write a patch for this.
It's something we should do with all our random values, not just the ones for prop250.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151123/0445c8f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151123/0445c8f7/attachment.sig>