Use veracrypt with a hidden container. There are debian packages here: VeraCrypt - Free Open source disk encryption with strong security for the Paranoid
Tails is debian based or you can use this in a debian vm to create hidden containers and move those to a USB if you’d like or just keep them in Qubes in another offline VM. The gui is very user-friendly and the instructions are straight forward. Give it a try.
Use veracrypt with a hidden container
Might take a look at it but I’m already experienced with LUKS. Would it be equally good in terms of security (and tracelessness)? (even if using both sticks (LUKS with files and the Tails stick) simultaneously)
That’s a great step in the right direction. Thanks for taking the time to explore this.
Not sure. Would this help? LUKS hidden volume with plausible deniability
I’d personally try to stick to mainstream solutions rather than experimental or cool looking ones. So this is why you may want to look into veracrypt. If you’re not into GUI veracrypt is also fully CLI.
Thanks, I think both ones are good. I’ll look into it and decide. (Btw, what about Qubes’ vault, though (regarding traces)?)
My entire situation is described in my newest question. I would appreciate it if you could take a look at it.
try both if you really like luks and want extreme security
I would like to agree with @ppc and suggest you use QubesOS for your everyday stuff and boot into Tails when you need to leave no trace on your hardware. Do not enable/use “persistante storage” on Tails, read-only OS, everthing done in ram. And you might want to use a public access point in those cases.
Btw, search for “hitb the grugq” on youtube, that is for the real paranoid and has a lot of insight.
Better be paranoid before then after (an security incident).
What types of metadata are we trying to eliminate here? What would a forensics researcher
look for in a QubesOS system?
Is this a reasonable list?
Hashes/Checksums are checked in …/vms/vms.all.SHA and …/vms/$vmname.SHA files. File paths contained in them must be absolute, and references to ‘/home’ must be prefixed with ‘/rw/’. Hashes in $vmname.SHA will override hashes specified for the same paths in vms.all.SHA. See also man page for sha256sum -c.
Whitelists are checked in …/vms/vms.all.whitelist and …/vms/$vmname.whitelist files, and file paths contained in them must start with /rw/. A default is provided in …vms/sys-net.whitelist to preserve Network Manager connections and sleep module list in sys-net.
Deployment files are copied recursively from …/vms/vms.all/rw/ and …/vms/$vmname/rw/ dirs. Example is to place the .bashrc file in /etc/default/vms/vms.all/rw/home/user/.bashrc for deployment to /rw/home/user/.bashrc. Once copying is complete, the /etc/defaults/vms folder is deleted from the running VM (this has no effect on the original in the template).
rc files are sh script fragments sourced from …/vms/vms.all.rc and …/vms/$vmname.rc. They run near the beginning of the vm-boot-protect service before mounting /rw, and can be used to override variable definitions like privdirs as well as the vm_boot_finish function which runs near the end before dismount. Another use for rc files is to run threat detection tools such as antivirus.
Tags: Any of the above configs may be defined as tags so that you are not limited to specifying them for either all VMs or specifically-named VMs. Simply configure them as you would acccording to the above directions, but place the files under the ‘@tags’ subdir instead. For example ‘/etc/default/vms/@tags/special.whitelist’ defines a whitelist for the tag ‘special’. A tag can be activated for one or more VMs by adding a Qubes service prefixed with vm-boot-tag- (i.e. vm-boot-tag-special) to the VMs. Also, multiple tags may be activated for a VM.
Another AF technique is using detached LUKS headers, how does this improve anti forensics?
How does TailsOS actually provision a persistent volume? What filesystem type is it?