On Thu, Feb 28, 2008 at 12:07 AM, Michael Prokop <[EMAIL PROTECTED]> 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 _______________________________________________ debian-live-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
