A additional write up for the Complete Guide To The Paranoid User has become evident after re-reading some older work. I missed the mark on some other key details that will be addressed in subsequent write ups. In this document I shall walk through the details concerning encryption, the needs, and the processes.
Symmetric encryption is what you typically think of when you think of encryption. With symmetric encryption the data is encrypted and de-crypted with the same key. It is by far the most commonly used form of encryption, because it is much more efficient and straight forward; however in order for it to work you have to have some way of securely giving the shared key to the recipient which can be an issue. Asymmetric encryption can solve this issue as well as do some other interesting things. Asymmetric encryption works with key pairs, one public and one private, usually associated with an individual or organization. How it works is you encrypt the data with the public key and then the data can only be de-crypted by the private key. This allows you to send encrypted communications/data to people without having first shared a key through some other channel. Additionally the private key allows us to digitally sign data that verifies it has not been modified from when it was signed, as well as it came from someone who has the corresponding private key to the public key that verified the signature. This is most often used for programs to ensure you’re installing exactly what the developers published and not one modified by a 3rd party. However it can also be used for anonymously verifying online personas. If you have some type of presence on a particular site, you could publish a public key associated with your persona and later you could verify that you are the same person somewhere else by signing something with the private key that can be verified with the public key you shared previously.
Something else to keep in mind with encryption is key versus password based encryption. As you might guess with password encryption, the key is derived directly from the password given. With key based encryption the encryption key is randomly generated to a predefined length. The only thing you really need to know is that key based encryption is orders of magnitude more secure than even a good password. Often encryption keys will be encrypted with a password, to add an additional layer of security. However the concern with keys is that if you lose the key, even if you remember the password for it, you will lose the data yourself at well. Password based encryption is more forgiving since as long as you remember the password you will be able to de-crypt the data.
We will start with just encrypting individual files. This is useful if you do not encrypt your hard drive, but have some files with important information you would want to protect in the event your device is lost or stolen (although drive encryption takes care of that for all your files) or if you are sending a file to someone through means you do not completely trust, like email or some sort of cloud provider. The easiest and most cross platform option is to use 7zip to create encrypted zip files of a single file or a folder. It only supports passwords, but that should be adequate for most circumstances, just send the password through some other channel such as text or other messaging app so that anyone who manages to stumble on the encrypted file on the Internet will not have access to it.
If you want to sign or encrypt a file with a key you will need to have GPG installed. This is typically installed by default on Linux and can also be installed on Windows with gpg4win which also includes the graphical interface Kleopatra (I have others listed in my Introduction To PGP article). Kleopatra integrates nicely into Windows, you simply need to right click on a file or folder to encrypt, sign or de-crypt the files. Additionally you can easily generate keys in Kleopatra by opening it and going to “File” and then select “New Key” and choose to create a new OpenPGP pair and at the screen where you fill in the name and email (does not have to be real, it is not verified) click “Advanced Options” and set it to RSA, either 3072 or 4096.
To encrypt a file with an RSA key pair, you will first need to import the public key of the recipient into your key ring. Once you have downloaded the key, again just go to “File” from within Kleopatra and select “Import” and then select the public key file you want to import. Afterwards when you encrypt a file with Kleopatra, it will prompt you with which key you would like to encrypt it with.
Although disk encryption may seem like overkill, I would still recommend it particularly on laptops you take with you places. To reiterate, an un-encrypted drive can be read more or less like a regular thumb drive without having to give the login credentials when booting the operating system. Now if for some reason or another, we do not want to encrypt our drive we also have the option of encrypted containers which are more or less sections of a hard drive that are encrypted rather than the whole thing.
The best time and manner to encrypt a device is when the operating system is installed and using the operating system’s built in tool. Both Mac and Windows have built in tools that can be enabled at any time without losing the data already on the drive. And for Linux there are solutions but they are variable and personally not recommended, one solution is LUKSipc. So it is much better to do it during installation (this is very easy, almost every distro it is just a checkbox you select during the install) although I suppose it is possible to backup your data somewhere, re-installed the operating system with encryption and then migrate your data back over. Although regardless of operating system you should do a backup before encrypting, even with the built in tool.
To see if your laptop or desktop computer meets the requirements for device encryption. You will first need to enable (or already have enabled) TPM and UEFI booting. Open Start, search for System Information, right click the top result, and select the Run as administrator option. Click the System Summary branch from the left pane. Check the "Device Encryption Support" item, and if it reads Meets prerequisites, then your computer includes support file encryption.
To enable device encryption on your Windows 10 Home laptop or desktop computer. Open Settings, Click on Update & Security. Click on Device encryption. Quick tip: If the "Device encryption" page is not available, then it is likely that your device does not support the encryption feature. Under the "Device encryption" section, click the Turn on button. Once you complete the steps, Windows will turn on encryption for the current and future files you store on your computer.
Again I would highly recommend going through the guide trying to enable TPM before resorting to the next option as first party tools are much less likely to have issues than third party ones, especially with something like encrypting the system drive. However this part is also relevant for non Windows users, because VeraCrypt is cross platform so is great for external drives as well as making encrypting containers on any operating system. However first I will cover a related topic which is verifying file signatures, which is something we will want to do when installing VeraCrypt.
Previously we discussed how private keys can be used to sign files so that the authenticity and integrity of a file can be verified. Although most of the software you download of the Internet will not have this option, for important programs such as VeraCrypt, Tor Browser, Installation images, etc. It will usually be provided and we will want to verify it ourselves. For example, a few years ago the Linux Mint installation image was replaced with a malicious one, verifying the signature would have shown that the malicious one was not signed by the Mint developers and you could have avoided installing it. Source: https://blog.linuxmint.com/?p=2994
To begin, we will first go to the download page of VeraCrypt’s site. https://veracrypt.io/en/Downloads.html
Linux: AppImage (Universal, portable): x64: VeraCrypt-1.26.24-x86_64.AppImage (PGP Signature) ARM64: VeraCrypt-1.26.24-aarch64.AppImage (PGP Signature)
As you can see they provide a link to their PGP key as well as show the fingerprint of it. Additionally you can see the signatures our separate files next to their respective installers, we will want to download both the installer and the corresponding signature and have them in the same directory (your Downloads folder is fine). First you will want to download the public key so it can be imported (to download it, right click on it and select “Save Link As” the default name and location is fine). Then open file explorer and right click on the file and you should see an option “More GpgEX options” if you have gpg4win and Kleopatra installed for Windows, for Linux you can open the file directly from Kleppatra or right click and run with Kleopatra. From that sub menu select “Import Keys” and then a window should pop up telling you one key as been imported.
You will note that it’s labeled as “not certified”. This just means that your computer does not know it can trust this key, however that is not necessary to verify the signature, but if you do want to certify it right click on the key and select “Certify” and you will then be prompted to make your own key pair if you do not already have one. Again this is unnecessary and we can verify it without certifying it. Next we will want to download either the exe / msi installer (For Windows) or the Appimage or corresponding linux file (For GNU/Linux) from the website along with it's corresponding signature file, both need to be in the same folder and the default Downloads folder is fine. From here we will simply open File Explorer and right click on the installer file (the one that does not end with .sig) go to “More GpgEX options” and select “Verify” (For Windows) or right click and select properties, then check "Program as Executable" (For Linux). Afterwards we will be presented with a "All operations completed" window. If you certified the key earlier the area with the text should be shaded green and telling you it is verified and trusted. However if you did not we can still verify the file, simply click “Show Audit Log” below and to the right of the progress bar and a new Window will pop up showing the fingerprint of the key that verified the file. We simply compare this fingerprint to the one shown on the website and if they match.
Alternatively (actually this would be the better option) we could compare the thumbprint to that of the key we downloaded rather than relying on what is on the website. To do so open Kleopatra and double click on the key we imported and at the bottom of the window, compare that to the fingerprint we got when we verified the file. Now we can consider the file verified and exactly what the developers wanted us to have and run the exe / msi or Appimage to install VeraCrypt.
There is 3 basic options when using VeraCrypt. You can encrypt the entire system drive, encrypt a non system drive (such as USB or external HDD) or encrypt a set amount of a drive. And remember that VeraCrypt is cross platform, so if you already have a Linux install and do not want to bother with backing up your data, reinstalling Linux with encryption and then migrating your data back, you could just do an encrypted container and put sensitive files in it. For this demonstration we will just be making an encrypted container since I recommend using your OS method of disk encryption for a system drive as well as it will allow me to cover the additional step of mounting the encrypted drive / container. If you do encrypt the system drive with it, whenever you boot the computer you will be presented with a black and white screen where you will be prompted for the password and PIM (just blank if you do not use it, which I would recommend).
You will want to open up VeraCrypt and select “Create Volume”. Next you will select what you will be encrypting, the options listed at the beginning of this section. The steps for all three are similar. For system drive you will not need to select a particular drive as VeraCrypt can figure it out (it’s the C: drive on Windows or /dev/sda on Linux if it does ask you) and if you are encrypting an entire non-system drive, you will just chose the USB/external HDD you are using, we will get to what to for containers in a bit. Next you will be asked whether you want to create a normal or hidden container. If you are not worried about law enforcement or the mob, just do a normal container, if you are I would recommend reading the manual for VeraCrypt but I will be listing the steps below.
Hidden volumes are not magic. If you sloppy-mount, write to the outer without protection, let your OS leak recent files, or you live where key disclosure is legal, deniability can fail. Treat this as one layer, not the only layer.
A) Create the outer volume 1. Open VeraCrypt choose Create Volume, then Create an encrypted file container. 2. Choose Standard VeraCrypt volume. 3. Select File, pick a normal name, for example VacationPhotos.dat. Avoid sketchy paths. 4. Encryption options: defaults (AES and SHA-512) are fine. Security outweighs speed here, so layer multiple encryption algorithms, starting with AES. For example, stack AES with Twofish or Serpent for additional security, even if it slows things down. 5. Volume size: pick something that fits both decoy and hidden later. Example: 40 GB total if you plan 6 GB for decoy and about 20 GB for hidden with headroom. 6. Set the outer password. Make it long and different from your hidden one. Skip a keyfile for the outer to keep the story simple. 7. Filesystem: Windows only: NTFS Cross-platform: exFAT Linux only: ext4 8. Click Format. VeraCrypt fills with random data, which enables deniability. B) Build a believable decoy Mount the outer volume with the outer password. Add harmless files that fit your profile (ebooks, school PDFs, screenshots, photos). Open and edit a few so timestamps look natural. Do not fill it; leave space for the hidden volume and later edits. Dismount. C) Create the hidden volume 1. Create Volume again, choose Hidden VeraCrypt volume, Normal mode. 2. Select the same container file you made for the outer. 3. VeraCrypt scans free space and suggests a size. Pick a size that fits your real data and leaves free space for outer edits. If the outer is 40 GB with 32 GB free, set hidden to about 20-24 GB. 4. Set a different, stronger hidden password. You can add a keyfile only if you can keep that story straight. 5. Choose filesystem and Format. 6. Done: two volumes in one file. Opening the hidden volume Mount, enter the hidden password, work, then dismount. In Preferences enable wiping cached passwords on exit. Set a hotkey to dismount fast. Opening the outer without damaging the hidden Mount with the outer password. When prompted, choose protect hidden volume against damage. Enter the hidden password so VeraCrypt can block overlapping writes. Make occasional harmless edits in the outer volume to keep the decoy alive. Keep the decoy believable Open it sometimes and save a note or tweak a doc. Do not keep only archives; include loose files and folders. Match filenames to contents: if it says Photos, include some photos. System hygiene that actually matters Windows Disable hibernation, powercfg /h off. Clear pagefile at shutdown, set ClearPageFileAtShutdown=1, or use Group Policy. Turn off indexing for the mount point: right-click the mounted drive, Properties, uncheck indexing. Enable auto-dismount on logoff or power saving in VeraCrypt. MacOS Exclude the mount point from Spotlight, mdutil -i off /Volumes/YourMount. Avoid Quick Look on sensitive files to limit thumbnail writes. Use FileVault so swap and temp files are encrypted at rest. Linux Use encrypted swap, or disable swap while working with sensitive files. Mount with noatime if you care about access‑time writes. Prefer an encrypted home for where the container lives so temp files and thumbnails are covered. All platforms Do not let cloud sync touch the container while mounted. Only sync the closed file if you accept size and modified-time metadata exposure. Name the file something boring and place it somewhere boring. Back up the closed container and protect the backup with the same OPSEC. Key choices that influence deniability Passwords: the outer should be strong but believable; the hidden should be very strong. Keyfiles can help but complicate your story. If you use one for hidden, store it somewhere natural and never mention it. Sizes: do not make the hidden area consume all remaining space. Leave slack so the outer can still be used. Container vs partition: files are easier to explain; partitions can be cleaner on Linux. Pick what matches your profile. Common mistakes that break the model Writing to the outer without enabling protect hidden volume. Letting your OS leak file paths in recents, thumbnails, office histories. A decoy with zero edits for months looks abandoned. A weird path or suspicious filename for the container. Talking about the setup; plausibility dies when the story leaks.
For a container, now you will be asked where you will want to create the container. Click “Select File” and File Explorer will open up, select the folder you want the new container to be in and then give it a name. Afterwards it should have the path to the new file you created. In this example I name it “container” and had it in my user’s Documents folder. Next you will be asked about the encryption and hashing methods for it to use, the defaults are fine so feel free to use them. The next part is only relevant for containers, not when encrypting entire drives. You will be asked to select the size of the container. If you do not know how large to make it, just make it 1 GB to be safe (for anything besides video, that is a lot of space) although note the default value is MB not GB, so be aware of that so you do not accidentally set it to 1 MB. Afterwards you will be prompted for the password for the volume as well the keyfile and PIM settings. Since we are mostly doing this to stop a some what tech savvy thief (or the person he sells the device to) from easily reading our data, using either of these options is not really necessary.
The next part is where you provide random data for the encryption key as well set a few options like file system to use. If you do not know what file system to use, just use exFAT. Although if it is a container that is smaller than 4GB you could also use FAT without issue (FAT cannot handle files larger than 4GB, exFAT it is not an issue at all). Additionally for our purposes feel free to check the “Quick Format” option as well. Lastly, move your mouse around in the window until the bar turns green. Now, if we made a container or encrypted a non-system drive, we will need to mount it through VeraCrypt so that your operating system can use it. To do so open up VeraCrypt and select a drive letter for what you will want the container / drive mounted as and then select “Select File” for a container or “Select Device” if you encrypted an entire non-system drive.
In this case, I will be mounting the container I made as drive A: the file has already been selected and it is path is shown in the box. If you allow VeraCrypt to save history, in the future you can just chose from previously mounted drives / containers with the drop down menu. From here just press “Mount” and provide the password when presented. After it is done mounting VeraCrypt should show the container / drive as mounted and the drive letter should be available in File Explorer for you to place and retrieve files from.
Although it does not necessarily involve encryption, it can and it is very relevant to protecting personal information. Whenever you get rid of a disk for whatever reason, you will want to wipe it or otherwise make the data on it inaccessible, whether you are intentionally giving it to someone else or just throwing it away. Additionally we will also cover sanitizing individuals files versus an entire disk. One thing that should be mentioned first is the differences between an SSD and HDD. I will not get into the technical details, but what is relevant is that with an HDD your computer more or less has full control over where data is written on the disk, making it very easy to over write old data. However with SSDs your computer does not have the same control, in order to extend the life of the disk the drive itself will determine where it writes new data to. This can cause issues because if your computer tells the drive to overwrite a particular file, the drive may decide to write the new random data somewhere else on the drive that is been written to less in order to prevent that particular section to fail before the other because it is being written to more often.
First let us clarify what happens when you normally delete a file. When a file is stored on your drive and file system there is the file data itself and what we will call a pointer to the file data. This pointer contains the file’s metadata (timestamps, size, name, etc) as well as the location on the disk of the actual file data, additionally this pointer is located inside the file data of a folder (which is why moving large files on the same drive is instant, because the file data is not actually being “moved” just the pointer to the data). Normally when a file is deleted all that happens is the pointer is removed from the folder’s file data and area on the disk where the file data is located is marked as “unused” however the data is still there and not overwritten. (Note: this is after a file has been removed from the recycle bin or similar, the recycle bin is essentially just a special folder that deleted files are initially moved to). Granted, it does take a fairly tech savvy person to recover deleted files, however plenty of free programs exist out there that will recover deleted files if they have not yet been overwritten by anything.
In order to actually overwrite a file’s data so that it is not recoverable, we will need a program that will tell the drive to overwrite a specific portion of it’s self (where the file is located) with either random data or to just write zeros at that location. The two programs we will discuss are SDelete for Windows and SRM on Linux, the two are used nearly identical, but with slightly different options. I will demonstrate with both the Windows program and on Linux.
*For Windows sdelete
*For Linux Remove a file after a single-pass overwriting with random data $ srm [[-s|--simple]] [path/to/file] Remove a file after seven passes of overwriting with random data $ srm -m [path/to/file] Recursively remove a directory and its contents overwriting each file with a single-pass of random data $ srm [[-r|--recursive]] [[-s|--simple]] [path/to/directory] Prompt before every removal $ srm [[-i|--interactive]] [\*]
This will overwrite the file’s data once with random data (srm will do 3 by default) as well as remove the pointer from the folder that holds it and the file will not go into the recycle bin or equivalent (On Windows even files deleted normally from the CLI, using the “del” command, don’t go to the recycle bin). This process can be quite slow, especially on large files. Thankfully overwriting the data multiple times and with random data is overkill, we can use sdelete with the -z option to overwrite the file with just zeros which still makes the data unrecoverable, but does not take as long since the computer does not have to generate a bunch of random data to overwrite with.
Note 1: Recovering data that has been overwritten is technically recoverable, however it is a advanced procedure and I am not aware of any examples of it being done except for very small amounts of data as a proof of concept. However it is worth nothing that many government agencies and corporations require that disks that contained sensitive information be overwritten 7 times, meaning that for government intelligence agencies recovering data overwritten once is likely within the realm of possibility. However for our purposes, overwriting once is more than enough to prevent a random person from running a program that will recover normally delete files.
Note 2: As mentioned at the beginning of this section, this method is not 100% reliable on SSDs as your computer cannot control exactly what parts of the drive are written to unlike HDDs. It is still worth doing on SSDs as it likely will work, however to be absolutely be sure, you will want to zero out all unused space on the disk after the file in question has been deleted. To do this with sdelete use this command run as administrator $sdelete -z C: or on Linux $sudo dd if=/dev/zero of=zero ; sync ; rm zero
Since the previous method was mostly relevant for HDDs and how common SSDs are these days, we will begin with SSDs. To solve the problem of sanitizing SSDs, most SSDs have a feature called “Secure Erase”, which is accessed through your computer’s BIOS, which wipes the SSD completely as well as the drive is usable as a completely blank drive afterwards. For wiping HDDs, your best bet is to use Linux live booted from a USB stick. I have previously written about Persistent USBs and cover this in An Introduction To GNU/Linux.
Once you are booted into the Live Linux disk, open a terminal and type “lsblk” to list all disks attached to the computer. Since to be safe, the only drives that should be connected are the live USB and the disk you intend to wipe, there should only be two disks shown /dev/sda (and it is partitions /dev/sda1 /dev/sda2 etc, which does not matter for our purposes) and /dev/sdb. Since /dev/sda will always be the disk which the operating system loaded from, the disk you want to wipe will likely be /dev/sdb, however to make sure check the sizes of the disks. If the USB stick is 8 GB and the drive you want to wipe is 500GB, make sure /dev/sda is 8 GB and /dev/sdb is 500 GB. Assuming the drive you want to wipe is indeed /dev/sdb. Use the following command to completely overwrite the disk with zeros $dd if=/dev/zero of=/dev/sdb. Additionally if you want to use random data instead of just all zeros, you could replace /dev/zero with /dev/urandom. However again, for our purposes all zeros is sufficient.
In this (not so brief) write up I hopefully covered the importance of encrypting your data, along with proper technique to sanitizing and wiping your data. While I did extensively cover VeraCrypt as an encryption option there are other available options like Ciphershed and Cryptomater.