Re: FileCopy overwrites the existing file

Thank you very much for your responses!

If a laptop was lost with overwritten (FileCopy) sensitive data, how much
concern should we have that someone could retrieve that layer of data in a
form practical enough to use? Does the risk level drop if the disk as been
defragged? Does the risk level drop if whole disk encryption is used?

Thanks

"anton bassov" wrote:

Another solution to the "safe erase" problem - full disk encryption.

Don't forget that, depending on your location, you may be subjected to
government regulations, i.e. what type of encryption
can be sold to what type of customer. For example, in the US you cannot
sell products that use encryption stronger than 40-bit, to the
individuals, and AFAIK, you cannot export them either. Therefore, from
the company's perspective, it is much better to develop products that
simply erase data - AFAIK, for the time being there are no restrictions
here (at least not yet)....


Just remove the keys

Again, not so easy.....

The problem is that these days governments become more and more
intrusive and obnoxious, so that your right to privacy holds...... but
only "apart from the cases specified by the law". This means that you
may be issued with a court order to provide your keys, and get some
"unpleasant experience" if you fail to comply with it. Therefore, from
the private individuals's perspective, it is also better to use those
products that simply erase data....


The procedure takes zero time

Yes, but what about the time spent on encrypting/decrypting data???? If
you use some strong encryption scheme, your machine is going to crawl
like a turtle. Therefore, it is better to encrypt files that meet some
certain criteria, rather than the disk itself, i.e. to implement
encryption in FS, rather than in disk, filter

Anton Bassov


Pavel A. wrote:
Perhaps the possibility of recovery depends on how long
the data stays on the disk before overwrite.

As Mr. Burn noticed, often implementation becomes requirement.
Another solution to the "safe erase" problem - full disk encryption.
Just remove the keys and the data will go for good, with
a cryptographic proof - no matter how the drive controller can
re-arrange or substitute blocks on the physical media.
The procedure takes zero time and does not wear off the media.

--PA


"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message news:1165410387.593416.103010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
How would you say that? No one will be demonstrating to you how to do
it, especially that some details might be (read: are) well guarded
company's secret (and top data recovery companies cooperate strictly
with governments).

There is no need do disclose the actual "know-how" in order to
demonstrate the technology in itself - the only thing needed here is
simply recovering overwritten data in a public demo test. However,
AFAIK, no one has ever successfully did it - Uwe has already mentioned
the "results" of one of these tests, and, AFAIK, there were quite a few
tests like that....

Anton Bassov


Grzegorz Wróbel wrote:
anton bassov wrote:
David,

In fact, the only thing I said is that "it has not yet been
*DEMONSTRATED* how to do it in more or less reliable way"......

I don't exlude the possibility that it may have *partly* been done by
some agency. This is why they still incinerate disks with secret data,
although they allow overwriting confidential one. After all, don't
forget about "bad sectors" that can be found on practically any disk -
although they are not accessible to the software, some data may still
be left over from the time when they were, and, at this point,
specially tuned hardware should not have any problem retrieving it.

However, the statement like " any good data recovery company can do it
if data has been overwritten only once" is just a gross
exagerration.......

How would you say that? No one will be demonstrating to you how to do
it, especially that some details might be (read: are) well guarded
company's secret (and top data recovery companies cooperate strictly
with governments). But if you want an empiric proof you can get it.
Overwrite some data *once* take your hdd and request recovery of that
data from a reputable company. It will cost you some money, but you'll
eventually get your data back. To make things easier for the company you
can overwrite your data by zeros only (or by ones). The proof as such
will still hold.

--
Grzegorz Wróbel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D


.

Relevant Pages

  • Re: "secure" file flag?
    ... >> Encrypting data and secure removal of data are orthogonal and in case ... > Both are completely adequate to protect the data on the disk from ... That's why encryption can be required. ... > specify a simple pattern like overwrite with zeros once, ...
    (freebsd-hackers)
  • Re: FileCopy overwrites the existing file
    ... sell products that use encryption stronger than 40-bit, ... The problem is that these days governments become more and more ... certain criteria, rather than the disk itself, i.e. to implement ... the data stays on the disk before overwrite. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: FileCopy overwrites the existing file
    ... Perhaps the possibility of recovery depends on how long ... the data stays on the disk before overwrite. ... Another solution to the "safe erase" problem - full disk encryption. ... company's secret (and top data recovery companies cooperate strictly ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Disk over writing software
    ... requirement of cleaning up the data on the hard disk. ... First of all, overwriting an entire filesystem, or larger area of the ... Secure overwrite of filemay be ... be left as it exists - e.g. if a 512 byte sector has been allocated ...
    (comp.os.linux.security)
  • Re: Question about secure empty trash/srm
    ... Quoting from the srm man page: ... through normal OS channels to read/write disk blocks. ... drive hardware composes the logical bits/bytes from (a simple overwrite ... With journaling, disk-writes are first committed to the journal file ...
    (comp.sys.mac.system)