H(m)⊕r
-
-
-
That's much like updating the DRBG state with the message before using a random nonce, right?
-
Yes, that would achieve the same result.
-
If we think about it as updating DRBG state, we can see that we could invoke hash function less by only hashing high-entropy bits…
-
…also we only have a 192-bit nonce so we're close to SHA-1 w.r.t. collisions, so better not be hashing attacker-controlled bits.
-
Also, unless one is using BLAKE2 (w/ BLAKE2 & ChaCha20 sharing code), hash + XChaCha20-Poly1305 seems expensive in multiple axes.
-
It has a cost, but the worst that can happen is getting deterministic nonces.
-
Let's say RNG is totally broken and always spits out zero. Then two messages would use the same nonce if 192-bit hashes collide.
- 1 more reply
New conversation -
-
-
And by "random" I mean something like hash(random+message+time+counter+unique).

-
If you feed random+message+time+counter+unique into PRNG state then you can just use the PRNG, right? Though message is low entropy.
-
I dunno — I don't really like the paradigm of stateful PRNGs that much…
-
Consider a message with the same value always sent at the same time. Then message + time would be perfectly correlated.
-
Stateful PRNGs seem like they can mitigate this kind of correlation, esp. when attacker can't see all requests/responses.
End of conversation
New conversation -
-
-
@CiPHPerCoder another option for long running chunks, long random plus counter@kaepora -
XChaCha20 already has an internal counter so I don't see any real benefit here. Just update the ic?
-
Sorry I was thinking of the XSalsa20Poly1305 variant... My mistake.
-
Salsa20 and ChaCha both have 64-bit internal counters.
End of conversation
New conversation -
-
-
@CiPHPerCoder long random, UTC time in ticks or millisecondsThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.