On 22 Nov 2015, at 01:09, Jacob Appelbaum jacob@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