>
>> djm> Much better for jurisdictions that allow for that, but not all
>> not knowing where something physically is at all times?
>
> I'm not in a position to discuss this jurisdictions requirements and
> rationale on a public mailing list. All I'm saying is that data destruction
> base on
On Wed, 11 Nov 2009, David Magda wrote:
There seem to be 'secure erase' methods available for some SSDs:
Unless the hardware and firmware of these devices has been inspected
and validated by a certified third party which is well-versed in such
analaysis, I would not trust such devices with s
Miles Nordin wrote:
"djm" == Darren J Moffat writes:
>> encrypted blocks is much better, even though
>> encrypted blocks may be subject to freeze-spray attack if the
>> whole computer is compromised
the idea of crypto deletion is to use many keys to encrypt the drive,
and enc
> "djm" == Darren J Moffat writes:
>> encrypted blocks is much better, even though
>> encrypted blocks may be subject to freeze-spray attack if the
>> whole computer is compromised
the idea of crypto deletion is to use many keys to encrypt the drive,
and encrypt keys with oth
On Wed, 11 Nov 2009, Darren J Moffat wrote:
Zfs is absolutely useless for this if the underlying storage uses
copy-on-write. Therefore, it is absolutely useless to put it in
zfs. No one should even consider it.
I disagree. Sure there are cases where ZFS which is copy-on-write
is sitting o
Bob Friesenhahn wrote:
On Wed, 11 Nov 2009, Darren J Moffat wrote:
note that "eradication" via overwrite makes no sense if the underlying
storage uses copy-on-write, because there's no guarantee that the newly
written block actually will overlay the freed block.
Which is why this has to be a
On Nov 11, 2009, at 17:40, Bob Friesenhahn wrote:
Zfs is absolutely useless for this if the underlying storage uses
copy-on-write. Therefore, it is absolutely useless to put it in
zfs. No one should even consider it.
The use of encrypted blocks is much better, even though encrypted
block
On Wed, 11 Nov 2009, Darren J Moffat wrote:
note that "eradication" via overwrite makes no sense if the underlying
storage uses copy-on-write, because there's no guarantee that the newly
written block actually will overlay the freed block.
Which is why this has to be a ZFS feature rather than
Bill Sommerfeld wrote:
On Wed, 2009-11-11 at 10:29 -0800, Darren J Moffat wrote:
Joerg Moellenkamp wrote:
Hi,
Well ... i think Darren should implement this as a part of
zfs-crypto. Secure Delete on SSD looks like quite challenge, when wear
leveling and bad block relocation kicks in ;)
No I w
On Wed, 2009-11-11 at 10:29 -0800, Darren J Moffat wrote:
> Joerg Moellenkamp wrote:
> > Hi,
> >
> > Well ... i think Darren should implement this as a part of
> zfs-crypto. Secure Delete on SSD looks like quite challenge, when wear
> leveling and bad block relocation kicks in ;)
>
> No I won't b
On Wed, November 11, 2009 13:29, Darren J Moffat wrote:
> No I won't be doing that as part of the zfs-crypto project. As I said
> some jurisdictions are happy that if the data is encrypted then
> overwrite of the blocks isn't required. For those that aren't use
> dd(1M) or format(1M) may be suff
On Wed, Nov 11, 2009 at 12:29 PM, Darren J Moffat
wrote:
> Joerg Moellenkamp wrote:
>
>> Hi,
>>
>> Well ... i think Darren should implement this as a part of zfs-crypto.
>> Secure Delete on SSD looks like quite challenge, when wear leveling and bad
>> block relocation kicks in ;)
>>
>
> No I won't
Joerg Moellenkamp wrote:
Hi,
Well ... i think Darren should implement this as a part of zfs-crypto. Secure
Delete on SSD looks like quite challenge, when wear leveling and bad block
relocation kicks in ;)
No I won't be doing that as part of the zfs-crypto project. As I said
some jurisdictio
Hi,
Well ... i think Darren should implement this as a part of zfs-crypto. Secure
Delete on SSD looks like quite challenge, when wear leveling and bad block
relocation kicks in ;)
Regards
Joerg
Am 11.11.2009 um 17:53 schrieb Cindy Swearingen:
> This feature is described in this RFE:
>
> htt
This feature is described in this RFE:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4930014
Secure delete option: erase blocks after they're freed
cs
On 11/11/09 09:17, Darren J Moffat wrote:
Brian Kolaci wrote:
Hi,
I was discussing the common practice of disk eradication used
Brian Kolaci wrote:
Hi,
I was discussing the common practice of disk eradication used by many
firms for security. I was thinking this may be a useful feature of ZFS
to have an option to eradicate data as its removed, meaning after the
last reference/snapshot is done and a block is freed, the
Thanks all,
It was a government customer that I was talking too and it sounded like a good
idea, however with the certification paper trails required today, I don't think
it would be of such a benefit after all. It may be useful on the disk
evacuation, but they're still going to need their pa
Excuse me for mentioning it but why not just use the format command?
format(1M)
analyze
Run read, write, compare tests, and data
purge. The data purge
function implements the National Computer Security Center Guide to
Understanding Data Remnance (NCSC-TG-025 version 2) Overwriting
On Nov 10, 2009, at 20:55, Mark A. Carlson wrote:
Typically this is called "Sanitization" and could be done as part of
an evacuation of data from the disk in preparation for removal.
You would want to specify the patterns to write and the number of
passes.
See also "remanence":
http:
Typically this is called "Sanitization" and could be done as part of
an evacuation of data from the disk in preparation for removal.
You would want to specify the patterns to write and the number of
passes.
-- mark
Brian Kolaci wrote:
Hi,
I was discussing the common practice of disk eradicati
Hi,
I was discussing the common practice of disk eradication used by many firms for
security. I was thinking this may be a useful feature of ZFS to have an option
to eradicate data as its removed, meaning after the last reference/snapshot is
done and a block is freed, then write the eradicati
21 matches
Mail list logo
