My current plan is to create an empty file, put it in a vault, close the fault to encrypt it, reopen the vault, open the file, then add the sensitive data. Would this work?
Edit: To clarify, what I mean is creating an blank file, like maybe I open a Libreoffice Doc and save it. Then I open a vault using VeraCrypt or one of the other recommended tools and drag the blank file into that. That way, all my normal drive ever saw was a blank file. Then I edit the file while it’s in the vault and save it there.
Not really sure what you mean. I am taking it as, you have a file on a secure drive, and you want to temporarily put it onto an unencrypted medium like a USB or external SSD? Good to encrypt the file itself, as even when it’s deleted from portable media, it may be recoverable.
I would recommend simply encrypting the file before putting onto the media. You could use Veracrypt, 7-Zip, or GPG. Then decrypt on the other side.
What I mean is creating an blank file, like maybe I open a Libreoffice Doc and save it. Then I open a vault using VeraCrypt or one of the other recommended tools and drag the blank file into that. That way, all my normal drive ever saw was a blank file. Then I edit the file while it’s in the vault and save it there. I’ll edit the main post to clarify this.
The idea is that in case malware gets onto my computer, it can’t find traces of things I really want to keep private. To be fair, this is a bit of speculation on my part. I don’t actually know if malware could reasonably scan my entire hard drive and piece together information from deleted files.
For Libreoffice specifically, you could just password protect it. LO natively has a gpg implimentation. Otherwise you could LUKS encrypt a USB and keep the files on that.
If your threat model is super high then you would need to go out of your way to be certain. As unwelled said, you could use Tails and not connect to the internet. Enable persistence. Then you have your files on an air-gapped, password protected OS that never connects to the internet.
I suppose it’s up to you how far you want to take it.
I know that, but I don’t expect to be the subject to that. I’m thinking about the possibility of my guard slipping and visiting a website I shouldn’t, installing a virus on my computer.
If your threat model isnt a fear of the physical harddrive itself, but the threat of future malware gettting installed, then this is the textbook use case for QubesOS.
Data is partitioned into VMs, Xen hypervisor makes the contents of VMs unreadable to one another. For your use case, youd simply create a ‘Sensitive Data’ Qube, and install no programs & allow no network access
Best practice would be using Tails OS which is entirely made for that purpose of defeating digital forensics.
Alternatively you can encrypt individual files, but that doesn’t guarantee unencrypted data never reaches your data drives unless your whole drive(running the OS) is encrypted.
On windows, UWF(unified write filter) can be used to process data solely in RAM, but I’d still prefer Tails for this.
If you intend to use veracrypt and create an encrypted vault, at least go through the official docs. Paging files, caches, temporary files, thumbnails, etc may be written in plaintext if your system drive is not encrypted.
I’d say so. No standard malware is going to send your entire SSD block for block off to a malicious actor who will then apply forensic analysis to it. That sounds highly targeted.
It’s not perfect due to wear leveling, (SSDs are somewhat of a nightmare to securely erase data off) but when I delete sensitive docs I like to use shred.
shred -uvz "filename" will overwrite the file with 3 rounds of pseudorandom data, then a round of zeros, before deleting the file. AFAIK this is the best method to deleting a file off an SSD. Actually even better would be that data in an encrypted container, and then shredding the container.
surely it’s better than emptying the recycling bin or rm no?
please tell me what you know I have found the whole topic of erasing files off an SSD incredibly confusing
edit: and any better method! of course there’s nvme-cli and SATA equivalents but that’s the whole drive. what about just a single file?
Poor OPSEC and user trust boundaries is the other side, where users assume data is deleted from third-party cloud servers, but due to data redundancy practices, ToS/AUP enforcement, government agencies, and malicious actors, data may not actually be deleted at all server-side.
Unlike HDDs, you can’t directly issue commands to the controller to write certain data at a certain location. Due to wear leveling, the logical addresses are arbitrarily remapped on thr physical address. So even if you try to overwrite the very same file stored on a specific location, what actually happens is just writing data on a different sector instead of overwriting, thus leaving the previous (unencrypted) data vulnerable to forensics.
The only way to truly securely delete files in SSDs is to shred the entire SSD itself, wasting huge amounts of SSD lifespan.
So it’s crucial to have the whole drive encrypted beforehand. That way, no plaintext data is ever written to the media in the first place(unless the system somehow bypasses on the fly encryption, which is very unlikely under proper configuration)
nvme-cli is good, but that doesn’t bypass wear leveling and other firmware defined behaviors. I also recommend trying out ShredOS, which is specifically designed to sanitize data drives.