Due to concerns I outlined at [1], I've decided to do a redesign of the
RandomPool random number generator (which originally came from PGP and has
stayed virtually unchanged since the beginning of the Crypto++ project). The
new design will help prevent random numbers from being reused if Crypto++
runs under VMware or similar software that allows rollbacks to earlier
snapshots. It will do this by cryptographically incorporating a high
resolution timer value into every random number generated, on the theory
that the timer will quickly diverge from other executions starting from the
same snapshot, while not slowing down the RNG too much.
I will also modify the DSA and ECDSA implementations so that the hash of the
message being signed is incorporated into the random number k that is
generated during the signing process. The DSA/ECDSA private key is leaked if
the same k is used on two different messages, so any applications using
these algorithms that could be running under a VM that allows rollbacks
should upgrade to the next version of Crypto++ (to be released in a few
weeks) as soon as possible.
While the RNG redesign doesn't offer 100% protection against this risk (see
[2]), it seems to be the best solution at the moment. If anyone has better
ideas, of course please let me know. I'll describe the new algorithm using
some C++-style pseudocode. Comments are very welcome at this point.
// IncorporateEntropy(input)
m_key = sha256(m_key | input); // "|" stands for string concatenation
// GenerateBlock()
rng_output = <empty string>;
m_timer ^= get_timer();
while (length of rng_output < requested length)
{
// m_timer and m_count are both 64-bit values
aes_output = aes_encrypt(m_key, m_timer | m_count);
rng_output = rng_output | aes_output;
m_count++;
}
m_timer ^= first_64_bits(rng_output);
return rng_output;
The reason that rng_output is XOR'ed into m_timer is so that m_timer will
stay diverged from a previous execution as soon as as get_timer() is
different for the first time, even if get_timer() were to re-converge later.
[1] http://www.nabble.com/how-to-guard-against-VM-rollbacks-t2952691.html
[2]
http://www.nabble.com/how-to-guard-against-VM-rollbacks-tf2952691.html#a10239332
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
