2

I just had some problems to get Pidgin with OTR running, because Pidgin hung on every attempt to generate my private key. This rather old blog post pointed me into the right direction (or rather "allowed me to generate a key"), by "feeding /dev/urandom into the entropy pool for /dev/random".

When I do watch cat /proc/sys/kernel/random/entropy_avail, I see numbers < 50. While feeding /dev/urandom into the entropy pool, this number went up to ~2000 and then I was able to generate my key.

Are my entropy values of < 50 bit(?) normal? I'm on a desktop system with basically Firefox, Thunderbird and Pidgin running, streaming music from LAN.

Is the inability to create a key for OTR a bug in Pidgin or is my Arch Linux installation to blame for the low entropy?

PS: I know about this answer explaining many misconceptions about entropy and (P)RNGs.

Update: There already are open bugs at the OTR bugtracker and at Launchpad about this issue. Writing random text in an editor also helps when generating the key.

Improve this question
2
  • 1
    I tested on a couple of Ubuntu systems (one with pretty heavy use, the other mostly idle), and both had values of ~800. Commented Dec 30, 2014 at 16:10
  • 1
    Ok, I tested it on 98 Ubuntu systems that I could connect to (all of which are mostly idle). The average, median, min and max vales were: 651.602, 711, 147, 906. Never as low as 50. I think this is a systemic problem (and not one in Pidgin). Commented Dec 30, 2014 at 16:18

1 Answer 1

Reset to default
2

“Feeding /dev/urandom into the entropy pool for /dev/random” is cheating — you're pretending to provide new entropy when in fact the data is derived deterministically from the current state of the RNG. Fortunately, as you noted, the rule that you're cheating is a useless one: entropy doesn't actually decrease despite what the Linux kernel pretends.

Low entropy by Linux's /dev/random's estimate is common and almost always a false alarm: the estimate is unreasonably conservative.

/dev/urandom is secure for key generation, so Pidgin should arguably use /dev/urandom (which doesn't block) instead of /dev/random (which can block, and often does).

There is only one case where /dev/random blocking is legitimate because the system genuinely doesn't have enough entropy: when the system is too new to have accumulated entropy. Linux systems normally save entropy for the next reboot, so in practice genuine low entropy only happens in two circumstances:

  • on a brand new installation — this is especially a concern in embedded devices that generate a key the first time they're turned on;
  • on a live system.

Where to set the blame isn't really a productive consideration, but if you must: Arch Linux and you are fully innocent. Pidgin should use /dev/urandom or at least offer a way, so it gets part of the blame. The Linux kernel should really provide an interface that's guaranteed to deliver crypto-quality randomness and blocks only if entropy is genuinely lacking (like FreeBSD's /dev/random).

Improve this answer
3
  • "Arch Linux and you are fully innocent." But according to the comments on my question, somehow has (reports?) more entropy than my box... Commented Dec 31, 2014 at 10:15
  • @Jasper If you've been using /dev/random a lot (perhaps you tried Pidgin's key generation several times?) then your entropy level will be low. It never gets really high even when it's had a lot of time to accumulate, so it can deplete pretty quickly. Commented Dec 31, 2014 at 10:27
  • 1
    That might be the case. Now I'm getting ~1000 entropy from entropy_avail. Commented Dec 31, 2014 at 11:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.