How to destroy files without leaving any traces ?

[maritnez]

you have a file that contains sensitive banking data and would like to delete it without leaving any traces on your system.

you can 'move it to trash'
which moves it to the trash

you can then press the delete button in your trash container but
is this really securely deleting the file without any chance of recovering it?

how to delete files without leaving ANY trace from it?

[Chris Laprise]

I think the surest non-physical method is to make sure the data is
encrypted in the first place, and throw away the key/passphrase. On a
typical Qubes configuration, this would mean re-encrypting and
reinstalling the OS if your data was on the same LUKS volume as the OS.

FWIW, Qubes supports SSD TRIM by default. This might provide a certain
level of data erasure if you are using an SSD, leaving less data behind
*on average*. However, its not something you should rely on when
deleting specific files. Some SSDs and HDDs also have a "secure erase"
feature which erases the entire drive.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Building on what Chris said, here are your general options, from best to worst:

1. Physical destruction of the storage medium. (usually overkill)
2. Make sure the data is encrypted before it ever touches the storage medium (then wipe the encryption headers, if any, or keep the key secret).
3. Delete the files and overwrite them with a tool like "shred", and/or delete them normally, then wipe all free space.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYEYPNAAoJENtN07w5UDAw52QP/iJRsrLIIijGrqyodtVsQK4V
a32qoLHOUIcfSByrSJp/u2atmnByysYtomYiNv588YELihEWnf7q8oLdynd5b3Q3
WxtlBO4fQQZN8f2f2oRDir3zDKkRZLRTEN7R7LjQoEE56teQubEDTCqqWYNOrnmC
sOeabKJd0lA8dLn6/xTRymhE657/kjJPurIEggfnfQrD0FQ1BsxYyfUhhiW1ESAT
4g/vpKz6IX7NyYfthTo/ZrT/wBU8dtxz48mSCimZI6qB3Cm2OVnNpRAqkRIeHjxY
XU7TN5+/g/qk92SuY2rUCjjIaXCbJrQD+TeOd7cHqV+8um8WXf+5K4hdGhKc3swR
BoUDFw3ezwT9KvpWQbKXsHvg4ZtoNuQRTQySXekcJBh08CwiLnnP1eGmE4pgGs5C
6OibzIr127QmArLDNJCc23d+Nl40Clw6YBP8aAhlompc6aaAD9vRAs6LY+Sf6LGO
9UC+XMwX7II1C+rrBVqTrTDt/wd8WX5USM7P9pTpex1JDEzMfgCIoAeQwE5Gs/Xx
kSgnM6FZ9PuGmcFjNcgypU2a41rex6eWt4lW83v+Ap1IGtHVP4GrXiTNe3f35L3x
lsMzrlmY3528caS16csSrpc8kK9wXbL0Br+QC2vKxoMriytWkA1XKvMR0Vs+t72r
/Hxds8+YON1+jVQ4M9Dj
=cFrz
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

Here is what happens when you do that in a VM, assuming the data is
stored in /home or /rw:

1. VM file moves to trash.

2. you empty the trash in the VM.

3. In 5 seconds, the VM kernel's ext4 file system commits the metadata
change to /dev/xvdb, and discards the data blocks that were occupied by
the file.

4. The discard makes its way to dom0's
/var/lib/qubes/appvms/vm/private.img by way of the loopback device that
was connected to the VM in representation of the private.img file.

5. Since loopback devices honor discard, and since loopback devices
mapping files issue PUNCH_HOLE or zero out the relevant data on the
file, that means the discard operations make their way into private.img
as either blocks zeroed out or PUNCH_HOLE operations.

6. The dom0 file system hosting that private.img file can do any number
of things about these incoming operations:

6.1. If ext4: after 5 seconds, the discard operation makes its way to
the underlying block device; this may be 100% ineffectual in rotational
devices that do not support discard, and may also be 100% ineffectual in
the case of SSDs as they may decide to forego deleting the data and just
add those disk regions to a fresh pool of writable flash (while keeping
the "zeroed" data hidden from you. but certainly not from governments)

6.2. If ext4 on top of LVM: ask someone else, as I'll put it bluntly: I
do not know what that shit does, and I do not know if anyone knows.

6.3. If ZFS or btrfs: the file system code will do copy on write, which
means the blocks will still be available in some other region of the
disk, until they get overwritten by new writes. Worse still, if the
data you just tried to zero out in the VM actually happens to be in a
file system snapshot of dom0, then by definition it will not ever get
deleted, until you kill the snapshot and zero out all storage on the
devices.

It's more complex than that, though.

First rule of thumb: IF you wrote X to disk, THEN be sure X is going to
be there.

Second rule of thumb: IF you read data chunk X with a program at some
point, THEN it's likely that X is going to be on disk too, because of
swap (read -> memory -> swapout -> disk).

The way to get around these rules of thumb is (a) make sure that data
always hits the disk encrypted (b) make sure to never ever let any
adversary read from that disk while unencrypted, or obtain the key to
that disk.

The takeaway: deleting data is REAL HARD. You better have a good
encryption password.

The honest, cheap-to-execute answer to your question is: get a blowtorch
and torch the individual data-bearing parts of the drive, until each
part changes color, and then some. Don't breathe the magic smoke coming
out of these parts — it may kill you.

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 10/27/2016 04:34 AM, Andrew David Wong wrote:
>
>
> Building on what Chris said, here are your general options, from best
> to worst:
>

> [...]

> 2. Make sure the data is encrypted before it ever touches the storage
> medium (then wipe the encryption headers, if any, or keep the key secret).

This method is no longer 100% effective since the advent of flash,
hybrid drives, and hidden storage areas on rotating disks that store
unused sectors for when used sectors begin to fail.

--
Rudd-O
http://rudd-o.com/

[Robert Mittendorf]

so what is the matter? If the data on the drive is stored only encrypted
(SSD, HDD or SSHD), those "hidden sectors" (for performance, wear
leveling or reserve) and the caches do only contain encrypted data as
well.....

[7v5w7go9ub0o]

(Heh....... "magic smoke", eh!?)

(Newbie question:) Is there a possibility of using "mlock" to block
swap; working entirely in ram - de-crypting the imported subject file
using "tmpfs" interim files, then exporting the updated, encrypted
subject file back to vault (or out the door)? I'd guess this would leave
you vulnerable only to someone hands-on dumping your memory? I'd presume
doing all of this in a DispVM would preclude some "relic" remaining in a
Domain. (One wouldn't want any (encrypted) relics in case of a
rubber-hose interrogation and demand for passwords.)

p.s. Thank You for your helpful postings here!!

[ludwig jaffe]

dd if=/dev/urandom of=/home/noob/myporn.jpg

[Manuel Amador (Rudd-O)]

tmpfs is swappable by default. You would have to swapoff.

> I'd guess this would leave you vulnerable only to someone hands-on
> dumping your memory? I'd presume doing all of this in a DispVM would
> preclude some "relic" remaining in a Domain. (One wouldn't want any
> (encrypted) relics in case of a rubber-hose interrogation and demand
> for passwords.)

I do not know what the status is on keeping the whole DispVM in RAM, but
there is an issue filed on the matter. Check the qubes-issues Github repo.

>
> p.s. Thank You for your helpful postings here!!
>
>

--
Rudd-O
http://rudd-o.com/

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Currently, DispVMs do *not* support exclusive in-RAM execution (or
whole-VM encryption) sufficient to thwart forensic analysis.

> I do not know what the status is on keeping the whole DispVM in RAM, but
> there is an issue filed on the matter. Check the qubes-issues Github repo.
>

Here's the issue:

https://github.com/QubesOS/qubes-issues/issues/904

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYFBjyAAoJENtN07w5UDAwxzoP/i247OluZeaWok5pOeXLdahh
yZCpOU6+FSahFZHJI9FU0+ogoXl4gaeI8f5m6HdFh7UfgyYrpnVU4K3257Sdvv9U
GL993Yn8WQYKiTSiUjYsZLN+jP6lzGlkEPy3wIHLmOZB42EBNO4UD8vHLq4OCnmL
xcCNcc5UQHjONExdp4SobLsYuibJwPDiS2KQUr6dnviCAzgbNDqieJlWnT/d2rnU
HwEbOmY9HBRBLRZA8HzbcQPOHuFnvAGJw0TGAoZyuGwmOnzw327LmIDgUkGSwQaH
TrhOBlFpT7lc4o1gRgqj8irPuDjCIHehAA6KyvISupAkUg9Gx++Drw5lxlGjIlCZ
J0cSFjWrm7/fqVErlLw1umQAjfLqDfOCXJZkOjxaVVKJ04KuJQPROiUoSmiUQ++p
weJwLcEdku2Rm90gnCirpiLWLYCZzwrCpPV1fBUhp3RapxXuthMqLtoclWOMRCkF
DKDcKplTmeF+mHZcYiGtzx7vhiCaualPlc/ODLMixacw2fLPe2CN3xrbVioltLaQ
sFWAl/cGfTEAq1OmzTDVrrQRSDmBwmKs+ByI9poSxilFAUMeAgB/dYPu7uSkfLIf
uB1a5FGpc6QxgGYwYlJoqqGMAvQkGq7q3CA8keDIw9oEzIauWX2J/e0W1IAwxZaz
8cCzEoictZ4LUdeGRPN5
=H5/u
-----END PGP SIGNATURE-----