On Mon, 2009-01-26 at 10:20 +, Pádraig Brady wrote:
Pádraig Brady wrote:
Thanks for performance testing, showing reading /dev/urandom is the
bottleneck.
It would be worth knowing what CPU you used for this test.
cheers,
Pádraig.
An AMD64 Turion, 2 cores @ 2GHz. The disk interface
On Mon, 2009-01-26 at 02:20 +, Pádraig Brady wrote:
A consequence of this change -- right now -- is that all 3 passes
will
be random. I am not sure if this was the intended result or not.
Yes we don't really care about the patterns written to file any more,
so random is as good as
HggdH wrote:
On Mon, 2009-01-26 at 02:20 +, Pádraig Brady wrote:
A consequence of this change -- right now -- is that all 3 passes
will
be random. I am not sure if this was the intended result or not.
Yes we don't really care about the patterns written to file any more,
so random is as
HggdH wrote:
On Mon, 2009-01-26 at 10:20 +, Pádraig Brady wrote:
Pádraig Brady wrote:
Thanks for performance testing, showing reading /dev/urandom is the
bottleneck.
It would be worth knowing what CPU you used for this test.
cheers,
Pádraig.
An AMD64 Turion, 2 cores @ 2GHz. The
Pádraig Brady wrote:
Thanks for performance testing, showing reading /dev/urandom is the
bottleneck.
It would be worth knowing what CPU you used for this test.
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
HggdH wrote:
On Thu, 2009-01-22 at 13:14 +, Pádraig Brady wrote:
Jim Meyering wrote:
Sure.
Too many people waste too much time with the existing defaults.
Pushing the attached soon so.
A consequence of this change -- right now -- is that all 3 passes will
be random. I am not sure if
On Thu, 2009-01-22 at 13:14 +, Pádraig Brady wrote:
Jim Meyering wrote:
Sure.
Too many people waste too much time with the existing defaults.
Pushing the attached soon so.
A consequence of this change -- right now -- is that all 3 passes will
be random. I am not sure if this was the
Pádraig Brady p...@draigbrady.com wrote:
Jim Meyering wrote:
Paul Eggert egg...@cs.ucla.edu wrote:
Jim Meyering j...@meyering.net writes:
I too would feel better with a minimum of 2 or 3 passes, just in case.
If we want to be conservative, then the U.S. Defense Security
Service's Clearing
Jim Meyering wrote:
Paul Eggert egg...@cs.ucla.edu wrote:
Jim Meyering j...@meyering.net writes:
I too would feel better with a minimum of 2 or 3 passes, just in case.
If we want to be conservative, then the U.S. Defense Security
Service's Clearing and Sanitization Matrix (2005-06-27)
Jim Meyering wrote:
Sure.
Too many people waste too much time with the existing defaults.
Pushing the attached soon so.
Note the recent paper suggesting a single pass is fine is:
http://sansforensics.wordpress.com/2009/01/15/overwriting-hard-drive-data/
However the methods there a questioned
Pádraig Brady [EMAIL PROTECTED] writes:
A better option I think is to use O_DIRECT, but again
portability is going to be the issue here.
Shouldn't be a problem. shred already uses O_DIRECT if available.
On Solaris, it uses directio(), for the same reason.
Philip Rowlands wrote:
On Fri, 4 May 2007, Paul Eggert wrote:
Anyway, 'shred' currently does the first, but not the second, as it
doesn't verify what it's written. That should get fixed, no?
Is there a way to ensure reading directly from disk? On Linux I see only
a whole-system,
On Fri, 4 May 2007, Paul Eggert wrote:
Anyway, 'shred' currently does the first, but not the second, as it
doesn't verify what it's written. That should get fixed, no?
Is there a way to ensure reading directly from disk? On Linux I see only
a whole-system, root-level way to drop cached
Peter Eckersley [EMAIL PROTECTED] writes:
We might choose 2, because of the 1% chance of recovery cited by one of
the recovery firms in that paper.
Or 3, because we're paranoid.
DoD 5220 specifies 3, in a certain way, so perhaps that should be the
default. But that's a pretty old
Paul Eggert [EMAIL PROTECTED] wrote:
Peter Eckersley [EMAIL PROTECTED] writes:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
As near as I can make out, for modern disks the default should be 1.
That's easy
On Fri, 2007-05-04 at 09:14 +0200, Jim Meyering wrote:
Paul Eggert [EMAIL PROTECTED] wrote:
Peter Eckersley [EMAIL PROTECTED] writes:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
As near as I can make out
Peter Eckersley [EMAIL PROTECTED] wrote:
On Fri, 2007-05-04 at 09:14 +0200, Jim Meyering wrote:
...
My reflex was to object. Reducing the default number of passes from
25 to 1 seemed extreme. But after skimming through the link below,
it's hard to argue :-)
Really? For Top Secret+
Jim Meyering scripsit:
My reflex was to object. Reducing the default number of passes from
25 to 1 seemed extreme. But after skimming through the link below,
it's hard to argue :-)
Still, there may be older disks hanging about. How about making the
number of passes inversely proportional
On Fri, 2007-05-04 at 10:28 -0400, John Cowan wrote:
Jim Meyering scripsit:
My reflex was to object. Reducing the default number of passes from
25 to 1 seemed extreme. But after skimming through the link below,
it's hard to argue :-)
Still, there may be older disks hanging about.
Jim Meyering [EMAIL PROTECTED] writes:
I too would feel better with a minimum of 2 or 3 passes, just in case.
If we want to be conservative, then the U.S. Defense Security
Service's Clearing and Sanitization Matrix (2005-06-27)
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
I too would feel better with a minimum of 2 or 3 passes, just in case.
If we want to be conservative, then the U.S. Defense Security
Service's Clearing and Sanitization Matrix (2005-06-27)
On Fri, 2007-05-04 at 15:35 -0700, Paul Eggert wrote:
I looked into the ATA side a bit more. The hdparm command has
--security-erase and --security-erase-enhanced options that look like
they should use the ATA functions in question. This could well be
more suitable for the paranoid than
Hi!
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
We'd like to get shred called from more standard packages (starting with
logrotate). For various reasons, plenty of systems seem to have large
enough log files (10s
On Wed, 2 May 2007, Peter Eckersley wrote:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
The first question which comes to mind is why 25?
From the first version which I can find:
http://git.sv.gnu.org/gitweb/?p
Philip Rowlands scripsit:
It's tricky to view security/performance tradeoffs to be anything but
ratchet-like, only ever towards security.
Hmm. You know, this ward lock you have on your front door here is
very insecure. It's easy to cut a skeleton key that will open it.
Oh, no problem! We
On Thu, 2007-05-03 at 19:56 +0100, Philip Rowlands wrote:
On Wed, 2 May 2007, Peter Eckersley wrote:
It's tricky to view security/performance tradeoffs to be anything but
ratchet-like, only ever towards security. Perhaps it's even preferable
to make --iterations be a mandatory argument,
On 5/3/07, Peter Eckersley [EMAIL PROTECTED] wrote:
We're certainly working on making sure that userspace chattr()s the
attribute. Apparently, for many journalling filesystems (ext3 and maybe
Reiser, IIRC), shred should still work pretty well as-is -- I guess
that's because the filesystem
I don't think that any of the attacks Wietse discussed are related to
actually reading things out from underneath multiple disk-write cycles
(though he does cite Peter Gutmann's 1996 paper on microscopic attacks,
but the paper applied to older hard disks).
Everything else is about keeping track
Peter Eckersley [EMAIL PROTECTED] writes:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
As near as I can make out, for modern disks the default should be 1.
That's easy to change. Any objections?
There's also
On Thu, 2007-05-03 at 19:05 -0700, Paul Eggert wrote:
Peter Eckersley [EMAIL PROTECTED] writes:
I was wondering if you would consider reducing the number of default
overwrites for shred from 25 to something more like 5?
As near as I can make out, for modern disks the default should be 1
30 matches
Mail list logo
