7 Oct
2017
7 Oct
'17
8:30 a.m.
Hi RS,
On Fri, Oct 06, 2017 at 08:43:22AM -0700, ringsignature(a)riseup.net wrote:
That is my understanding as well. The key difference is that you were
spot on about the pool being drained very seriously - to the point of
underflowing, thus potentially encountering serious error states. Those
error states might be a 512 byte buffer with only one random byte, for
example.
I don't think this is an issue. We can actually do blocking reads for
key generation, once we ever do that. The speed of programming SIM
cards is probably invariably slower than the amount of randomness we can
get. That's a one time operation at the time SIM cards are programmed.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
* use getrandom() with GRND_RANDOM flag for
K/OP/OPc/Ki generation
I don't have a strong opinion on this one. For GNU/Linux kernel >= 4.8 both
/dev/random and /dev/urandom are going through the same CSPRNG so I'm
not sure we
gain anything by requiring random instead of urandom.