cryptsetup with Python subprocess + pipes
Hello,
I'm trying to make a plausible deniability encryption wrapper around cryptsetup.
Basically it uses a hash table to first lookup an offset (encrypted with the password), then uses that offset to load a hidden volume within a contiguous file (within which other volumes may or may not exist).
The theory is solid, and everything is mostly working. The only problem I'm having is doing the communication in Python:
# Format the volume
pipe = subprocess.Popen(["cryptsetup", "luksFormat", loop_device],
stdout=subprocess.PIPE, stdin=subprocess.PIPE)
out = pipe.communicate(input=b"YES\n" + password)
if pipe.returncode:
error("Problem formatting volume.")
return pipe.returncode
For some reason, this does not give any output! But the volume gets created, but I cannot decrypt it with the password.
I don't want to save the password to disk, so I cannot use --key-file.
For some reason, this works with other commands, just not cryptsetup. I think it is suppressing output and stopping me doing this. Why?
Any help?
Thanks.
Quoted 21 lines · Police Terror
Hello,
I'm trying to make a plausible deniability encryption wrapper around cryptsetup.
Basically it uses a hash table to first lookup an offset (encrypted with the password), then uses that offset to load a hidden volume within a contiguous file (within which other volumes may or may not exist).
The theory is solid, and everything is mostly working. The only problem I'm having is doing the communication in Python:
# Format the volume
pipe = subprocess.Popen(["cryptsetup", "luksFormat",loop_device],
stdout=subprocess.PIPE, stdin=subprocess.PIPE)
out =pipe.communicate(input=b"YES\n" + password)
if pipe.returncode:
error("Problem formatting volume.")
return pipe.returncode
Quoted 2 lines
For some reason, this does not give any output! But the volume gets created, but I cannot decrypt it with the password.
Probably because if you use pipe, cryptsetup will switch to batch mode where there is no question and no output.
It is better to add batch mode (-q switch) explicitly and remove from "YES\n" from your script (otherwise it becomes password ;-).
There is also simple Python pycryptsetup wrapper (it doesn't cover all commands though).
Milan
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.
Milan Broz:
Quoted 40 lines · Police Terror
Quoted 21 lines
Hello,
I'm trying to make a plausible deniability encryption wrapper around cryptsetup.
Basically it uses a hash table to first lookup an offset (encrypted with the password), then uses that offset to load a hidden volume within a contiguous file (within which other volumes may or may not exist).
The theory is solid, and everything is mostly working. The only problem I'm having is doing the communication in Python:
# Format the volume
pipe = subprocess.Popen(["cryptsetup", "luksFormat",loop_device],
stdout=subprocess.PIPE, stdin=subprocess.PIPE)
out =pipe.communicate(input=b"YES\n" + password)
if pipe.returncode:
error("Problem formatting volume.")
return pipe.returncodeQuoted 2 lines
For some reason, this does not give any output! But the volume gets created, but I cannot decrypt it with the password.
Probably because if you use pipe, cryptsetup will switch to batch mode where there is no question and no output.
It is better to add batch mode (-q switch) explicitly and remove from "YES\n" from your script (otherwise it becomes password ;-).
There is also simple Python pycryptsetup wrapper (it doesn't cover all commands though).
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 7 lines · Police Terror
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
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:
Quoted 20 lines · Police Terror
Quoted 7 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
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
Quoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
You obviously did not look at the example because the data is not hidden steganographically.
The way it works is that you have a slab with multiple possible volumes at various offsets. To decrypt a volume, you need to know the offset and the password. An attacker cannot delete the volume because he does not know the offset.
These offsets are stored in a hashmap array. The password is hashed using scrypt, then the array is indexed. The value at that index is then decrypted using the password to get the offset.
So all the user needs is a password. With that, the software can find the index, use the password to get the volume's index within the slab and then decrypt it.
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.
Arno Wagner:
Quoted 64 lines
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,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 2 lines · Police Terror
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.
[...]
Quoted 3 lines
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
Quoted 69 lines
Arno Wagner:
Quoted 22 lines
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.
Quoted 42 lines
Regards,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
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
Quoted 112 lines · Arno Wagner
Quoted 2 lines · Police Terror
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.
[...]
Quoted 3 lines
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,
ArnoQuoted 69 lines
Arno Wagner:
Quoted 22 lines
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.
Quoted 42 lines
Regards,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-cryptSignature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
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:
Quoted 127 lines
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,
ArnoQuoted 112 lines · Arno Wagner
Quoted 2 lines · Police Terror
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.
[...]
Quoted 3 lines
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,
ArnoQuoted 69 lines
Arno Wagner:
Quoted 22 lines
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.
Quoted 42 lines
Regards,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-cryptSignature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt
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
Quoted 145 lines · Police Terror
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:
Quoted 7 lines
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).
Quoted 120 lines
I have updated FAQ Item 5.18 to hopefully make that clearer.
Regards,
ArnoQuoted 112 lines · Arno Wagner
Quoted 2 lines · Police Terror
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.
[...]
Quoted 3 lines
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,
ArnoQuoted 69 lines
Arno Wagner:
Quoted 22 lines
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.
Quoted 42 lines
Regards,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-cryptSignature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
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:
Quoted 161 lines
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,
ArnoQuoted 145 lines · Police Terror
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:
Quoted 7 lines
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).
Quoted 120 lines
I have updated FAQ Item 5.18 to hopefully make that clearer.
Regards,
ArnoQuoted 112 lines · Arno Wagner
Quoted 2 lines · Police Terror
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.
[...]
Quoted 3 lines
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,
ArnoQuoted 69 lines
Arno Wagner:
Quoted 22 lines
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.
Quoted 42 lines
Regards,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-cryptSignature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Well, if you read that right, then you have found a big fat loophole in the UK legislation. It will be no doubt be closed if anybody ever uses it successfully.
However, I see it only talking about "protected information", not about how and where it is stored. So my reading would be that they can demand the passphrase for "that storage system" (or the like), and all you can claim is that your "storage system" (which comprises all parts including decoys) does not contain data. Then you need to hope a judge believes you, because rather obviously nobody would normally go to that effort and then store nothing in it.
You could of course still put several containers in there and only give them one and claim the others are decoys. Again, you need a judge to believe you or you are screwed.
Here is an even simpler system that makes the problem blatantly obvious: Put a large file with random data on disk. Claim it is random input used as driver of a simulation and put in a file to be able to repeat the simulation. (In reality, it is a loop-mounted dm-crypt device.) If I were to do that, I could even point to academic papers of which I an the author that deal with simulations.
Yet if "they" suspect something, do you really think this scheme would work? They would just say that obviously this is a file holding "protected information" and obviously I am lying to them. If there already is some suspicion, they have a good chance to convince a judge, and even if that is only "he acted funny". People have been shot by the police even in the UK on grounds not any more solid.
Regards,
Arno
Quoted 188 lines · Police Terror
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:
Quoted 7 lines
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.)
Quoted 154 lines
Also remember that the key point in "plausible deniability" is "plausible" and not "deniability". Deniability is easy. Plausible deniability is not.
Regards,
ArnoQuoted 145 lines · Police Terror
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:
Quoted 7 lines
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).
Quoted 120 lines
I have updated FAQ Item 5.18 to hopefully make that clearer.
Regards,
ArnoQuoted 112 lines · Arno Wagner
Quoted 2 lines · Police Terror
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.
[...]
Quoted 3 lines
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,
ArnoQuoted 69 lines
Arno Wagner:
Quoted 22 lines
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.
Quoted 42 lines
Regards,
ArnoQuoted 37 lines · Police Terror
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:
Quoted 12 lines · Police Terror
Quoted 7 lines
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.Quoted 8 lines
(It was designed for Anaconda installer mainly.)
Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-cryptSignature · 11 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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 [email protected] http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Re: [dm-crypt] cryptsetup with Python subprocess + pipes (saout: to exclusive)
In reply to Police TerrorQuoted 6 lines · On 06/23/2016 02:37 PM, Police Terror - [email protected] wrote:
Hello,
I'm trying to make a plausible deniability encryption wrapper around cryptsetup.
[...]
Not what you're asking, but for this purpose, have you had a look at dmsteg? http://dmsteg.sourceforge.net/
/D
Re: [dm-crypt] cryptsetup with Python subprocess + pipes (saout: to exclusive)
dmsteg would be great but last updates are 2012 and my solution is way simpler building off existing crypto primitives.
Diagon:
Quoted 18 lines · On 06/23/2016 02:37 PM, Police Terror - [email protected] wrote:
Quoted 6 lines
Hello,
I'm trying to make a plausible deniability encryption wrapper around cryptsetup.
[...]
Not what you're asking, but for this purpose, have you had a look at dmsteg? http://dmsteg.sourceforge.net/
/D
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt