Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Entropy feeder
April 11, 2010, 2:36 pm
rate this thread
On some of my boxes, entropy dries up when I try to generate keys using
gnutls certtool. This bothers me; I'm concerned that SSH and HTTPS will
end up negotiating keys using "random" numbers that are to some extent
predictable. I'm particularly concerned about where my (remote,
headless) Xenu virtual server thinks its entropy is coming from; it
seems to have a pretty good supply of the stuff, but at best it must be
sharing it with other Xenus on the same physical hardware.
I have one box that is equipped a VIA C3 processor, which provides a
hardware RNG. This device produces a generous stream of random bits,
which is fed to the entropy pool. The resulting entropy can therefore be
accessed through /dev/random, which doesn't dry up (at least, not quickly).
I have a scheme to write (a) an entropy server, that runs on the VIA
box, and serves blocks of entropy from /dev/random on a TLS-encrypted
port; and (b) a daemon that runs on an entropy-challenged box, and
collects a buffer-full of entropy from the server whenever its pool
starts to dry up, and injects it into the pool (updating the entropy
estimate as it does so).
The server would therefore be a bit like the HTTP service at
- Random.org doesn't seem to offer HTTPS; it wouldn't be good to use an
open channel to collect my raw cryptographic material.
- Random.org relies on radio atmospherics for its entropy, and it seems
to me that radio atmospherics are susceptible to manipulation (using a
transmitter) and interception.
- Random.org imposes a quota.
So: is this a good plan? Are there any gotchas I should try to avoid? Is
an equivalent tool already available? (rngd in stream-input mode dies
when it gets to EOF on its input stream, rather than waiting a few
milliseconds for the stream to start up again).
Re: Entropy feeder
Why the hell is certtool using /dev/random. That is idiotic.
You might want to do
mv /dev/random /dev/random.useless
ln -sf /dev/random /dev/urandom
Or more usefully, stop using the the --disable-quick-random option.
Stop using a useless program. Most of the systems use cryptographically secure
number generators (/dev/urandom) , and, unless the attacker has root priviledges
machine and has recorded all of the activities on your machine for the
past months, they will not be able to predict the keys.
That certtools uses /dev/random indicates that the writer has absolutely
no clue as far as security is concerned. That would worry me far more
than running out of randomness. Why use a tool written by someone who
obviously has no clue whatsoever.
(Note in 2007 they started using /dev/urandom by default, but allowed
you to use /dev/random with the --disable-quick-random option. It should
have been called --use-idiotic-random instead.
DO NOT use the the --disable-quick-random option.
Your chances of being hit by a meteor in the next day are higher than
that someone will predict your random number generator because you did not
feed it enough entropy. Do you worry about meteor strikes every day?
Do not use /dev/random. It is silly. It blocks and can cause problems.
And so you are now going to make available the entropy stream to anyone
who can tap your net link between the boxes? That is a far higher danger
than that machine itself has "insufficient entropy".
But go ahead. Set up your "entropy server". It probably will do no
harm. It certainly will not do any good either, but hobbies are good for
The gotcha to avoid is paranoia.
And to avoid programs written by people without a clue.
Yes, it is to use the default option in certtools.
Re: Entropy feeder
certool is used to generate long-lived keys; sometimes they need the
highest standard of security possible.
The option you refer to is not mentioned in the results of "man
certtool" on my system.
# man certtool | grep "quick-random"
If the attacker knows the internal state of the rng (i.e. the seed),
they can predict the next number it will spit out (and the next seed it
will use). Yes, that requires root, as you note. That the RNG is
"cryptographically secure" doesn't help much; all that guarantees is
that you can't easily predict the next output given a series of prior
outputs. Someone who knows the seed can predict it easily, though. Each
number produced by a PRNG that an attacker can learn gives him more info
about the state, unless entropy is introduced periodically.
You may or may not be right about the authors of certtool; but you
haven't made the case, and your reliance on abuse suggests that you can't.
Do you object to using real random numbers for cryptographic purposes? Why?
This is a rather bald assertion, which you should substantiate.
I know about that, which is why I am attempting a solution.
But I might as well use any PRNG. One uses a real rng if one wants real
random numbers; and /dev/urandom is only a "real" rng until it's used up
the entropy to the point where /dev/random would block. Why do you
advise using /dev/urandom, rather than any other PRNG?
1. I'm proposing nothing of the sort; I may indeed choose to only serve
numbers to clients that can offer an acceptable SSL certificate.
The problem is that sometimes people aren't sufficiently paranoid! In
particular, if one uses crypto routinely, one can become casual about
it. Problems arise when that casualness bleeds through to activities
such as exchanging high-value keys and passwords.
I think there are things that the certtool people did wrong; but I don't
happen to think relying on /dev/random was one of them. Taking too much
entropy from it is another matter...
That's not an answer to my question. And as a Debian user, what you
refer to as "default" is AFAICS not even an option for me. Man certtool
doesn't mention it.
Re: Entropy feeder
That is what urandom gives you.
Wwhat version do you have?
or certtool --help
Entropy IS introduced periodically. And if the attacker has root, you
are totally screwed anyway. It is like worrying about dirty fingernails
while tied to the railway track with a train coming.
Each number produced by the prng may give him more info, but the precise
reason for a cryptographing prng is that that does not help. The amount
of effort required to use that info is totally unfeasible.
Fine. you are of course allowed to do or think what you want. some
people believe that only by wearing tin foil on their heads can they
stop the CIA from reading their minds.
/dev/random blocks. That is a failure. A program which ceases to work
for no known reason is a bad program. /dev/urandom uses a
cryptographically strong PRNG. If you are willing to use say gpg, or
SSL, or any of the other encryption products, you know that they all are
"weak" in that with less than 2^128 work they can be broken. There is no
evidence that /dev/urandom can.
I object to using a routine, /dev/random, that blocks for anything. If I
want "real random numbers" whatever they are, I will build myself a
random number generator using thermal noise or quantum noise, with a
distillation routine to make sure that any biases in the physical
process will be cooked out. I sure will not use /dev/random. In the
meantime I will use /dev/urandom, until someone makes a convincing
argument that it is breakable in much less than 2^128 work.
Because it is easily available.
If you want to use another one, go ahead.
What? You are going to devise an RNG and then have it depend on
something like SSL? That is evan weirder
certtools uses info, not man. /dev/urandom was made the default in 2007.
If debian is using an older version than that, then perhaps other things
Usage: certtool [options]
--disable-quick-random Use /dev/random for key generationg,
thus increasing the quality of
Note that the comment "increasing the quality" is simply not true. But
at least the default is now sensible.
Now maybe Debian did something to certtool to make "diable quick-random"
the default, or maybe they are using an ancient version of certtool.
Re: Entropy feeder
I said in my first post that I plan to move entropy from a machine that
has lots to one that is entropically-challenged over TLS. If we can
assume that the TLS session is established properly, then how is that weird?
Info shows the same stuff as man.
/dev/urandom was made the default in 2007.
Aah - and there it is. Looks like someone perhaps de-documented it, but
that would be an odd thing to do.
I can't at this time find any evidence that Debian has deviated from the
gnutls defaults. But my experience is that certtool blocks on a depleted
entropy pool, even without that flag.
# certtool -v
certtool (GnuTLS 2.4.2) 2.4.2
Re: Entropy feeder
It is the disconnect in logic. You are worried that /dev/urandom does
not have good enough random numbers, but are willing to trust SSL or
whatever to protect those same random numbers. You worry that someone
could obtain root on your system and read the entropy pool to
/dev/urandom, but not that someone could watch the traffic flow by on
the net, and break the encryption. That is what is weird.
No. They probably forgot to document it when it was introduced in 2007.
But apparently you are using /dev/random because your system it blocking
(at least that is why I assume you are worried about having a sufficient
entropy pool for /dev/random) while the default should be /dev/urandom,
which does not block. Either debian made that no quick random the
default in compiling, or something is wrong.
Yes, that is what is weird. Either it is a bug in certtools, or Debian
overrode the default.
Re: Entropy feeder
I demand that unruh may or may not have written...
If /dev/random is causing blocking, then either it's being used too much or
there isn't enough entropy being added to cope with what may well be normal
usage. Devices such as are available from the likes of
http://www.entropykey.co.uk/ should help with this.
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + This comment has been censored.
One will not have needed the future perfect in one's entire life.
- » 2010 Congress on Computer Applications and Computational Science, Singapore [EI Compendex...
- — Next thread in » Linux Security
- » Cloud Ace Technologies is offering Implementation Services on Cloud Computing, Cloud Serv...
- — Newest thread in » Linux Security
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — The site's Newest Thread. Posted in » Secure Shell Forum