7 ms·

Show HN: FractalCrypt 2.0 – free deniable encryption cryptoarchiver

128 points by zorggish 5y ago

akx 5y ago
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?
- sildur 5y ago
  That format really needs widespread adoption. Using it is suspicious by itself right now.
  - arsome 5y ago
    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.
- davidhbolton 5y ago
  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?
  - akx 5y ago
    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.
  - flixic 5y ago
    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).
    - KingOfCoders 5y ago
      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).
- moritonal 5y ago
  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.
- XorNot 5y ago
  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".
  - dane-pgp 5y ago
    > and not having any recovery codes 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.
    - XorNot 5y ago
      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.
  - 5y ago
- dane-pgp 5y ago
  > until they get the data they want. 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 https://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
  - orev 5y ago
    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.
    - anigbrowl 5y ago
      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.
- Seirdy 5y ago
  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.
ComodoHacker 5y ago
Not a word about security analysis, threat model, etc. That's not how a security tool your life could depend on is presented these days. Also, is it a coincidence that the "Made with C++" badge is colored red?
DarkmSparks 5y ago
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.
tifadg1 5y ago
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.
cdumler 5y ago
> 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.
- deleted 5y ago
  [deleted]
- 3np 5y ago
  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.
  - malf 5y ago
    If there’s wear leveling, there’s metadata. If not, there’s, like, wear.
    - 3np 5y ago
      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
- derefr 5y ago
  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.
3np 5y ago
> 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.
hartator 5y ago
Can’t the attacker just see that FractalCrypt is installed, read the same Readme, and ask for the 2nd key?
- matharmin 5y ago
  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.
  - hartator 5y ago
    Hum, it the attacker knows that he wants the key for a specific secret, like a Bitcoin wallet, can he just torture you until he gets it?
    - istjohn 5y ago
      Well, yeah. There's no system that will defeat rubber hose exploits.
    - p_j_w 5y ago
      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.
    - j_walter 5y ago
      Have a different and much smaller bitcoin wallet that serves as a decoy...and have the keys in the 1st layer of encryption.
inetsee 5y ago
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."?
- shpongled 5y ago
  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.
- gzm55 5y ago
  https://github.com/gzm55/dpad-enc 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.
istjohn 5y ago
Here's a quick and dirty DIY system: 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.
- tsujp 5y ago
  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.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
Comevius 5y ago
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.
- temptemptemp111 5y ago
  Can you share more about this project? Thoughts on management engined access to registers and DMA being a weakness?
  - Comevius 5y ago
    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. https://www.inkandswitch.com/local-first.html 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.
FpUser 5y ago
Unless the functionality is supported in common software like zip the mere fact of one using it can be a clue.
m3kw9 5y ago
Can it be detected that you are using fractalcrypt archive type?
bb88 5y ago
> 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.
- lucb1e 5y ago
  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.
  - bb88 5y ago
    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.
- chrisbuc 5y ago
  Inevitable XKCD: https://xkcd.com/538/ https://xkcd.com/538/
anonypla 5y ago
Old but relevant https://defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm 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).
- zorggish 5y ago
  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.
CodeWriter23 5y ago
I dunno, kinda sounds like asking for repetitions of torture IMO.
willbank 5y ago
Interesting but as many commentators point out there are major challenges to plausible deniability when under duress. Wouldn’t multisig be preferable? “Umm, look you’re going to need to go torture my brother 80 miles away at the same time…”

128 points by zorggish 5y ago

akx 5y ago

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?

sildur 5y ago
That format really needs widespread adoption. Using it is suspicious by itself right now.
- arsome 5y ago
  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.
davidhbolton 5y ago
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?
- akx 5y ago
  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.
- flixic 5y ago
  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).
  - KingOfCoders 5y ago
    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).
moritonal 5y ago
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.
XorNot 5y ago
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".
- dane-pgp 5y ago
  > and not having any recovery codes 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.
  - XorNot 5y ago
    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.
- 5y ago
dane-pgp 5y ago
> until they get the data they want. 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 https://en.wikipedia.org/wiki/Rubberhose_%28file_system%29
- orev 5y ago
  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.
  - anigbrowl 5y ago
    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.
Seirdy 5y ago
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.

ComodoHacker 5y ago

Not a word about security analysis, threat model, etc. That's not how a security tool your life could depend on is presented these days. Also, is it a coincidence that the "Made with C++" badge is colored red?

DarkmSparks 5y ago

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.

tifadg1 5y ago

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.

cdumler 5y ago

> 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.

deleted 5y ago
[deleted]
3np 5y ago
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.
- malf 5y ago
  If there’s wear leveling, there’s metadata. If not, there’s, like, wear.
  - 3np 5y ago
    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
derefr 5y ago
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.

3np 5y ago

> 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.

hartator 5y ago

Can’t the attacker just see that FractalCrypt is installed, read the same Readme, and ask for the 2nd key?

matharmin 5y ago
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.
- hartator 5y ago
  Hum, it the attacker knows that he wants the key for a specific secret, like a Bitcoin wallet, can he just torture you until he gets it?
  - istjohn 5y ago
    Well, yeah. There's no system that will defeat rubber hose exploits.
  - p_j_w 5y ago
    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.
  - j_walter 5y ago
    Have a different and much smaller bitcoin wallet that serves as a decoy...and have the keys in the 1st layer of encryption.

inetsee 5y ago

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."?

shpongled 5y ago
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.
gzm55 5y ago
https://github.com/gzm55/dpad-enc 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.

istjohn 5y ago

Here's a quick and dirty DIY system: 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.

tsujp 5y ago
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.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

Comevius 5y ago

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.

temptemptemp111 5y ago
Can you share more about this project? Thoughts on management engined access to registers and DMA being a weakness?
- Comevius 5y ago
  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. https://www.inkandswitch.com/local-first.html 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.

FpUser 5y ago

Unless the functionality is supported in common software like zip the mere fact of one using it can be a clue.

m3kw9 5y ago

Can it be detected that you are using fractalcrypt archive type?

bb88 5y ago

> 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.

lucb1e 5y ago
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.
- bb88 5y ago
  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.
chrisbuc 5y ago
Inevitable XKCD: https://xkcd.com/538/ https://xkcd.com/538/

anonypla 5y ago

Old but relevant https://defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm 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).

zorggish 5y ago
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.

CodeWriter23 5y ago

I dunno, kinda sounds like asking for repetitions of torture IMO.

willbank 5y ago

Interesting but as many commentators point out there are major challenges to plausible deniability when under duress. Wouldn’t multisig be preferable? “Umm, look you’re going to need to go torture my brother 80 miles away at the same time…”