| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Boaz Barak, Shai Halevi: A model and architecture for pseudo-random
generation with applications to /dev/random. ACM Conference on Computer and
Communications Security 2005.
which I was referred to by Hugo Krawczyk.
Changes include:
Remove the entropy estimation. This is a major point of Barak and
Halevi's paper: the entropy we want to estimate is the condtional
entropy of the collected data from the point of view of an
unknown attacker. Obviously this cannot be computed! Instead
HMAC_RNG simply counts each byte of sampled data as one bit of
estimated entropy.
Increase the reseed threshold from 2^14 to 2^20 outputs, and
change the fast poll during generation from once every 1024
outputs to once every 65536 outputs (though the fast poll might
not trigger that often, if output lengths are very large -
however this doesn't really matter much, and with the X9.31
wrapper it does kick off exactly every 2^16 outputs). The paper
also has some good arguments why it is better to reseed rarely,
making sure you have collected a large amount of (hopefully)
unguessable state.
Remove a second HMAC PRF operation which was only being done to
destroy the previous K value. Considering it has a short
lifetime, seems excessive (and really hurt performance).
|
| | |
|
| |
|
|
|
| |
Generate new XTS (extractor salt) values using PRF outputs rather than the
clock.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to randomize(), at the start of the function. After that it will
generate as many outputs as needed. The counter cannot overflow,
as only up to 2**32 bytes can be requested per call to
RandomNumberGenerator::randomize, wheras HMAC_RNG can generate 32
bytes (256 bits) per counter value and uses a 32-bit counter.
The PRF is 'stepped' once after the call to
RandomNumberGenerator::randomize is completed. This reduces the
window of exposure to data that was already output for use by the RNG.
|
| | |
|
| |
|
|
|
| |
implementation), remove freestanding estimate_entropy function, change
Randpool to use entropy estimator.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
the constructor. This avoids repeatedly resetting it for each reseed,
if HMAC_RNG is used without entropy sources and using only
application-provided entropy. Very slightly more efficient and
also the code for reseed becomes a bit clearer.
|
|
|
"On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF".
While it has much smaller state than Randpool (256-512 bits, typically,
versus 4096 bits commonly used in Randpool), the more formal design
analysis seems attractive (and realistically if the RNG can manage to
contain 256 bits of conditional entropy, that is more than sufficient).
|
