FS#23856 - SASL should use /dev/urandom instead of /dev/random

Attached to Project: Arch Linux
Opened by Andreas Baumann (andreas_baumann) - Wednesday, 20 April 2011, 15:09 GMT
Last edited by Jan de Groot (JGC) - Wednesday, 03 August 2011, 20:50 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Description: SASL should use /dev/urandom instead of /dev/random

This task depends upon

Closed by  Jan de Groot (JGC)
Wednesday, 03 August 2011, 20:50 GMT
Reason for closing:  Implemented
Comment by Tom Gundersen (tomegun) - Friday, 22 April 2011, 15:40 GMT
I'm not the maintainer, but out of curiosity:

Why do you request the change? As far as I understand this would fix possible latency/timeout problems at the cost of weaker encryption, is this correct? If so, do we know that the weaker encryption is "good enough"? What are other distros doing, what does upstream think about the issue?
Comment by Andreas Baumann (andreas_baumann) - Saturday, 23 April 2011, 08:46 GMT
/dev/random is always secure as it stops returning data if it has too low entropy.
/dev/urandom guarantees not to block but can deliver less secure random data. Now
in SASL a random device is used for digest computation (as in CRAM MD5) and other
things. If you program a server doing authentication over SASL, the worst thing
which can possibly happen is that it stops during authentication (imagine sshd
would do that): you are open to DoSAs for login.

If you worry about security: /dev/urandom feeds actually on /dev/random for
it's entropy, so in normal situations they are equally safe. If you have a
hardware random number generator and are using for instance rngd, then the
hardware entropy is used to feed /dev/random's entropy pool.

This is a more general discussion I realize and maybe we should look at other
distributions and other packages (not only SASL) and what's the poilicy on
the usage of random number devices there.

Comment by Andreas Baumann (andreas_baumann) - Saturday, 23 April 2011, 08:50 GMT
Addendum: /dev/random feeds on hardware events, mainly mouse moves and keyboard clicks
to produce entropy (also a little bit interrupts and disk activity). Now servers
rarely have somebody sitting in the rack moving around mouses and doing a lot
of tipping.. ;-)
Comment by Andreas Baumann (andreas_baumann) - Saturday, 23 April 2011, 08:52 GMT
See at discussions like the following one:


It's about outweighing two evils, which one is in which case the lesser evil.
Comment by Tom Gundersen (tomegun) - Saturday, 23 April 2011, 10:27 GMT
Thanks for the summary!

It sounds to me after reading the discussions that

1) /dev/random must be used when generating long-lastin keys/certificates (ssh-keygen, ++),
2) /dev/urandom must be used for things susceptible to a DoS attack,
3) things that are neither in 1, nor 2, should use /dev/urandom, and
4) things that are both in 1 and 2 are broken and need to be looked into...

Maybe we have a policy on this already that I have not seen?
Comment by Jan de Groot (JGC) - Saturday, 23 April 2011, 10:55 GMT
/dev/urandom should be used for SASL. I faced this problem once on debian when we had setup a Cyrus Murder setup. Authentication between backend and frontend would always hang for several minutes after the box had rebooted because of an empty random entropy pool.