Cyrus POP3 Issue

[Marco Colombo]

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.
  _____/ _____/  _/		       Colombo at ESI.it
---
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