Henrique de Moraes Holschuh wrote:
On Thu, 03 Mar 2005, L. Mark Stone wrote:
The POP server component is giving us a problem. It often fails to
respond to connection requests in a timely manner, if at all. IMAP
Disable APOP, or get SASL to use /dev/urandom like it should be doing in any
sane distribution (SASL is not generating long-term keys which would be a
good reason to use /dev/random).
You do want to use /dev/random for your session keys. _They_ are
likely going to attack your session keys, not your master key. The whole
point is to guess as many bits as possible of the kernel PRNG state.
/dev/random blocks when the kernel thinks the PRNG state could have
already been guessed, in pure theory. So the attacker would be able guess
its _next_ output. By reading from /dev/urandom, you're accepting the risk
(the output is protected by a crypto-strong hash function, such as SHA1,
anyway - but you have to trust it). Once the attacker knows the output of
your /dev/urandom, he knows all the session keys your host will generate.
Note that since you've generated the master keys offline, in an unknown
time on an unknown computer, the attacker knows _nothing_ about the PRNG
state of the machine you used. You could have used /dev/urandom for
them w/o any risk, unless the attacker was able to observe you in that
moment[*]! The only thing that could help him is a bug in the PRNG and the
hash function, so that some bit strings are impossible (or unlikely) to be
generated. That would allow him to discard them in a brute force search.
It happened in the past, some software used to generate 128 bit keys was
buggy and the actual number of possible combinations was much much smaller
(say 2^20). But the same PRNG and the same hash function are used by
/dev/random as well, so it isn't much safer in this respect.
If your kernel runs out of random bits, you should find a reliable source
of randomness and feed it into the kernel.
.TM.
[*] assuming the keys you generated are not longer than the kernel
internal pool, in bits. If the PRNG state is 4096 bits, and you are
generating a 8192-bit key out of /dev/urandom, the attacker needs only
to try 2^4096 possible combinations, not 2^8192. Usually the kernel pool
is large enough (and can be enlarged at run time in modern Linux kernels).
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
