Hal Finney wrote:
Even with a random nonce there could be duplication if the OS RNG
state does not get changed from the time the rollback occurs until the
RNG is queried for the nonce. (Here I am assuming that the RNG is part
of the virtualized OS and not a global resource.) Note that some RNGs
buffer entropy and do not add it to the main RNG state until a certain
amount of estimated entropy has been acquired, to avoid state
following attacks. That will increase the window of vulnerability to
this problem.
Hopefully OS vendors will cooperate with VM software writers to fix this
problem. It should be relatively simple since the fix would be
transparent to the application software (i.e. not require a new API).
In the mean time, a workaround at the application software level may be
to always hash the current time into the random number returned by the
OS. This type of solution may also be applicable to state-derived
nonces, for example by reserving some bits in the nonce for a timestamp.
Nonce duplication could be avoided by creating the nonce
as a hash of RNG data and the message being hashed, to achieve the
condition that nonce reuse would only happen with the same message.
This is also a good workaround in some situations, but using it for
Wegman-Carter MACs would eliminate or significantly reduce their speed
advantage.
_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg