Show HN: FractalCrypt 2.0 – free deniable encryption cryptoarchiver
github.com
github.com
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.
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.
https://www.inkandswitch.com/local-first.html
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 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.
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
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.
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.
Some log-oriented file systems may provide insight into changes made. From what I know, ZFS is one example of such file system and btrfs is another.
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.
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?
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?
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.
I'd much prefer an encryption format that hides itself in a well-known one layer encryption (like encrypted zip).
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).
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.
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.
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.
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.
[0] https://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
But with something that has an arbitrary number of hidden volumes, you have no way to prove it and they can interrogate you forever.
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.
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.
Sure, but in that case you're fucked regardless, so there's not much point worrying about it.
Don’t assume everyone is making an argument from an extreme position, as reality is rarely ever black and white.
This is a very useful explanation/articulation of the idea here, thank you.
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.
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.
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.
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.
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.
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.
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.
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.
Wouldn’t multisig be preferable? “Umm, look you’re going to need to go torture my brother 80 miles away at the same time…”
Couldn't you tell an attacker "It's just a picture of my cat."?
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.
Also, is it a coincidence that the "Made with C++" badge is colored red?