Obscurix – Arch Linux-based OS configured for privacy, security and anonymity
obscurix.github.io
obscurix.github.io
A big difference is the base distro.
I used Arch for many years, so I love it as daily driver.
But for a security-critical context such as this, Debian with it's stability and very security-aware package maintainership seems like a better choice.
Some answers are in the FAQ: https://obscurix.github.io/faq.html
Or Centos.
From Obscurix FAQ:
"Whonix is another anonymity focused operating system. It is meant to be run inside virtual machines instead of from a USB like Obscurix. Whonix has a more leak-proof method of forcing all traffic through Tor but it isn't amnesiac or forensics resistant like Obscurix."
Basically, Whonix requires a VM sandbox escape in order to leak your IP address. Obscurix does not have any comparable protection against malicious applications leaking your IP address. The purported advantage of Obscurix is its "amnesiac" property, but it doesn't sound very compelling. Everyone should be using full disk encryption in any case, regardless of what OS they are running or what other steps they are taking to improve security. It's not clear to me why I should care about the amnesiac property of the OS when everything is encrypted.
If you're uploading whistleblower documents to Wikileaks, sure you could use Amnesiac to do the upload, but where are the documents? Are they on an unencrypted USB stick? You clearly need encryption for this use case.
Are you buying/selling drugs on the Tor network? You probably need some cryptocurrency keys, where are they? On a USB stick in plain text? You clearly need encryption for this use case.
Or maybe you're a security researcher who's trying to anonymously report a vulnerability to a corporation that's known to go after researchers. Where is your poc code? On an unencrypted USB stick? You clearly need encryption for this use case.
If I was working on important whistleblower documents, I wouldn't trust a cloud storage service as the sole location for the documents. I would need at least some form of backup. Furthermore, if the point was to hide the existence of encrypted data, you would have to also hide your payments to said cloud service provider. So at this point we would need to:
- Set up (locally encrypted) storage to cloud service provider 1, and a similar backup to cloud service provider 2.
- Learn cryptocurrency washing mechanism to hide continuously ongoing payments to cloud service providers.
Note that both of these would have to remain in your memory, since you wouldn't be able to save anything (like "download_encrypted_data_from_cloud_storage.sh") on the amnesiac OS.
But you can totally set up a “download encrypted blob from external data storage” script if you want. You can do a whole lot depending on what resources you have available.
Remember where this conversation started? You said "Amnesiac is a level above FDE. You can’t be compelled to decrypt that which does not exist." Well, if the USB stick that contains the amnesiac OS also contains a script for downloading an encrypted blob from cloud storage, then obviously we are back at the "being compelled to decrypt" issue that we started from. If we're going to have an encrypted $TOP_SECRET document, we might as well encrypt the whole disk. And at this point the amnesiac property of the OS doesn't really provide a lot of benefit.
Also, more importantly, why are encryption and this amnesiac property mutually exclusive? Can't you do both and use the strongest available guarantees that are applicable to a particular set of data? Seems like it'd at least make the job of an attacker more annoying at the least.
Sure. The amnesiac property just doesn't add a lot of security on top of full disk encryption. If you have an encrypted USB stick that contains an amnesiac OS and $TOP_SECRET_DOCUMENT, the information that your adversary cares about is the document. If the adversary somehow breaks the encryption, they still get access to the document, regardless of the amnesiac property of the OS.
Should they? Regardless of threat model? It's point and click easy on macOS (and probably Windows) so sure why not, but a bit more involved on Linux. I think encrypt a directory (ies) that actually warrants protecting is enough for most people, where the threat is casual even opportunistic theft rather than an organised, targeted attack.
Not sure it matters if it's full-disk vs just home directory, but full disk is easier to reason about and I don't recall an OS that can do homedir easily but not full-disk (there very well could be one, just none come to mind).
Directory-level encryption is harder to set up and use—it requires typing your passphrase more often and makes you choose third-party software instead of using the features built into your operating system. Plus, lots of important files, like your browser's autofill information and other files that aren't considered "critical", are left wide open.
Encrypting your home directory is better than encrypting the "TOP SECRET" directory, but it's still just as hard as setting up full-disk encryption while being less effective.
And what's the difference in what you're protecting that affects the average user? Why stop at FDE - they should be worried about cold-boot attacks too right!?
My first thought as an adversary would be "Hey! This looks out of place! this guy must really want to protect whatever this is".
Typically, I will [1] customize my own installation media to do or contain whatever software or configurations I need without a third-party making assumptions for me. This is quite possibly what I like most about Arch Linux. I know what is going on under the hood because I set it up. I'm likely not a typical user for most spinoffs. I use Arch Linux, FreeBSD, Gentoo, RHEL, Debian, SLES, and Ubuntu for different use cases as required.
[1] https://wiki.archlinux.org/index.php/archiso
*EDIT: Forgot and added a couple distros that I actively use (wish I could consolidate to one. Maybe one day)