Previous Page

nihilist & Oxeo0 - 2025-04-01

The main source of Plausible Deniability: Deniable Encryption (April 2025 update)

zuluCrypt is a free and open-source tool for encrypting files and volumes in a secure way. We already used it for hiding data in video files using steganography.
Today, we'll use it as a replacement for VeraCrypt - a free open source disk encryption software for Windows, Mac OSX and Linux. Being based on TrueCrypt, VeraCrypt offers a unique feature called Hidden Volumes which can give us Plausible Deniability. zuluCrypt supports both TrueCrypt and VeraCrypt volumes while being better integrated in Linux ecosystem. It also comes preinstalled with kicksecure OS.

But why is Plausible Deniability important first of all?
From a legal perspective, depending on jurisdictions, you may be forced to type your password into an encrypted drive if requested. All it takes is for an adversary to be able to prove the existence of an encrypted drive to be able to force you to reveal the password to unlock it. Hence for example the regular LUKS encryption is not enough, because you need to be able to deny the existence of the encrypted volume. If that is the case, we have to use veracrypt encrypted volumes, which is an encryption tool used to provide deniable encryption (which is what gives you Plausible Deniability) against that scenario where you're forced to provide a password.

Using Veracrypt encrypted volumes, you have a decoy volume which is there by default (that spans the entire encrypted volume) and you CAN have a hidden volume if you choose to, which is hidden in the decoy volume, it's also known as the "inner volume", and the only way to reveal that the hidden volume exists, is to use the correct secret password to both unlock it. If the encrypted volume doesn't exist, legally speaking you cannot be forced to unlock it, because it doesn't exist to begin with, as far as the adversary's concerned.

DISCLAIMER: we're using only harddrives (HDDs) here, because using SSDs are not a secure way to have Plausible Deniability, that is due to hidden Volumes being detectable on devices that utilize wear-leveling

source: https://anonymousplanet.org/guide.html#understanding-hdd-vs-ssd

regarding wear leveling:
"Also as mentioned earlier, disabling Trim will reduce the lifetime of your SSD drive and will significantly impact its performance over time (your laptop will become slower and slower over several months of use until it becomes almost unusable, you will then have to clean the drive and re-install everything). But you must do it to prevent data leaks that could allow forensics to defeat your plausible deniability. The only way around this at the moment is to have a laptop with a classic HDD drive instead."

OPSEC Recommendations:

1. Hardware : (Personal Computer / Laptop)

2. System Harddrive: not LUKS encrypted [1]

3. Non-System Harddrive: 500Gb (used to contain our VeraCrypt encrypted volumes)

4. Host OS: KickSecure

5. Hypervisor: QEMU/KVM

6. Packages: grub-live and ram-wipe

In this tutorial requires you to have implemented the following setup:

As we have explained previously the Host OS being in live mode is a crucial requirement to be able to maintain deniability, on top of erasing the contents of the RAM upon rebooting the Host OS, because we need to make sure that the adversary is not able to see what we were doing on the computer before they manage to get their hands on it. The Veracrypt encrypted volumes are now going to enable us to store sensitive data that can be accessed again after rebooting. To do so, we need to save the veracrypt encrypted volume on a non-system drive, because if we were to store it on the system drive, it'd disappear when we reboot the computer to exit live mode !

Sidenote: Help us improve this tutorial by letting us know if there's anything missing or incorrect on this git issue directly!

Using Zulucrypt to create Hidden Veracrypt volumes

Since we are using Kicksecure as a Host OS, zulucrypt is installed by default, so we can open it:

So now you have zuluCrypt on your system. However before you start to use it, make sure that your Host OS is in live mode, as otherwise you wouldn't be able to maintain your deniability regarding the existence of the veracrypt hidden volume

By default, your host OS directly writes into the system drive all sorts of potential forensic evidence that an adversary may use against you, such as system logs, kernel logs, non-standard logs, etc, and unless if you remove each of those manually, you're never sure of wether or not the Host OS saved proof of the existence of the hidden volume onto the system drive. That's why when you use zulucrypt to handle veracrypt hidden volumes (creating them or opening them) you absolutely need to use the Host OS in live mode ONLY!

When the Host OS is in live mode, you're loading the entire host OS in the RAM, meaning that you are not writing anything on the system drive anymore, but rather you are only writing all that potential forensic evidence of the veracrypt hidden volume in RAM alone, which can be easily erased with a simple shutdown thanks to both live mode and ram-wipe.

So if you didn't do it already, reboot the Host OS into live mode:

And only now once we are in live mode, we can use zuluCrypt to create hidden encrypted volumes and unlock them. But be aware that everything you write into the system drive will be wiped upon shutting down, if you want to store something persistent accross reboots from live mode, you need to save it in a non-system drive.

[user /run/media/private/user]% lsblk
NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sr0                                            11:0    1 1024M  0 rom   
vda                                           253:0    0  200G  0 disk  
├─vda1                                        253:1    0    4G  0 part  /boot
└─vda2                                        253:2    0  196G  0 part  
  └─luks-24351c83-3657-4142-82d2-8f8a5787f406 254:0    0  196G  0 crypt /live/image
vdb                                           253:16   0   20G  0 disk  
└─vdb1                                        253:17   0   20G  0 part  

Here as you can see we have a non-system drive called /dev/vdb1, which, for our current testing purposes is only 20 GB big. Before we start encrypting it, let's format the harddrive using gparted to make sure the vdb1 partition is available for us to use:

Now that the /dev/vdb1 partition is available for us to use, let's create the veracrypt encrypted volume which will span the entire non-system drive:

Here is the important part: you need to mention Password A for the decoy volume (which is the outer volume, it will span the entire disk), and you need to mention Password B for the hidden volume (which is the hidden veracrypt volume where we'll be able to store our sensitive files)

Here you may need to click create twice as zulucrypt recommends you to use another format that it can't use, so click create a second time and then wait for it to create the volume:

And that's it! We have successfully created the veracrypt volume, so now let's mount each one:

Mounting the Decoy and Hidden Volumes

First let's mount the decoy volume (which we'll later use to store non-sensitive files, that would make sense for an adversary to keep in an encrypted drive):

Here as you can see, the decoy volume once mounted spans the entire non-system drive (in this case 20GB). So if you were forced to open it for an adversary, they would only find non-sensitive files (for example pirated movies or adult content) that are stored in it. And since the volume spans the entire drive, you can deny the existance of any other encrypted volume in there, and the adversary would be unable to prove otherwise. This means that our deniability is maintained.

Next we'll unmount the decoy volume to mount the hidden volume instead:

At this step you need to make sure that noone is watching you type this second password, as this second volume needs to remain a secret at all costs, it's existance is only to be known by you.

And now after unlocking the hidden volume (and revealing it at the same time), we see that it is 10GB big, as intended. And it is only in that hidden volume, that you can safely store your sensitive files which are meant to remain secret at all costs.

if there were to be any emergency where someone would be close to discovering that there is a hidden volume (meaning the adversary is busting down your door and is almost next to your monitor) all you need is to press Right Control to immediately reboot the host OS, to be able to erase all forensic proof that the hidden volume exists.