Cyrus POP3 Issue

[Henrique de Moraes Holschuh]

On Fri, 04 Mar 2005, Marco Colombo wrote:
> 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.

Which, in a Cyrus server, won't be helpful since there is a lot of disk
activity and the PRNG state changes quite often, provided you don't keep it
drained (and thus without activity because nobody can talk to the server!).

Using random instead of urandom goes a long way into helping to keep the
pool drained (the kernels usually protect a small amount of entropy 
won't let urandom drain it completely).

> /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

The hard facts are that most kernel entropy accounting is not anywhere close
to exact enough, so we cannot rely on it on anything close to a border
condition (such as the entropy pool being empty, which is the only time
urandom differs too much from random).  You *are* already depending on the
security of the PRNG for small ammounts of time (when the entropy in the
pool is "close" to zero).

Given that fact, IMHO you are much better using urandom anyway, because the
system will still work enough close to an empty entropy pool to regen that
pool a bit.

> 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.

If, and only if, you have no new entropy going in.  If you have a few bits
of entropy going in, they have a reduced search space (which IS already a
very bad thing)... unless the kernel does a catastrophic reseed of the PRNG.
Which on newer Linux kernels for example, it does as often as it possibly
can.

> 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.

It won't be any safer, you mean.  Well, I am not afraid of the SHA search
space, in Linux, BSDs and Solaris, that have somewhat good PRNGs.  The state
of the entropy pool changes unpredictably quite often enough.

> If your kernel runs out of random bits, you should find a reliable source
> of randomness and feed it into the kernel.

I do.  In fact, I have a 25kbit/s entropy feed into the kernel pool in such
a way that I force a catastrophic reseed at least every second, and I am
also working with the merkensleep.com guys to get rng-tools to a point
where you can easily send entropy over the network from something like a VIA
Nehemiah step 8 (a couple Mbit/s of entropy, sweet...) to a cluster.

> 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).

At least so far.  Someone was talking about removing "that useless feature",
so keep an eye for it to make sure they don't.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
---
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