Under UK law there is no difference. The police need reasonable suspicion to be able to compel you to give up a crypto key. If you have several volumes that are randomly used depending on the passphrase you give, then there is nothing to give them reasonable doubt you are using one over the other. This is covered by Regulation of Investigatory Powers Act 2000, section 49. 1. Whereas with VeraCrypt style volumes (which can contain 1 hidden volume), the scheme I presented is better because under UK law, a police officer could suspect another hidden volume based on circumstantial evidence. But the scheme with 10 volumes, leaves no link or indication that they are used as storage. For a UK officer to compel you to decrypt something, they must be able to say which volume they suspect you have access to. Also because the volumes are looked up based on passphrases (to index the hash map array), then it makes rainbow attacks more difficult. This is a common case in UK law where they compel a person who previously knew the password but cannot remember it in full. The suspect gives the police instructions on how they can regenerate the password. With this scheme it will be expensive to run these kinds of attacks unless it was a pure brute force. Arno Wagner: > If you want that, just use plain dm-crypt. It does not have > a header. Just remember that you have no plausibility for > the denial that they have data (because the assumption that > volumes contain data is entirely plausible), hence you need to > hide the volumes effectively. If the attacker finds these, > you are screwed. (As explained in FAQ 5.18.) > > Also remember that the key point in "plausible deniability" > is "plausible" and not "deniability". Deniability is easy. > Plausible deniability is not. > > Regards, > Arno > > On Wed, Jun 29, 2016 at 10:47:15 CEST, Police Terror wrote: >> In this case we have 10 volumes which are created upon initialization, >> and the key is discarded. >> >> The attacker does not know if anything exists in any of those 10 >> volumes, and he cannot prove it either. >> >> Your password is hashed and indexed to look up a row in a hashmap array, >> and then that row is decrypted to get the offset for the volume to >> decrypt. Then using your password, you can decrypt that volume. >> >> Otherwise there's no other data. If LUKS didn't have headers, it would >> be even more deniable because the crypto would just look like random data. >> >> Arno Wagner: >>> I think I may have found what confuses all these people. They >>> may actually be thinking about simple deniability (just >>> hiding data) instead of plausible deniability (where the >>> attacker knows something may be in those "random" bytes >>> but cannot prove it and in particular it is "plausible" >>> that no data is in there). >>> >>> I have updated FAQ Item 5.18 to hopefully make that clearer. >>> >>> Regards, >>> Arno >>> >>> >>> On Fri, Jun 24, 2016 at 18:58:16 CEST, Arno Wagner wrote: >>>> On Fri, Jun 24, 2016 at 18:33:37 CEST, Police Terror wrote: >>>>> You obviously did not look at the example because the data is not hidden >>>>> steganographically. >>>> >>>> You obviously did not understand what I wrote, because >>>> I never claimed that in this case it was. I only claimed that >>>> at this time this is the only valid known way to do plausible >>>> deniablility. >>>> >>>> [...] >>>> >>>>> About a well engineered solution: today I just found VeraCrypt which >>>>> actually works well. I encourage people to try it. It can create hidden >>>>> volumes. >>>> >>>> ... and that have all the problems hidden volumes come with. >>>> They also managed to create additional problems TrueCrypt does >>>> not have, for example a broken password "quality" assessment >>>> that cannot be bypassed (alternatively you get a broken >>>> password iteration, that can lead to minutes of unlock time). >>>> My trust in the VeraCrypt developers is much, much lower than >>>> in the original TrueCrypt developers. >>>> >>>> Seriously. Bright-eyed "can do" attitudes have no place in >>>> IT security. They do much more harm than good and they endanger >>>> users. >>>> >>>> Regards, >>>> Arno >>>> >>>>> Arno Wagner: >>>>>> What I would like to see is a plausible deniability technique >>>>>> that is not just a worthless tech-demo, but where the >>>>>> "plausible" part was actually well engineered with regards >>>>>> to how things work in the real world and that is not limited >>>>>> to a very small amount of steganographically hidden data. >>>>>> So far, none exists. >>>>>> >>>>>> The thing is, for an incompetent attacker it is already >>>>>> enough to just remove a partition from the partition table >>>>>> and re-create it at need in the same place. For a competent >>>>>> attacker, the things that exist today just provide probable >>>>>> cause that you are trying to hide something and hence make >>>>>> things worse. >>>>>> >>>>>> As it is, these tools are of negative worth, as they give >>>>>> users a false sense of security. >>>>>> >>>>>> Also refer to FAQ 5.18 for my analysis of the status-quo. >>>>>> The paper by Schneier et. al. I reference provides an >>>>>> excellent in-depth analysis of the problems with the idea >>>>>> of plausible deniability in a real OS environment. >>>>>> >>>>>> Regards, >>>>>> Arno >>>>>> >>>>>> On Fri, Jun 24, 2016 at 14:16:05 CEST, Police Terror wrote: >>>>>>> Here's the tool: >>>>>>> >>>>>>> https://github.com/RojavaCrypto/hiddencrypt >>>>>>> >>>>>>> Mostly proof of concept for now. >>>>>>> >>>>>>> Would be cool in the future to work something better out by hacking >>>>>>> cryptsetup itself. Maybe if there's headerless volumes (that just look >>>>>>> like random data). >>>>>>> >>>>>>> Multiple deniable Linux installs would be a killer feature. >>>>>>> >>>>>>> Milan Broz: >>>>>>>> On 06/24/2016 11:56 AM, Police Terror wrote: >>>>>>>>> Ahhh yes! Thank you Diagon and Milan. >>>>>>>>> I've added now the -q switch. >>>>>>>>> >>>>>>>>> I looked at the pycryptsetup but 2 things: >>>>>>>>> >>>>>>>>> 1. It's not Python 3 >>>>>>>>> 2. It's an extra dependency and not in the repos. >>>>>>>> >>>>>>>> Fedora has both Python3 and 2 builds but other >>>>>>>> distros do not compile it probably. >>>>>>>> >>>>>>>> (It was designed for Anaconda installer mainly.) >>>>>>>> >>>>>>>> Milan >>>>>>>> _______________________________________________ >>>>>>>> dm-crypt mailing list >>>>>>>> dm-crypt@xxxxxxxx >>>>>>>> http://www.saout.de/mailman/listinfo/dm-crypt >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> dm-crypt mailing list >>>>>>> dm-crypt@xxxxxxxx >>>>>>> http://www.saout.de/mailman/listinfo/dm-crypt >>>>>> >>>>> _______________________________________________ >>>>> dm-crypt mailing list >>>>> dm-crypt@xxxxxxxx >>>>> http://www.saout.de/mailman/listinfo/dm-crypt >>>> >>>> -- >>>> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx >>>> GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 >>>> ---- >>>> A good decision is based on knowledge and not on numbers. -- Plato >>>> >>>> If it's in the news, don't worry about it. The very definition of >>>> "news" is "something that hardly ever happens." -- Bruce Schneier >>>> _______________________________________________ >>>> dm-crypt mailing list >>>> dm-crypt@xxxxxxxx >>>> http://www.saout.de/mailman/listinfo/dm-crypt >>> >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
