WEBVTT 00:00.000 --> 00:06.700 in environments where surveillance, coercion, or seizure are actually real threats. 00:07.580 --> 00:15.340 Standard encryption alone leaves you exposed. You could argue it keeps your data confidential, 00:15.940 --> 00:21.480 what happens when someone puts a gun to your head and basically asks for the key that way, 00:22.180 --> 00:31.200 or when a judge threatens you with contempt charges. If the adversary knows you're using encryption 00:31.960 --> 00:39.540 and you can't explain away the encrypted material, you're pretty much done, right? 00:39.940 --> 00:46.680 So that's where deniable encryption actually comes in. The art of hiding secrets so well 00:46.680 --> 00:53.740 that you can convincingly claim that they never actually existed. Deniable encryption is a class 00:53.740 --> 01:01.380 of cryptographic techniques that allow users to encrypt data in such a way that the existence of 01:01.380 --> 01:09.040 certain information can be basically denied under direct scrutiny. And the goal extends far beyond 01:09.040 --> 01:16.820 keeping unauthorized users out, like if you want to make it impossible to prove additional 01:17.360 --> 01:24.020 undeclared data exists at all. The concept emerged in the early 1990s when researchers 01:24.540 --> 01:32.200 began exploring ways to actually protect users against rubber hose cryptanalysis, the charming 01:32.860 --> 01:41.660 practice of beating encrypted keys out of people with actual rubber hoses. Like in 1997, 01:42.140 --> 01:50.380 Ross Anderson and Roger Neatham and Andy Schimer, sorry if I missed your name, formally introduced 01:50.380 --> 01:57.980 the idea in their paper, the second and graphic file system. Their system posed a method where 01:57.980 --> 02:04.180 multiple encrypted files could coexist on the same physical security with different passwords, 02:04.560 --> 02:09.860 unlocking different layers of data. That makes sense. Simple but really powerful, 02:10.040 --> 02:16.060 if someone forces you to unlock your actual encrypted files, you reveal only the decoy 02:16.060 --> 02:22.640 volume and convincingly deny that anything else exists. The model was later implemented 02:22.640 --> 02:29.100 in tools like TrueCrypt and its successor, which is Veracrypt, which introduced the hidden volume 02:29.100 --> 02:35.380 feature. The user creates an encrypted container within another encrypted container, each with 02:35.380 --> 02:41.960 different passwords. One password reveals your tax returns, let's say, and cat photos, 02:42.280 --> 02:48.880 and that's the decoy. Another reveals your XMR wallet, Bitcoin wallet keys, or whatever 02:48.880 --> 02:54.620 else that you'd rather keep private. Crucially, the existence of the second volume remains 02:54.620 --> 03:01.260 completely undetectable. Even advanced forensics can't really distinguish between unused disk space 03:01.260 --> 03:07.040 and hidden data. And there are two main types of deniable encryption that actually exist, 03:07.140 --> 03:14.400 this storage base deniability, which is physical or logical structures like disk volumes, for 03:14.400 --> 03:20.840 example, that contain multiple layers of encrypted data without actual revealing that more than one 03:20.840 --> 03:27.800 actually exists. Examples include Veracrypt hidden volumes or graphic file systems like Julina 03:27.800 --> 03:35.420 Sange's old rubber hose project from 1997. So that one's dead. We come to communication-based 03:35.420 --> 03:42.440 deniability. And here users can plausibly deny sending, receiving, or possessing 03:42.440 --> 03:48.880 certain messages. Secure messaging protocols like off the record, which is now outdated, or signals 03:48.880 --> 03:56.460 double ratchet algorithm also ensure that conversation transcripts can't be cryptographically 03:56.460 --> 04:02.140 authenticated after the fact, preserving things like plausible deniability. That you're carrying 04:02.140 --> 04:10.000 a blocked briefcase. A traditional encryption gives you a single key and forces you to open it. 04:10.000 --> 04:15.480 And everything's exposed once that happens. Deniable encryption, however, creates multiple 04:15.480 --> 04:23.260 secret compartments inside and like each accessible with a different key, more or less. Under coercion, 04:23.680 --> 04:29.080 you open one with the boring documents, no evidence exists of the actual other 04:29.080 --> 04:35.840 compartments in high risk environments. This becomes rather essential because of 04:35.840 --> 04:42.640 his reasons. So we'll take Ross Olberg, for example. Now, when the FBI actually grabbed his laptop in 04:42.640 --> 04:49.120 that San Francisco library, they called him logged in and it was game over. But imagine if he'd used 04:49.120 --> 04:56.460 proper, deniable encryption with a duress password that wiped the real data while actually 04:56.460 --> 05:03.200 displaying a decoy. Journalists and authoritarian regimes, dissidents and whistleblowers, 05:03.200 --> 05:10.940 or anyone operating in legally gray areas needs systems where sensitive material, 05:11.440 --> 05:17.740 the existence of that kind of stuff actually remains cryptographically deniable. If an adversary 05:17.740 --> 05:24.180 can't actually prove the protected data exists, coercion loses its teeth. Deniable encryption 05:24.900 --> 05:32.840 demands careful execution. Success absolutely depends on plausibility of how believable your 05:32.840 --> 05:40.700 decoy actually appears. An empty volume or one filled with obvious generated junk raises some red 05:40.700 --> 05:46.680 flags faster than a custom agent finding a kilo of white powder in your luggage. And if your 05:46.680 --> 05:52.540 device shows 500 gigabytes used, but your actual decoy volume contains say three word 05:52.540 --> 05:56.860 documents, investigators are going to piece together if there's an issue. Effective deniable 05:56.860 --> 06:05.340 encryption requires chaff files, so to speak. There's stage documents and it's time consuming 06:05.340 --> 06:12.100 kind of metadata to try to sell the illusion. Forensic memory analysis poses another threat. 06:12.380 --> 06:20.200 See the device while powered on and RAM dumps may expose encryption keys, usage logs, or signs 06:20.200 --> 06:25.880 of hidden containers. Chelsea Manning, for example, learned this the hard way. Investigators 06:25.880 --> 06:34.040 recovered chat logs from RAM even after deletion. Proper operational use demands hold shutdown 06:34.040 --> 06:41.820 protocols and amnesic systems, like tails, which clear RAM on power loss. Then there's the 06:41.820 --> 06:47.980 whole legal minefield and some jurisdictions make refusing to decrypt data a crime in 06:47.980 --> 06:55.140 itself. And the UK's repo or regulation of Investigatory Powers Act can actually land you 06:55.140 --> 07:02.040 in prison for up to five years just for staying silent about your passwords. And in 2007 a British 07:02.040 --> 07:08.440 citizen got 14 months for actually refusing to decrypt his device at the border. Now the 07:08.440 --> 07:13.620 United States has the Fifth Amendment, but courts increasingly find kind of creative ways 07:13.620 --> 07:20.700 to try to circumvent it and get around it. Biometric locks, for example, are not testimonial, so 07:20.700 --> 07:27.080 no Fifth Amendment protection actually exists. Deniable encryption offers a solution for this, 07:27.280 --> 07:33.220 comply with demands while also protecting what actually matters. File systems betray you in 07:33.220 --> 07:41.180 a ton of different ways. So swap files, indexing services, thumbnail caches, like 07:41.180 --> 07:46.540 recent file lists all leave breadcrumbs of some kind, pointing to hidden activity. 07:47.080 --> 07:53.700 Windows helpfully creates shadow copies of files that you thought you actually deleted. 07:54.160 --> 08:01.280 Mac OS indexes everything from spotlight search that actually happens. So even accessing a file 08:01.280 --> 08:09.840 on a hidden drive might leave traces in system logs. Deniable encryption must pair with full 08:09.840 --> 08:17.540 device operational security. So stuff like secure bootloaders and journaling suppression and encrypted 08:17.540 --> 08:25.960 swap or no hibernation and minimal or ephemeral post systems, right? Real-world example is in 08:25.960 --> 08:32.440 2020 German police raided a Dartmouth vendor's home and they found varicarp volumes but couldn't 08:32.440 --> 08:38.100 actually prove hidden volumes existed. And the vendor provided the outer volume password 08:38.100 --> 08:46.080 revealing cryptocurrency trading records and plausible for someone like him interested in 08:46.080 --> 08:51.780 things like privacy. The hidden volume with the vendor's data remained undetected and 08:51.780 --> 08:58.080 he walked eventually, right? So ultimately, deniable encryption provides control over 08:58.080 --> 09:05.100 what your adversary can actually prove exists and not just who can actually access it, it adds 09:05.740 --> 09:12.400 uncertainty to the surveillance equation making it almost impossible to know if the entire truth 09:12.400 --> 09:19.020 has actually been extracted and that uncertainty protect the operator. So a good thing to do is 09:19.020 --> 09:24.900 to ask yourself like if law enforcement kicked in your door right now, could you provide access 09:24.900 --> 09:31.260 to a decoy that would stand up to screw you, right? Could you hide what actually matters 09:31.260 --> 09:38.680 while leaving zero evidence it ever even existed? Because relying on encryption alone is kind of like 09:38.680 --> 09:46.240 bringing a knife to a drone straight like technically your armed but you still kind of 09:46.240 --> 09:50.320 screwed, right? Thank you for watching to the end and as always, I'll see you in the next video.