4 ms·
"Denial of encryption" is no different from "Denial of having password", and leads you straight into XKCD 538. If the adversary does not belive you, their best
by phkamp 6y ago
"Denial of encryption" is no different from "Denial of having password", and leads you straight into XKCD 538.
If the adversary does not belive you, their best bet is to keep torturing you, until they get their way.
What you want is "Proof of inability to decrypt" so that the adversary has nothing to gain by waterboarding you.
See also: https://papers.freebsd.org/2004/phk-gbde/ https://papers.freebsd.org/2004/phk-gbde/
- adrianmonk 6y agoI think there are some situations where there might be a difference: ones where the adversary does not know for sure whether the data exists. For example, suppose you work in the IT department of a law firm, something fishy is going on and you want to be a whistle blower, and you need a way to exfiltrate some evidence. You are getting rid of some obsolete laptops, and standard procedure is to wipe the drives before selling them. Management has its suspicions about you because you've been asking too many questions. So they get another IT person to check the drives you were supposed to wipe. If the drives have the data on them with a LUKS header, you've been caught (or at least they think you were too lazy to wipe the drives). If it's indistinguishable from random data, then you've given them no reason to suspect you.
- marcinzm 6y agoSure in that scenario but I feel that's an edge case scenario. More commonly a machine you use is acquired by an adversary. Thus the machine is expected to have a working installed OS on it. If that laptop lacks an un-encrypted partition then the adversary will assume it is encrypted. They don't need to mathematically prove it.
- na85 6y agoIf I suspected an employee was up to something and they wanted to dispose of old laptops, I would send another employee to physically destroy the drives with a drill or a saw.
- phkamp 6y agoThis scenario suffers from what I call "IT-Dude-Syndrome". IT-Dude-Syndrome is when IT-people come up with scenarios which hinge on "IT-Dude" being smarter than everybody else in the whole world. First, if you're suspected of anything in a law firm, you're out until the issue is resolved, you don't get to "destroy old laptops" or anything of that sort. In a high-security operation you don't even get to touch a laptop, and you will be handed a loaner-phone, while your own phone is turned off, signed, sealed and stored in a safe until the matter is resolved. Second, if "standard procedure" in that law firm is to "wipe the drives before selling them", that law firm is not following best, or even minimum, security practices for the business they are in, and that is what the whistle-blower should report to the relevant authority. Third and most significant, IT-dude is smarter than the obviously junior IT-dude called in to "check the drives" IT-dude "were supposed to wipe" ? You know what, he's not. In such scenario you can be damn sure, that whoever is called in to check is several levels smarter than IT-dude. And you know what super-IT-Dude will do when she see the disks full of high entropy data ? She will point to the final step in the official procedure for wiping disks, which is to write all zeros to the entire media to prove that there is nothing hidden. She will write in the report that IT-dude did not follow a trivial procedure to the letter, and point out that the most likely, in fact the only credible, explanation for skipping a trivial step in the procedure, was that IT dude were trying to exfiltrate data.
- viraptor 6y ago> If it's indistinguishable from random data, then you've given them no reason to suspect you. It depends on the IT person really, your company, and your opsec. Does your shell history contain luks commands? Are your logs clean from any trace of mounting? Are dirty blocks on the disk free of that data too? Are your machines centrally managed with logs shipped out? Do your local logs look like they've been only continuously appended to, or are there likely uneven rewrites? Does your system contain encryption software you're not using in normal operation? If you really want to hide that information, the encryption itself looks like the smallest issue.
- n0on3 6y agoIf you face an adversary that is willing to torture you and can get away with it what you __really__ need is to deny the opportunity to do so. I find it naive suggesting that "Proof of inability to decrypt" can lead to a positive outcome in such scenario.
- phkamp 6y agoThere are no "positive" outcomes in that sort of situation. Being able to prove that you cannot possibly decrypt the partition, moves you out of the XKCD 538 scenario. That is a "much less negative" outcome.
- n0on3 6y ago> Being able to prove that you cannot possibly decrypt the partition, moves you out of the XKCD 538 scenario. It does not. I think your mistake is modelling an adversary willing and enabled to torture like an entity that behaves like you would do, which I assume is according to logic + knowledge + willing/able to communicate + respect for human life. How about the adversary just not buying your proof and torture you anyway (to death) just in case you are trying to deceive? How about the adversary not even giving you the opportunity to explain or show your proof? (imagine getting yelled "open it" because they don't speak much english other than that and get beaten for whatever you do that doesn't look like "opening it") I'm writing this just in case someone reading will actually at some point need to prepare for such threat. "Proof of inability to decrypt" (as also "Denial of encryption") does not give you a way out of the "XKCD 538 scenario". If you can't avoid the scenario entirely, there are better bets (e.g., disguise still-encrypted data as plausible, non-sensitive other data).
- phkamp 6y ago"in case someone reading will actually at some point need to prepare for such threat" You mean like any human rights organizations who send people to authoritarian states ? You mean like any Foreign Ministry sending a courier out in the world ? You could learn so much about operational security, if you wanted to, just by reading open sources. Can I recommend you start with a wonderful old article called "A first tour like no other" ? If your adversary model is a wild-eyed gun-slinging mid-west racists and you are black, then encryption is not going to be a factor in your death, and speculating what you can or cannot convince them about is besides the point. If a sane adversary has captured you and your devices, say border police in some police-state like Belarus, Brazil or USA, it would be silly to assume that you know more about disk-encryption than they do. Most importantly, you would be very silly to assume that they will not simply lock you up, until you provide access to the device, aka "XKCD538-lite". There are people who have languished in hell-hole jails for years already, not because they are unwilling to provide access, but because they cannot provide access, but are unable make a convincing showing of that. Competent organizations make sure their travelers can make that showing convincingly, and one of the steps they take, is to make 100% sure there is no unexplained high-entropy data on their devices. Imagine ending up in a foreign jail for years, just because you once deleted a huge gzip'ed file, and the first sectors subsequently got overwritten ? Yeah, that happened: "Now decrypt this other secret partition!"
- eeZah7Ux 6y agoPlease stop quoting XKCD 538 like doctrine. Reality is way more complex. E.g. if a company has a policy of wiping external drives and SD cards before each trip and the policy is religiously [or automatically] followed it becomes clear that harassing employees on a trip for having wiped drives is pointless. Also a lot of organizations that are ready to torture people do that regardless of the quality of information that they can gain.