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.