This works like TrueCrypt hidden volumes, which are volumes created in the free space of volumes.
This is not secure against multi-snapshot adversaries, like those who can take multiple snapshots of your storage at different times.
The solution is to hide the access pattern, for example by using a write-only oblivious RAM.
I'm currently working on a cloud database that uses searchable encryption. In a database the smallest things can hurt you, both the access and search pattern (must hide the encrypted data that satisfies the query condition or multiple query conditions, the volume of that data, and hide which queries are identical). And the attacker can have auxiliary information (known-data, known-query, inference).
On top of that the database must be verifiable (authentical, sound, complete, fresh). Encrypted and non-encrypted data might be searched together (partitioned data security). A database must be resizable, that's the point of a cloud database. And then there is data sharing. And it must be cheap. The existing solutions in the literature either compromise security or practical efficiency.
Sure, the project is called Endpipe and it's an attempt to create a privacy-preserving cloud database. The idea is a Google Cloud Firestore alternative that works offline and synchronizes in real-time, but without the data being accessible to the server. The encryption key never leaves the client or trusted proxy.
We want to keep sensitive data like Protected Health Information (PHI) from getting into the wrong hands. Any hands really, but yours. You own your data.
Endpipe is offline-first and needs client storage to be secure and practically efficient, so it's different than most cloud databases. The client is trusted, and there can be also a trusted proxy, the server is untrusted. The server is distributed and maliciously secure, it can have arbitrary number of Byzantine-faulty replicas. It is a multi-model database (document, object and file) with range queries, automatic indexing and eventual consistency with explicit causality, which is used for conflict resolution. There are conflict-free operations for collaboration. It is multi-platform, the client core is being written in C/Zig/WASM on top of SQLite. Android, iOS, Linux, macOS and Windows are supported, eventually the web will be once there is a better File System Access API with origin private file system support. A Dart/Flutter library is the first priority, that is the beachhead. The supported data types are Bool, Int, BigInt, Double, String, DateTime, List<E>, Set<E>, Map<K,V>, Uint8List, Uint16List, Uint32List, Uint64List, Int8List, Int16List, Int32List, Int64List, Float32List and Float64List. Collections are generic, E, K and V identifies the type of objects they can store, which make collections homogeneous, but heterogeneous collections are also possible by not specifying the type. Our serialization format is space efficient, integers up to 127 are represented by one byte, smaller and larger integers use a variable-length (1 to 9 bytes) zigzag integer encoding. There are holes for supporting arbitrary-precision binary and decimal floating point numbers in the future. Large values up to 16 TiB are supported. Query results are available as data streams, they receive realtime updates, however Endpipe can delay updates for query smoothing. Endpipe can issue fake queries, prefetch or buffer data from the server data structure, which is essentially a dynamic volume-hiding encrypted multi-map with forward and backward privacy.
> management engined access to registers and DMA being a weakness
If you are talking about Intel ME on the client, we trust the client, we have no other choice. Client-side encryption is planned, it would offer some protection against snapshot adversaries, but not against a persistent adversary that has access to your device. History independence to be able to do secure deletion is not a goal.
On the server it doesn't matter whether it is curious or malicious, our threat model is a persistent adversary that has continuous total access to the server. Endpipe uses the server interactively to store and retrieve encrypted data, and the server is allowed to spy and lie, it's only function is to send the original data back, which the client can verify.
> The capability of plausible deniability is that the encrypted file is indistinguishable from noise; There is no way you can find out the amount of data stored in the cryptocontainer.
The problem with deniable encryption is: if the attacker can watch the file changes, one can determine the rough size of the data in the volume. The attacker makes note of where in the file changes occur. Once you get them to unlock the file you see if the data is shorter than the size of file changes. If so, you know there is more data.
Once an attacker can see your encrypted volume, you can no longer make changes to the hidden data.
This presumes that you’re working in a random-access manner with your data. A lot of deniable-encryption use-cases involve archival access (i.e. tossing new files into the container, with each written file then treated as immutable.)
An attacker watching the side-channel of your access pattern would just see you growing the volume. But that doesn’t tell them whether you’re adding new real data, or adding noise.
An important part of deniable encryption is that you can "provably" deny data isn't there when it is. You want the authorities to agree that when you unlock your volume they see "all" of your data so they don't hold you in contempt. If the total changes is less than the data visible, the assumption is you're hiding more data. Adding noise isn't deniable. In fact, it would hurt you: If you can't prove your noise is noise then the authorities are going to assume you are hiding data.
I think you make a good point: the only way to be secure in this method is to A) work on an uncompromised machine and B) write each layer in series and C) never change it again.
Noise should be added either in a fixed pattern or randomly. Eg consider a disk of size 2^N, with volumes of size 2^(N-1), 2^(N-2), 2^(N-3), ..., 2^(log minsize). Blocks would be written such that every second block is for volume -1, every fourth block is for volume -2, etc. Data for lower volumes should be queued to be written in turn; when the turn comes up, if the queue is empty (or less than a appropriately-distributed[0] random amount full), a appropriately-distributed[0] number of new blocks should be added to the queue.
(Note that you'll also need a compaction phase when the disk fills up; I don't think that can be done without the keys for the lower volumes (or losing that data), so you need to be careful to regularly compact while in a safe environment.)
0: This requires some tuning depending on general (but obviously not specific) expected usage.
> The problem with deniable encryption is: if the attacker can watch the file changes, one can determine the rough size of the data in the volume.
I think it's even more basic than that. An attacker just needs to know you've used such a tool (by using FractalCrypt, eg) to know you're not really unlocking it.
After that it's pretty much game over, at least on being able to have deniability.
This is a specific threat model where the attacker can watch live file changes undetected. This may be acceptable e.g. for a laptop without historical archives of the file.
Good point and good to be aware of. Still, it requires dedicated physical access and specialized physical equipment, right?
I think that at least for the foreseeable decade or so, there are only a handful individuals globally for whom this would be a practical vector rather than a purely theoretical one.
It'd be interesting to see if it can be practical to improve in regards to that
So... assuming there are bad guys demanding access to your data and you say "oh yes, I've been using this plausible deniability encryption/archive format", chances are that they're going to torture you for about exactly as long as they want until they get the data they want.
Also – assuming you have three layers of equal compressed size in your container, and you provide two passwords, can't your interrogator see that only 2/3 of the container file gets accessed, and has a reason to believe there's more data to be found?
The game theory here is interesting. If they are sure that you have the information (for example, the private key to your bitcoin wallet) then "plausible deniability" isn't really a useful feature. It means you can credibly bluff "The key isn't on this device", but they can just torture you until you reveal which device it is on.
In contrast, the threat model of Rubberhose[0] assumes that the secret police believe that you have an incriminating file on your device, but they aren't sure. That means if you are innocent and disclose all your passwords to them, they won't be satisfied and will have to keep on torturing you forever, hoping that you might give them the information you don't actually have. Therefore they have to convince you that there is some information that you could hand over which would satisfy them, and they mustn't over-estimate what information you have, otherwise they are committing to torturing you forever and there is no advantage to you disclosing even the information you do have.
Exactly this. In True/VeraCrypt, there’s only the possibility of having two keys, the main and hidden one. Just the existence of this feature places everyone using the software in danger (at least people who are potential targets of this type of regime), because if you’re not using the hidden volume, you can’t ever prove it. To be really safe, everyone would need to use both volumes, with the hidden one being empty so it can be proven nothing is in there.
But with something that has an arbitrary number of hidden volumes, you have no way to prove it and they can interrogate you forever.
It's bleakly amusing that you think torturers are worried about some sort of credibility calculus. Where torture is sanctioned or tolerated, people are sometimes tortured for information, sometimes for compliance - but those considerations are often excuses offered to justify the torture to external critics. In many cases, people are tortured purely in order to terrorize others into compliance, or because the torturers are sadists who get off on it.
A lot of HN discussions on this topic are based on the implicit assumption that torture is a rational tactic, if extremely brutal and unpleasant one, because most people will eventually tell torturers what they want to hear in hopes of making it stop, and giving up secrets is a bargaining option. The sad fact is that many torturers are motivated by their enjoyment of others' suffering, so you could give them everything only to have them laugh at your dismay when you figured out they never cared about your secrets in the first place.
In some historical conflicts, this realization ahs been exploited by the underdogs; Algerian guerrillas under French occupation had standing agreements to maintain silence for 24 hours if arrested, but after that they could spill everything freely without fear of moral compromise, thus denying the incumbent powers a credible excuse for carrying out torture. Guerrillas were expected to keep abreast of each others' liberty status and to have an unshared plan to bail out if their network was compromised.
I point this out purely as a tactical maneuver; following the ejection of the French the newly independent Algerian state itself instituted all kinds of unethical and repressive practices.
> It's bleakly amusing that you think torturers are worried about some sort of credibility calculus. Where torture is sanctioned or tolerated, people are sometimes tortured for information, sometimes for compliance - but those considerations are often excuses offered to justify the torture to external critics. In many cases, people are tortured purely in order to terrorize others into compliance, or because the torturers are sadists who get off on it.
They actually are in some ways. I toured a former secret East German prison in Berlin, and they would keep prisoners for a long time, and psychologically torture them until they confessed, and would then send them to "trial" with their confession as proof.
I asked the guide why they didn't just physically torture them or falsify the trial right off the bat and he answered something along the lines of the prison guards thinking they were civilized people and wouldn't resort to such barabarous manners.
Torturers are still people and have some level of cognitive dissonance going on, but do require some kind of credibility.
I said interrogation, not torture. There are now at least a few law abiding countries (e.g. UK) where disclosing passwords is mandatory by law as part of an investigation, where interrogation is the process where they demand the suspect reveal such information. With a tool like this, it would be impossible to prove you have revealed every password, and they could hold you in contempt forever.
Don’t assume everyone is making an argument from an extreme position, as reality is rarely ever black and white.
> but those considerations are often excuses offered to justify the torture to external critics. In many cases, people are tortured purely in order to terrorize others into compliance, or because the torturers are sadists who get off on it.
Sure, but in that case you're fucked regardless, so there's not much point worrying about it.
> Therefore they have to convince you that there is some information that you could hand over which would satisfy them, and they mustn't over-estimate what information you have, otherwise they are committing to torturing you forever and there is no advantage to you disclosing even the information you do have.
This is a very useful explanation/articulation of the idea here, thank you.
In countries like the UK where you can be jailed or fined for not giving a password, this provides a way to do that and escape jail. Truecrypt did it and after the developers stopped supporting that, VeraCrypt came along.
You obviously don't reveal that you are using a plausible denial storage method. Give it a zip extension and rename the application that you access with to something like Zip Archiver. "It's an encrypted zip file and the password is ...." How do they know its not zip or that's there's secret data there?
The app literally says "Welcome to FractalCrypt!" when you open it. Not only revealing the encryption format name, but clearly hinting to how it works.
I'd much prefer an encryption format that hides itself in a well-known one layer encryption (like encrypted zip).
I agree, something like VeraCrypt where the partition has a certain size, with or without hidden data.
But state level actors might nevertheless have methods to find out, that you write 120gb of data compressed into a 100gb file, there needs to be something hidden because otherwise you would get in 122gb - something like that.
Or single stepping VeraCrypt machine code execution (you see I have no clue).
For one, it's not clear that this tool creates standard .ZIP files, so the bad guys using an off-the-shelf `unzip` tool would probably suspect things.
If the tool does create regular ZIPs with irregular contents, they could still see that there's noise that isn't read during the course of decryption/extraction, which is suspect.
Partly because these systems are designed to destroy the data if not unlocked. Your "plausible" container, if not unlocked, makes the rest of the container look like free space - i.e. destroyed by an OS not aware it shouldn't write to it.
Which is common with HDD block-device format containers (not sure this thing makes as much sense) anyway: if my laptop here (which is encrypted) gets unlocked with 2 passwords, you would need to independently verify that in fact I normally used 3 and the idea is you can't prove that the "free space" is actually not just normal freespace on my HDD.
Combined with a TPM chip and not having any recovery codes and the HDD can't be realistically extracted except by nation-state level actors with a motivated interest.
Also why would "truly secret" data be large in size to start with? The more likely relationship would be 100:10:1 or greater in terms of "plausible" to "implausible".
An alternative might be to use something like Shamir's Secret Sharing to split the recovery codes between a dozen mutually-unknown friends in different jurisdictions, such that the secrets held by some threshold of them could produce the recovery codes.
These friends would have to be trusted to only hand you their share if they meet you in person in their jurisdiction, and should perhaps also first tweet out that they were doing so, in order to warn anyone whose security might depend on your encrypted data not being compromised.
Well the data is going to get wiped after you unlock without enough passphrases anyway, so it's kind of pointless - you need a backup. The point of not having recovery codes for the TPM is to ensure the disk is completely unusable if the machine is tampered with - i.e. you have to be forced to unlock that machine, and not a copy, to ensure the data is destroyed. I do wonder if TPM's would detect the use of SATA/PCI-E write blockers (or some elaborate shim system - but again, nation-state level).
Of course this is the real fiction: in reality I'm somewhat too lazy to set all that up for the much more likely scenario of a preventable glitch hosing my system.
> you can't prove that the "free space" is actually not just normal freespace on my HDD.
Isn't normal free space supposed o contain at least partially recoverable traces of deleted files usually? I think we need a file system that wipes everything deleted (including file names!) and replaces it with random data by default.
One of the best mitigations against rubber-hose and similar attacks is a hardware key. If you leave it at home, you can't be compelled to decrypt unless an attacker also breaks into your home and searches the place.
In a pinch, you might be able to conveniently "lose" your hardware key, or smash it if you hear the front door break open. Doing so effectively erases your data without actually erasing it, since it's unreadable without the key.
Yeah, TrueCrypt or VeraCrypt are widespread enough right now and most people are just using them in normal, non-deniable form, so it seems like better cover currently.
To expand on your second point, these kinds of systems should let you set the fixed-size of the volume, like 1G or 5G, with the payload being unrelated.
> Whereas, using FractalCrypt you can safely give away the keys to unclassified volumes, and there is no way to prove that there are actually more volumes than you have disclosed.
So the problem is that you're going to use what exactly to decrypt it to prove plausible deniability? FractalCrypt? And then what do the adversaries do once they google FractalCrypt and see the phrase above?
Once your adversaries know you're using FractalCrypt, you've negated any plausible deniability.
Sure, they can keep beating you or keep you locked up, but you know that they will anyway because they'll never be satisfied with the amount you've given them. There could always be more. So there is no point giving up all of them. What that means for your mental state and the likelihood that you will give them all up, I don't know.
On the other hand, if you don't use this, they'll just beat you or keep you locked up until you've given the key to all the volumes they can see.
Which type is better depends on your situation. You can't just say it's pointless because they know what the purpose of this encryption software is.
I do make the claim it's pointless, as well as all other crypto software that claims to provide "plausible deniability" for the reason I stated.
The best mental state you can have is being able to tell all the truth and that still doesn't help an adversary to recover the data. That means keeping your key separate from your gray matter.
There is no way for the attacker to know how many keys you have. So you can give the attacker 2 keys, while you have your actual sensitive data behind the 5th one.
It could still be a challenge to convince the attacker that you really only had n-1 keys, so you may need to include plausibly-sensitive data in earlier layers.
Sure, but there's a significant subset of attackers for whom this isn't an option. For example, I live in the USA. Torturing me because the government thinks there's a 7th key I'm not being up front about isn't an option for them, at least on paper.
> First, it creates a cryptocontainer of a user-specified size, filled with random characters. To create the first volume, the program archives the user-specified files to the beginning of the cryptocontainer and encrypts it using the first key.
This is problematic; key reveal gives important metadata hints as to size and location of other volume(s).
This could be redeemed by encoding offset and size parameters in the key. These could be randomized or fixed at initialization.
Great ambition, I'll be keeping tabs on how this evolves.
1. Create 10 files of encrypted random data. Discard the passwords.
2. Replace a random selection of these files with encrypted fake data, using different passwords for each one.
3. Replace one file with the actual encrypted data.
If challenged, openly share this scheme you used with your opponent. Under durress give up the passwords to the fake data files. Insist that one fake data file is the real data and that the keys to all the other files were discarded.
Get punished anyway because "only bad people have things to hide" would be my guess. It's a shame we even need to have plausible deniability in the first place.
Cant speak for this implementation, but deniable encryption has an additional benefit over just encrypting stuff that even if you are actually targeted they need to get really really deep into your life to even know it exists and where.
Be that your super secret draft annual report or a fat bitcoin wallet, it will pass a casual inspection and they will move onto more interesting targets.
Old but relevant https://defuse.ca/truecrypt-plausible-deniability-useless-by... .Be careful with plausible deniability depending on your threat model as it's only efficient against a soft "lawful" adversary. It's probably a terrible idea against an adversary willing to resort to "enhanced interrogation techniques" (not mentioning the usual 5$ xkcd).
This article is about the problem of using TrueCrypt, which allows you to create a single hidden layer;
In case TrueCrypt usage is detected, the requirement to give out the hidden layer password would be quite reasonable, because then you can be sure that the container is decrypted in its entirety.
In the case of FractalCrypt, only part of the container can be decrypted, even knowing all the passwords; hence, denying the existence of truly secret data can be quite convincing, for example, by first giving out unclassified, and after a long interrogation giving out semisecret ones.
In addition, the article states that
> In other scenarios the feature can be useful. If the attacker has limited resources (i.e. can only torture you for 30 minutes), or if you are "innocent until proven guilty" under the law, then it can be advantageous to use a hidden volume. Just don't recommend TrueCrypt to your friends in North Korea, or at least make sure they use a hidden volume.
In most situations, such as a police raid or criminal robbery, you will not be tortured to death.
However, it is really better not to use FractalCrypt in North Korea.
for use within linux I wouldn't trust anything but luks. speaking of luks, it can theoretically accomplish this with offsets and payload align, but I'm not sure I'd trust it not to fudge up when reaching allocation limits.
I am not an expert in encryption or plausible deniability, but couldn't steganography be used to conceal sensitive information? I realize steganography would be problematic if you need to store large amounts of information, or need to modify the information often, but couldn't it be used for small amounts of information that doesn't change often?
Couldn't you tell an attacker "It's just a picture of my cat."?
I'm not an expert either, but I think you could also use a one time pad to do exactly that.
You have a picture of a cat, and 2 one time pads (OTPs). OTP #1 is the key for your real data, and you can generate OTP #2 such that it decrypts the ciphertext (in this case, an image) into whatever data you pick.
Whether this is practical is a completely different question though.
https://github.com/gzm55/dpad-enc
Here is a poc to encrypt just static pieces of short secrets in to a large enough file, and decrypt only one secret by select a correct password.
This is not secure against multi-snapshot adversaries, like those who can take multiple snapshots of your storage at different times.
The solution is to hide the access pattern, for example by using a write-only oblivious RAM.
I'm currently working on a cloud database that uses searchable encryption. In a database the smallest things can hurt you, both the access and search pattern (must hide the encrypted data that satisfies the query condition or multiple query conditions, the volume of that data, and hide which queries are identical). And the attacker can have auxiliary information (known-data, known-query, inference). On top of that the database must be verifiable (authentical, sound, complete, fresh). Encrypted and non-encrypted data might be searched together (partitioned data security). A database must be resizable, that's the point of a cloud database. And then there is data sharing. And it must be cheap. The existing solutions in the literature either compromise security or practical efficiency.