[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Mixed distributions on Debian Live images (and bug in ssl-cert 1.0.15)



On Thu, Feb 28, 2008 at 12:07 AM, Michael Prokop <mika at grml.org> wrote:
>  > How long did you wait for ssl-cert?
>  [...]
>
>  That's not that relevant, because it does not really help you for
>  example on remote, automatic build servers. ;)
The process would proceed, albeit slowly.  It would appear to have
hung, perhaps, but given sufficient time it would finish.  The random
number generator is not so silly as to rely on console input; it uses
keyboard and mouse inputs, but also interrupt and block device I/O
times.  This gives nice, random numbers, even if the machine is mostly
idle.  Perhaps ssl-cert should generate disk activity or something, to
ensure that it completes in a reasonable amount of time?  As a test, I
left my machine alone and it finished making a certificate within an
hour - there was enough network and disk traffic to slowly advance the
progress of the certificate, so if there was more traffic it would go
faster.

>  See my bug report #465279 against ssl-cert; Tollef Fog Heen fixed
>  that problem with upload of ssl-cert version 1.0.16 already.
Good heavens.  I don't care much for my security, but if I were
someone who did, this line might suffice to convince me to move to
another linux distro:
* Get rid of RANDFILE and just use /dev/urandom instead.
/dev/urandom spits out bytes as fast as you ask for them, rather than
block until there is enough entropy like /dev/random does.  This makes
it, as [1] puts it, "merely cryptographically strong", or as the man
page for random (man 4 random) [2] says "Knowledge of how to do this
is not available in the current non-classified literature, but it is
theoretically possible that such an attack may exist. If this is a
concern in your application, use /dev/random instead."  This isn't to
say it's a fatal flaw in my eyes, but I don't think it should be the
default.  SSL certificates for any purpose I can think of should be
made as cryptographically secure as possible.  While I'm glad the slow
build process of ssl-cert has been fixed, I think this is
fundamentally the wrong way to go about things.

Will

[1] http://www.csm.ornl.gov/~dunigan/devrandom.txt
[2] http://linux.die.net/man/4/random



Reply to: