From: Police Terror <PoliceTerror@dyne.org>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] cryptsetup with Python subprocess + pipes
Date: Fri, 24 Jun 2016 16:33:37 +0000 [thread overview]
Message-ID: <576D60E1.7090805@dyne.org> (raw)
In-Reply-To: <20160624152856.GA26849@tansi.org>
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:
> 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@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
next prev parent reply other threads:[~2016-06-24 16:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-23 21:37 [dm-crypt] cryptsetup with Python subprocess + pipes Police Terror
2016-06-24 5:42 ` [dm-crypt] cryptsetup with Python subprocess + pipes (saout: to exclusive) Diagon
2016-06-24 9:58 ` Police Terror
2016-06-24 5:42 ` [dm-crypt] cryptsetup with Python subprocess + pipes Milan Broz
2016-06-24 9:56 ` Police Terror
2016-06-24 10:45 ` Milan Broz
2016-06-24 12:16 ` Police Terror
2016-06-24 15:28 ` Arno Wagner
2016-06-24 16:33 ` Police Terror [this message]
2016-06-24 16:58 ` Arno Wagner
2016-06-29 0:02 ` Arno Wagner
2016-06-29 8:47 ` Police Terror
2016-06-29 9:58 ` Arno Wagner
2016-06-29 11:47 ` Police Terror
2016-06-29 17:28 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576D60E1.7090805@dyne.org \
--to=policeterror@dyne.org \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox