Radoslaw,
One of the problems I see with Host based overwrite is that you can only
overwrite the current location of the logical volume.
If you are using IBM's Eazytier, or Hitachi's HDT you really do not know the
past location of the chunks of the volume, only the last location. The same
Ron,
Please, read carefully my first words:
I did mean DISK overwrite.
Eazytier or other vendors features, or SVA-like type of emulation make
it hard to overwrite DISK (physical disk) from host level. However your
point contains another assumption, untypical IMHO: logical volume
overwrite.
if an IT auditor would accept this method!
Thank you for sharing.
Roger
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Pommier, Rex
Sent: Tuesday, January 21, 2014 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Disposal of storage devices
W dniu 2014-01-20 22:44, Paul Gilmartin pisze:
On 2014-01-20, at 13:35, R.S. wrote:
And what about n-times overwrite policies? What number is proper? Does one need
to overwrite disk content once, twice, 3 times, 7 times or 21 times? What's the
magic number? And what is the reason for the
Radoslaw,
About 10 years ago I was given the task to migrate off an RVA onto a different
disk subsystem. Not really knowing how to erase the disks without use of a
sledgehammer, I initialized all the volumes to logically erase them, then
uploaded a bunch of songs to the array. I then
R.S. wrote:
3. Regarding possibility rto read *valuable* information overwritten once: Such
theoretical possibility assumes one use good microscope and watches single
magnetic domain. There is no hidden HDD command like read deleted info. And
now: what is easier: decrypt encrypted content of
W dniu 2014-01-21 17:03, Phil Smith pisze:
R.S. wrote:
3. Regarding possibility rto read *valuable* information overwritten once: Such
theoretical possibility assumes one use good microscope and watches single magnetic
domain. There is no hidden HDD command like read deleted info. And now:
R.S. wrote:
Well, two points:
1. Encryption means the data is still there, but you need a lot of time or
...just good luck to access it. So, when you dispose encrypted media then it's
very unlikely someone could read it, but when you dispose erased media then
you are sure.
2. LAS, BUT NOT
W dniu 2014-01-20 21:18, Phil Smith pisze:
R.S. wrote:
Well, two points:
1. Encryption means the data is still there, but you need a lot of time or
...just good luck to access it. So, when you dispose encrypted media then it's
very unlikely someone could read it, but when you dispose erased
On 2014-01-20, at 13:35, R.S. wrote:
And what about n-times overwrite policies? What number is proper? Does one
need to overwrite disk content once, twice, 3 times, 7 times or 21 times?
What's the magic number? And what is the reason for the number?
For example from:
Phil Smith wrote
begin extract
if I encrypt a ZIP file with DES (56 bit keystrength) and you believe
it's a .doc file, you will cheerfully cruise right by the correct key,
because you won't see the .doc signature you're expecting.
/end extract
and I have two comments.
First. the professional
Phil thinks I misunderstood/misrepresented him.
His statement
begin extract
But in the real world, such assumptions often don't apply, and so even
relatively weak crypto can be de facto quite secure.
/end extract
immediately following the one about DES that I quoted earlier suggests
otherwise
On 1/20/14, John Gilmore jwgli...@gmail.com wrote:
Phil thinks I misunderstood/misrepresented him.
His statement
begin extract
But in the real world, such assumptions often don't apply, and so even
relatively weak crypto can be de facto quite secure.
/end extract
immediately following
John Gilmore wrote:
Phil thinks I misunderstood/misrepresented him.
His statement
begin extract
But in the real world, such assumptions often don't apply, and so even
relatively weak crypto can be de facto quite secure.
/end extract
immediately following the one about DES that I quoted earlier
Thank you. It is my phrase. I provide quotation marks and, usually,
an attribution when I quote, as I am said to do too much.
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access
15 matches
Mail list logo
