[clue] secure erase techniques?

[Dan Kulinski]

Chris,

Thanks for the actual numbers in your post.  On what CPU did you pull these
numbers?

Also, I think your calculations are wrong for overwriting a 300GB drive.  We
routinely write 1TB+ to drives and I have a chart of transfer rates for our
data folks.

1TB at 100MB/sec = 3 hours
1TB at 10MB/sec = 30 hours
1TB at 1MB/sec = 300 hours

We routinely hit 80 - 90MB/sec on 2TB HDDs, not 3MB/sec.

100MB/sec is about 1/3rd of the SATA bandwidth (I know that isn't exact but
for simplicity's sake I equate 1Gb/sec to 100MB/sec).  I think your SATA
speed calculation should be 3*1024^3 (kilobits, megabits, gigabits).

Dan Kulinski

On Wed, Jun 1, 2011 at 10:26 AM, chris fedde <chris at fedde.us> wrote:

> It might be a good idea to switch to /dev/zero.  It is much faster
> than /dev/random
> You need to wait for it to finish to overwrite the whole disk.  As a
> least upper bound on the run time take the disk size and divide by the
> advertised transfer rate of the interface.  300Gbyte = 300*1024^3,
> 3Mbyte/sec ideal SATA speed = 3*1024^2
>
> using bc -l
>
> (300*1024^3)/(3*1024^2)
> 102400.00000000000000000000
> ./3600
> 28.44444444444444444444
>
> about 29 hours if you really get full bandwidth from your sata port.
> Chances are that's a gross under estimate.
>
> Here is a quick device timing test:
>
> [cfedde at home]$ dd if=/dev/urandom of=/dev/null bs=4096 count=1000
> 1000+0 records in
> 1000+0 records out
> 4096000 bytes (4.1 MB) copied, 0.532551 seconds, 7.7 MB/s
>
> [cfedde at home]$ dd if=/dev/zero of=/dev/null bs=4096 count=1000
> 1000+0 records in
> 1000+0 records out
> 4096000 bytes (4.1 MB) copied, 0.001732 seconds, 2.4 GB/s
>
> /dev/zero is much faster than /dev/urandom
>
> On Wed, Jun 1, 2011 at 9:07 AM, Mike Bean <beandaemon at gmail.com> wrote:
> > No harm, no foul, it's not a particularly fast Celeron, so I don't mind
> > letting it run long, I just wasn't sure what to expect.
> >
> > On Wed, Jun 1, 2011 at 8:15 AM, Will <will.sterling at gmail.com> wrote:
> >>
> >> I should have recommended /dev/zero instead of /dev/urandom.  For your
> >> purposes it would have been just as good and faster.
> >>
> >> On Wed, Jun 1, 2011 at 8:02 AM, Will <will.sterling at gmail.com> wrote:
> >>>
> >>> It should eventually quit on its own.  The amount of time it will take
> is
> >>> dependent on how fast your CPU can generate random numbers and how
> large the
> >>> partition is.
> >>>
> >>> On Wed, Jun 1, 2011 at 5:09 AM, Mike Bean <beandaemon at gmail.com>
> wrote:
> >>>>
> >>>> How long would I need to leave this running?   cat /dev/urandom >
> >>>> /dev/sda1 's been going for long about 10 hours now.  Is this
> something that
> >>>> I'll need to abort or does it terminate on its own?
> >>>>
> >>>> On Tue, May 31, 2011 at 9:04 AM, chris fedde <chris at fedde.us> wrote:
> >>>>>
> >>>>> Raymond,
> >>>>>
> >>>>> What does the magic block size do?
> >>>>>
> >>>>>
> >>>>> I'd go with two passes of "cat /dev/urandom > /dev/sdX" as root.
> >>>>>
> >>>>> On Tue, May 31, 2011 at 8:51 AM, Raymond DeRoo <rderoo at deroo.net>
> >>>>> wrote:
> >>>>> > Mike--
> >>>>> >
> >>>>> > In short, I'm giving one of my older PC's to a friend's friend.
> One
> >>>>> > of
> >>>>> > those, I don't need it, things.  In any case, in terms of secure
> >>>>> > destruction
> >>>>> > of drives, my father's always taught me to disassemble the drives
> and
> >>>>> > throw
> >>>>> > the heads and the platter out separately.  Can't do it here, they
> >>>>> > need the
> >>>>> > drives, so I thought I'd ask for advice in case we have members who
> >>>>> > might
> >>>>> > know a thing or two about this sort of thing.  I figured I'd
> probably
> >>>>> > just
> >>>>> > boot it to a live CD and nuke the partitions, and that's probably
> >>>>> > enough,
> >>>>> > after all, I don't need like a military-grade erase, but I'll
> settle
> >>>>> > for
> >>>>> > making it @#$@#$@$ hard to recover.  Any suggestions are welcome.
> >>>>> >
> >>>>> >
> >>>>> > # dd if=/dev/urandom of=/dev/sda bs=387 count=<size of disk in
> bites>
> >>>>> > / 383
> >>>>> > Recover from this *IS* still possible, but generally requires
> someone
> >>>>> > who is
> >>>>> > *VERY* knowledge about drives to do as such.
> >>>>> > .r
> >>>>> > _______________________________________________
> >>>>> > clue mailing list
> >>>>> > clue at cluedenver.org
> >>>>> > http://cluedenver.org/mailman/listinfo/clue
> >>>>> >
> >>>>> _______________________________________________
> >>>>> clue mailing list
> >>>>> clue at cluedenver.org
> >>>>> http://cluedenver.org/mailman/listinfo/clue
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> clue mailing list
> >>>> clue at cluedenver.org
> >>>> http://cluedenver.org/mailman/listinfo/clue
> >>>
> >>
> >>
> >> _______________________________________________
> >> clue mailing list
> >> clue at cluedenver.org
> >> http://cluedenver.org/mailman/listinfo/clue
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue at cluedenver.org
> > http://cluedenver.org/mailman/listinfo/clue
> >
> _______________________________________________
> clue mailing list
> clue at cluedenver.org
> http://cluedenver.org/mailman/listinfo/clue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20110601/b82b6fb0/attachment-0001.html