(unknown)

From ???@??? Tue May 21 10:33:18 2002
X-cs: R
From: Yan Fitterer <[email protected]>
X-RS-ID: <Default>
X-RS-Flags: 0,0,1,1,0,0,0
X-RS-Header: In-reply-to: <000501c200ae$b3da1a80$6407070a@blue>
X-RS-Sigset: 0
To: "Nicholas Knight" <[email protected]>
Subject: Re: [tomsrtbt] /dev/random and dd
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
Date: Tue, 21 May 2002 11:33:01 -0000


That's very usefull Nicholas - thanks. The goal of this dd was to properly destroy 
all data on a HD prior to disposal of a machine (old laptops in this case). Zeroing 
the disk (even repeatedly) isn't really considered good enough, as all bits are 
affected by the same value, hence my use of a random source.

tomsrtbt was an ideal solution: you plug in the old hardware, boot it on the fd, 
then do a dd. A little change of the scripts could even do this automatically...

Am I right then in thinking there's really no easy solution with Linux? (short of 
leaving the dd running overnight, or mounting the HD in another (faster) machine...)

Y.
PS - how silly of my not to realise /dev/null was input only...

----  On 21 May 2002, at 3:03, Nicholas Knight wrote:  ----
> 
> > Hi,
> >
> > I'm trying:
> >
> > dd if=/dev/random of=/dev/hda bs=1024
> >
> > and I get a trickle of random out of /dev/random. Basically, I get a few
> records (4
> > or 5) when I break out of it after a few seconds. If I use /dev/urandom I
> seem to
> > get a little more data, but still _very_ slow. usring /dev/null doesn't
> work at all, but
> > /dev/zero does.
> >
> > Timing the process, urandom gives me about 1.8K/s. This running on ancient
> > hardware (486). Is the random device that processor-hungry? Or is
> something
> > else amiss?
> >
> > I'm on 2.0.103.
> 
> /dev/random attempts to be *really* random. It's ment for situations where
> high security is needed, such as key generation for encryption applications.
> It spits out a few bytes until it entropy drops too low, then waits for
> other events to create additional entropy. Events that qualify are mostly
> interrupts, things like moving a mouse or hitting the keyboard.
> 
> /dev/urandom however, does not block. It just keeps spitting out
> psuedo-random data that may not be as secure. However, it *will* be slow,
> esspecialy on a 486, as it DOES use the same complex algorithim for the data
> it spits out as /dev/random. Because of the algorithim it uses, which is
> thought to have only some limited theoretical attacks possible at this time,
> it can be argued that /dev/urandom is secure enough for just about anything.
> 
> /dev/zero just spits out all zeros, and never blocks. It'll pretty much spit
> out zeros as fast as they can be written to disk (or RAM, if you've got room
> for the cache).
> 
> /dev/null is *not* an output device, it is input only. Trying to read from
> it is useless (picture trying to read from a floppy drive with no diskette
> in the drive), it is intended solely as a bit-bucket, whatever is directed
> to it is just gone.
> 
> Now, if you want to get a lot of high-entropy random data quickly, you might
> look into a hardware-based solution. Some recent motherboards have built-in
> random number generators, and I'm pretty sure you can find PCI cards, though
> I don't know if any of the PCI cards have Linux drivers avalible. I know the
> generator on the Intel chipset does.
>