* kinto <kintho@xxxxxxxxx> wrote: > Alle 22:09, lunedì 10 ottobre 2005, markus reichelt ha scritto: > > Regarding the use of /dev/urandom in crypto operations, please > > have a look at the thread at > > http://marc.theaimsgroup.com/?l=gnupg-users&m=112873347315783&w=2 > > and especially at the last paragraph of my message. > > I've read that message. > Intersting but my question is about the concept, not specifically > urandom as source of entropy. Regarding /dev/urandom as a source of entropy the way it is set up in most linux distribution is a good joke :-) That's all I wanted to point out. However, if it's used to wipe a HDD, fine with me cos that has not much todo with crypto stuff. And Jari basically agreed, IIRC. > > Don't forget to check your system's init scripts for the > > initialization of /dev/urandom > Urandom debian script seem like slackware script. What is the solution? > Sholud we use /dev/random instead of /dev/urandom? Like Tobias already said, it depends on how /dev/random is set up, if it is at all. On some systems there's even /dev/hwrandom, which I would prefer were it present on all my systems. I believe some VIA systems have that ability; I operate a Nehemiah System on a patched 2.6.7 kernel which only has /dev/urandom /dev/random & /hwtrap (whatever that's for). What this boils down to is crypto scripts - one has to be aware of obvious snares. If one writes his own init routines & scripts or continues using distro stuff it totally up to the user. If you initialize /dev/urandom yourself by making sure that the same data is not reused again in crypto ops it's ok. Same applies to /dev/random, which should be ok to use. If I need some pseudo-random data I generate it on the spot. To clarify things regarding loop-aes: It's ok to re-use pseudo-random data to wipe some HDD. It's a totally different issue to re-use pseudo-random data to do real encryption stuff; one shall not use the very same gpg-key to encrypt more than one partition, either. Simply put: If in doubt, just create one more chunk of pseudo-random data; this never is a bad idea, and it doesn't hurt to have used an additional gpg-key if it comes to system compromise. --
Attachment:
pgpXFmjFbkz9v.pgp
Description: PGP signature
