i know, but i heard somewhere that “plausible deniability” only available on windows
and require “trick” to work on other
There’s no trick, full veracrypt options are available for both windows and linux. There’s no difference between other the if you open a hidden container on windows you’ll likely defeat the purpose of the hidden container and leave traces of the contents all over the windows system whereas in tails non-persistent session you’ll leave no traces once it’s powered off.
i understand what you talking about
i’m talking about full os “plausible deniability”, not “hidden container”
Can you see the edit?
The hidden container container feature in veracrypt is what offers the plausible deniability. When creating the hidden container you always create a non-hidden container and fill it with semi-sensitive data. When you’re forced to give your passphrase, you give it for the non-sensitive container, while never giving up your hidden container passphrase. Through mathematical forensics one cannot prove there is a hidden container.
Can you see the edit?
For full OS plausible deniability only open a hidden container offline in tails. I would go as far as saying never use tails persistence, just use hidden containers if you need to save anything or keep it stored in brain memory.
Don’t use qubes or any other OS for any sort of plausible deniability.
i don’t understand?
why don’t, i’m using qubes os with plausible deniability
http://dreadytofatroptsdj6io7l3xptbet6onoyno2yv7jicoxknyazubrad.onion/post/af76301c21e1b4a33851
3 Likes
Wow great share. I’ll look into this.
But I think for OP this would beyond their level at the moment.
But thanks for sharing.
That’s here
This works fine for 4.0 and creates a RAM based storage pool to hold a
qube. Depending on your threat model, it may be of some use.
3 Likes
So to prevent traces with Tails, it would be good to use it without persistence, but instead with another LUKS encrypted USB drive to save files?
Thank you.
To sum it up: Are the traces only a threat if someone grabs my device while being logged in?
That’s my main question here.
@Thamil13 Thank you.
To sum it up: Are the traces only a threat if someone grabs my device while being logged in?
That’s my main question here.
In the context of using encryption and without torture, blackmail, and other methods of coercion that would force you to give up a 15 word diceware created passphrase for powered down system, then I’d say yes those traces are only a threat in qubes while being logged in.
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.
1 Like
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?