Encrypting files?
- Inicie sesión ou rexístrese para enviar comentarios
I've been encrypting files with my pgp key and I found out yesterday when I used photorec to recover a deleted file on a USB drive that it recovered the unencrypted files, so am I encrypting files the wrong way?
When I decrypt my files it makes a decrypted zip file then unzip the file to access it. Then I would delete those files that have been decrypted at the end of a session so only the encrypted file remains. I didn't realize that the decrypted zip and file would still be there and recoverable by photorec. There has to be a better way because this is not secure at all.
What am I screwing up?
I recommend you to encrypt the whole USB or your hard drives (or SSD or even MicroSD or android phone) to don't have this problems.
Of course this means being extra careful with your data.
You can 'shred' the original file rather than only removing it:
$ shred -un 1 file
I am a translator!
You are doing it wrong, mateson :(
As mr. Magique wrote above you need to make sure you shred the original unecrypted file.
shred -uvz file
This will use the default 3 passes. 1 pass is enough though. You can use bleachbit to shred entire folders.
Depending on the filesystem, it may still be wrong:
$ info shred
(...)
*Please note* that `shred' relies on a very important assumption:
that the file system overwrites data in place. This is the traditional
way to do things, but many modern file system designs do not satisfy
this assumption. Exceptions include:
* Log-structured or journaled file systems, such as those supplied
with AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in
`data=journal' mode), BFS, NTFS, etc., when they are configured to
journal _data_.
* File systems that write redundant data and carry on even if some
writes fail, such as RAID-based file systems.
* File systems that make snapshots, such as Network Appliance's NFS
server.
* File systems that cache in temporary locations, such as NFS
version 3 clients.
* Compressed file systems.
In the particular case of ext3 file systems, the above disclaimer
applies (and `shred' is thus of limited effectiveness) only in
`data=journal' mode, which journals file data in addition to just
metadata. In both the `data=ordered' (default) and `data=writeback'
modes, `shred' works as usual. Ext3 journaling modes can be changed by
adding the `data=something' option to the mount options for a
particular file system in the `/etc/fstab' file, as documented in the
mount man page (man mount).
If you are not sure how your file system operates, then you should
assume that it does not overwrite data in place, which means that shred
cannot reliably operate on regular files in your file system.
(...)
I am a translator!
Yes, good reminder. Always read dem man pages!
shred commands
https://wiki.ubuntuusers.de/shred/
In synaptic package manager:
wipe
secure-delete
nautilus-wipe
Do they have same limitations about file systems which shred has?
I would assume so, unless you find evidence of the opposite.
I am a translator!
Forgot to add that shreding files on a ssd is like cleaning mr. Zuccamerd: impossible and a time waste. If you have an ssd full disk encryption is your only choice (other than filling the entire drive with random garbage)
Veracrypt says, do not encrypt on ssds. The ssd software may cancel secure
encryption.
Any pieces of information on the matter about gnulinux encryption?
Please encrypt your devices for a better security less problems.
Even when you forget to encrypt something it will still be encrypted. The problem with this devices is that is really hard to actually delete the stuff you put in them.
- Inicie sesión ou rexístrese para enviar comentarios