tech-crypto archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: insufficient entropy for rnd
Hello!
Thank you all for the replies, there have been a couple of
very useful bits of information, primarily from Dan Carosone.
Here are some outputs from my server:
# rndctl -l
Source Bits Type Flags
sd1 12200023 disk estimate, collect
sd0 14535605 disk estimate, collect
pckbd0 2421 tty estimate, collect
fxp0 0 net
wd0 6184645 disk estimate, collect
Correct me when I'm wrong but I'd think fxp0 is disabled
by default because it could theoretically be flooded from
the network with a pattern that could make the randomness
somewhat more predictable (not that I'd recognize that
as a serious security risk...)
# rndctl -s
32922694 bits mixed into pool
0 bits currently stored in pool (max 4096)
14031307 bits of entropy discarded due to full pool
18891387 hard-random bits generated
171645157 pseudo-random bits generated
To me the above numbers tell that lots of entropy bits get
wasted because of the pool being full and the 4096 bits
in the pool can be drained rather easily by any process
which eats bigger bursts of random numbers.
> By default it is 128 words (x 32 bits). It can be made bigger, for
> example I have:
>
> options RND_POOLWORDS=512
I made a quick "grep RND_POOLWORDS /usr/src/sys/arch/i386/conf/*"
and there was nothing (1.6 release syssrc though). The only manpage
that has got some indication of this is rnd(4):
typedef struct {
u_int32_t len;
u_int32_t entropy;
u_char data[RND_POOLWORDS * 4];
} rnddata_t;
I'd say this is far too implicit so for a normal user like me
this option is not the in well documented part. Thank you for
mentioning it.
> Having a larger pool probably helps fudge the estimator more than
> it really helps the "quality" of the randomness produced.
Why that? (sorry I'm no mathematician ;-)
Regards,
Szabolcs Rumi
Home |
Main Index |
Thread Index |
Old Index