[dm-crypt] Passphrase protected key file?

[dm-crypt] Passphrase protected key file?

[Laurence Darby]

Hello,

My next question, what's the best way to have a passphrase protected key file?
Should I encrypt it with GPG, and then do eg:

 gpg -d ~/pass_key  | cryptsetup luksOpen --key-file - /dev/loop1 loop1

That has the advantage of using the same passphrase I use for
everything else, but is there any security risk I'm not seeing?  I read
that encrypting something twice or with multiple ciphers is effectively
a new unknown cipher, potentially trivially breakable - I don't think
that applies here, but is there anything like that I need to watch out for?

Alternatively, I could just do this:

( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file - /dev/loop1 loop1

so I still have to provide both the key and passphrase, terminated with
Ctrl-D.  Any thoughts?

Thanks,
Laurence

Re: [dm-crypt] Passphrase protected key file?

[Jorge Fábregas]

On 07/11/2011 06:17 PM, Laurence Darby wrote:
>  gpg -d ~/pass_key  | cryptsetup luksOpen --key-file - /dev/loop1 loop1

I don't see the point of this.  If you need to enter a passphrase for
GPG to decrypt your stored key...why not simply use a passphrase
(instead of a key file) for cryptsetup?  In both cases you would be
entering a passphrase (so the manual work is the same).  Also,  if you
use just a passphrase for cryptsetup I see an advantage there:  there's
no hash or "encrypted version" of my passphrase stored _anywhere_ on the
system.

Regards,
Jorge

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Mon, Jul 11, 2011 at 11:17:32PM +0100, Laurence Darby wrote:
> Hello,
> 
> My next question, what's the best way to have a passphrase 
> protected key file?

Whyever woyld you want one? If you already have a passphrase,
use that directly. The passphrase-in-file option is 
for slaved devices and keys stored in hardware with some
additional protection by the hardware, e.g. keys on a chipcard.
Key storage on the device itself is actually a pretty much
unsolved problem. The onluy way to do it with a reasonable
level of security today is with costly HSMs (hardware
security modules) that have things like their own power,
extensive sensors, armoured consruction ans the like.
Expect to pay >= 50'000 EUR/USD for one that offers 
reasonable security.

> Should I encrypt it with GPG, and then do eg:
> 
>  gpg -d ~/pass_key  | cryptsetup luksOpen --key-file - /dev/loop1 loop1
> 
> That has the advantage of using the same passphrase I use for
> everything else, but is there any security risk I'm not seeing?  

Yes, you should not reuse passphrases. If you do, of it is exposed
in one place, everything else is exposed. That said, I do 
realize having a good passphrase and using it _carefully_ in
several places is better than having several bad passphrases.
Just make sure you always think about who could evasdrop before
you enter it. For example, never use your passphrase on a
computer not under your control. If you need to do that
(e.e. external storage device), use a dedicated one that
you use nowhere else.

> I read
> that encrypting something twice or with multiple ciphers is effectively
> a new unknown cipher, potentially trivially breakable - I don't think
> that applies here, but is there anything like that I need to watch out for?

If you have _independent_ keys, it usually is as strong as the 
stronger cipher/key combination. With dependent or the same keys, 
this warning is correct. Example: Using a stream cipher twice with
the same key gives you the plaintext as encryption result.
 
> Alternatively, I could just do this:
> 
> ( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file - /dev/loop1 loop1
> 
> so I still have to provide both the key and passphrase, terminated with
> Ctrl-D.  Any thoughts?

Yes, why do you not use the passphrase entry function of cryptsetup
directly? Without a specific and credible risk, there is no
reason to do anything of what you describe here...

I would suggest you read up a bit more on cryptography. 
"Cryptography Engineering" by Schneier et al. is a good book for
example, to get a good understanding of cryto technology
and risks.

You are at the moment in this dangerous "half-knowledge" state, 
were you see some risks and overamplify them, while you completely 
miss others. It is normal to go through this stage, but make sure 
you leave it behind. 

Cryptography is risk management support technology. It is not 
something that needs to be done perfectly, only appropriately 
for the risks identified. The risks are sometimes pretty 
surprising though.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Passphrase protected key file?

[Ma Begaj]

2011/7/12 Arno Wagner <arno@wagner.name>:
> On Mon, Jul 11, 2011 at 11:17:32PM +0100, Laurence Darby wrote:
>> Hello,
>>
>> My next question, what's the best way to have a passphrase
>> protected key file?
>
> Whyever woyld you want one? If you already have a passphrase,
> use that directly. The passphrase-in-file option is
> for slaved devices and keys stored in hardware with some
> additional protection by the hardware, e.g. keys on a chipcard.
> Key storage on the device itself is actually a pretty much
> unsolved problem. The onluy way to do it with a reasonable
> level of security today is with costly HSMs (hardware
> security modules) that have things like their own power,
> extensive sensors, armoured consruction ans the like.
> Expect to pay >= 50'000 EUR/USD for one that offers
> reasonable security.
>
>> Should I encrypt it with GPG, and then do eg:
>>
>>  gpg -d ~/pass_key  | cryptsetup luksOpen --key-file - /dev/loop1 loop1
>>
>> That has the advantage of using the same passphrase I use for
>> everything else, but is there any security risk I'm not seeing?
>
> Yes, you should not reuse passphrases. If you do, of it is exposed
> in one place, everything else is exposed. That said, I do
> realize having a good passphrase and using it _carefully_ in
> several places is better than having several bad passphrases.
> Just make sure you always think about who could evasdrop before
> you enter it. For example, never use your passphrase on a
> computer not under your control. If you need to do that
> (e.e. external storage device), use a dedicated one that
> you use nowhere else.
>
>> I read
>> that encrypting something twice or with multiple ciphers is effectively
>> a new unknown cipher, potentially trivially breakable - I don't think
>> that applies here, but is there anything like that I need to watch out for?
>
> If you have _independent_ keys, it usually is as strong as the
> stronger cipher/key combination. With dependent or the same keys,
> this warning is correct. Example: Using a stream cipher twice with
> the same key gives you the plaintext as encryption result.
>
>> Alternatively, I could just do this:
>>
>> ( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file - /dev/loop1 loop1
>>
>> so I still have to provide both the key and passphrase, terminated with
>> Ctrl-D.  Any thoughts?
>
> Yes, why do you not use the passphrase entry function of cryptsetup
> directly? Without a specific and credible risk, there is no
> reason to do anything of what you describe here...


everything you say is absolutely logical but having a key in an encrypted
file creates under some conditions a more secure environment. you could
keep a file on an usb stick:

a person will need usb stick AND password for decrypting a luks device

and

loosing usb stick is not security problem

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Thu, Jul 14, 2011 at 11:10:09AM +0200, Ma Begaj wrote:
> 2011/7/12 Arno Wagner <arno@wagner.name>:
> > On Mon, Jul 11, 2011 at 11:17:32PM +0100, Laurence Darby wrote:
> >> Hello,
> >>
> >> My next question, what's the best way to have a passphrase
> >> protected key file?
> >
> > Whyever woyld you want one? If you already have a passphrase,
> > use that directly. The passphrase-in-file option is
> > for slaved devices and keys stored in hardware with some
> > additional protection by the hardware, e.g. keys on a chipcard.
> > Key storage on the device itself is actually a pretty much
> > unsolved problem. The onluy way to do it with a reasonable
> > level of security today is with costly HSMs (hardware
> > security modules) that have things like their own power,
> > extensive sensors, armoured consruction ans the like.
> > Expect to pay >= 50'000 EUR/USD for one that offers
> > reasonable security.
> >
> >> Should I encrypt it with GPG, and then do eg:
> >>
> >> ?gpg -d ~/pass_key ?| cryptsetup luksOpen --key-file - /dev/loop1 loop1
> >>
> >> That has the advantage of using the same passphrase I use for
> >> everything else, but is there any security risk I'm not seeing?
> >
> > Yes, you should not reuse passphrases. If you do, of it is exposed
> > in one place, everything else is exposed. That said, I do
> > realize having a good passphrase and using it _carefully_ in
> > several places is better than having several bad passphrases.
> > Just make sure you always think about who could evasdrop before
> > you enter it. For example, never use your passphrase on a
> > computer not under your control. If you need to do that
> > (e.e. external storage device), use a dedicated one that
> > you use nowhere else.
> >
> >> I read
> >> that encrypting something twice or with multiple ciphers is effectively
> >> a new unknown cipher, potentially trivially breakable - I don't think
> >> that applies here, but is there anything like that I need to watch out for?
> >
> > If you have _independent_ keys, it usually is as strong as the
> > stronger cipher/key combination. With dependent or the same keys,
> > this warning is correct. Example: Using a stream cipher twice with
> > the same key gives you the plaintext as encryption result.
> >
> >> Alternatively, I could just do this:
> >>
> >> ( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file - /dev/loop1 loop1
> >>
> >> so I still have to provide both the key and passphrase, terminated with
> >> Ctrl-D. ?Any thoughts?
> >
> > Yes, why do you not use the passphrase entry function of cryptsetup
> > directly? Without a specific and credible risk, there is no
> > reason to do anything of what you describe here...
> 
> 
> everything you say is absolutely logical but having a key in an encrypted
> file creates under some conditions a more secure environment. you could
> keep a file on an usb stick:
> 
> a person will need usb stick AND password for decrypting a luks device

Yes. But since that USB stick does have to be connected to the
same device as the encrypted storage, that does not make it 2-factor.
Also note that an attacker that has access to the storage could
patch your GnuPG binary or other system components.

> and
> 
> loosing usb stick is not security problem

Indeed. But in the ordinary scenario it is not either,
as there is no USB stick.

My take is that you do not get higher security in most 
real scenarios.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Passphrase protected key file?

[Ma Begaj]

> Also note that an attacker that has access to the storage could
> patch your GnuPG binary or other system components.

well that is an another story because an attacker could in that case patch
cryptsetup too. if s/he can do that it is not important whether you
use encrypted
key file on usb stick or directly cryptsetup.

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Thu, Jul 14, 2011 at 01:55:50PM +0200, Ma Begaj wrote:
> > Also note that an attacker that has access to the storage could
> > patch your GnuPG binary or other system components.
> 
> well that is an another story because an attacker could in that case patch
> cryptsetup too. if s/he can do that it is not important whether you
> use encrypted
> key file on usb stick or directly cryptsetup.

Indeed. But are there any realistic scenarios where 

a) a passphrase is signifiacntly less secure than an encrypted 
   passphrase stored on USB with a second pasphrase to decrypt that

and

b) the attacker does not have the possibility to patch
   GnuPG/cryptup/other things that make the second passphrase
   just as weak as the first one?

My claim is that a realistic risk analysis will show there
are no such scenarios that are typical and hence having 
an encrypted passphrase on an USB stick does not offer
improved security.

Remember, IT security is pure risk managements, possibly
with IT means.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Passphrase protected key file?

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/14/2011 03:35 PM, Arno Wagner wrote:
> On Thu, Jul 14, 2011 at 01:55:50PM +0200, Ma Begaj wrote:
>>> Also note that an attacker that has access to the storage could 
>>> patch your GnuPG binary or other system components.
>> 
>> well that is an another story because an attacker could in that
>> case patch cryptsetup too. if s/he can do that it is not important
>> whether you use encrypted key file on usb stick or directly
>> cryptsetup.
> 
> Indeed. But are there any realistic scenarios where
> 
> a) a passphrase is signifiacntly less secure than an encrypted 
> passphrase stored on USB with a second pasphrase to decrypt that
> 
> and
> 
> b) the attacker does not have the possibility to patch 
> GnuPG/cryptup/other things that make the second passphrase just as
> weak as the first one?
> 
> My claim is that a realistic risk analysis will show there are no
> such scenarios that are typical and hence having an encrypted
> passphrase on an USB stick does not offer improved security.

Improved security over which other setup?

a) Unencrypted passphrase stored on a USB key. Here the second
encryption step will probably give additional security in case the user
looses the USB key.

b) Directly entering passphrase without the need of a USB key. Here we
have a typical risk of users using the same passphrase for different
things or even of writing it down (on a post-it note on the screen or
keyboard...). If we depend upon a USB stick with the real passphrase
(encrypted by the one on the post-it note) being present at boot the
attacker won't be able to utilize that passphrase.

If we move kernel+initrd+cryptsetup to the USB stick and boot the
machine from USB, we can even encrypt the entire harddisk, thus even
someone with physical access to the machine cannot patch cryptsetup/gnupg.

Now it only boils down to whether a user writing down his passphrase
will remember to remove the USB key ;)

Regards, Heiko

P.S: Thinking of law enforcement as the attacker (guess that is not that
a great risk for most of us), it is possible to destroy all access to
your data by destroying all the USB keys with the encrypted passphrase
on them - and then you can even tell them your passphrase...
- -- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4e+V0ACgkQ/Vb5NagElAW5aQCfVU4p9/H64K+AQjgl33qSJjQJ
4BEAnRQ9tRptBRHM8JDdFOigyHjPH58N
=utnI
-----END PGP SIGNATURE-----

[dm-crypt] Status of trim for SSds?

[André Gall]

Hello,

I'd like to know the current status about the compatibility of TRIM
(http://en.wikipedia.org/wiki/TRIM) for SSDs and dm-crypt. It is my
understanding, that the current version of dm-crypt does not support
trim operations and therefore SSDs that are encrypted with dm-crypt are
not able to work as efficiently and fast as they would with working trim.

One argument that is often heard in discussions about encryption and
trim, is that trim enables an attacker to tell used blocks from empty
blocks and that this might make an attack easier. However, I have never
heard of a case, where the knowlege about the used blocks lead to a
successfull attack of state-of-the-art crypto-algorithms and
implementations. Of course the attacker might be able to make some
guesses or assumptions about the content of the encrypted storage-device
by analysing the distribution of used blocks, but in most scenarios this
isn't an issue.

Is the support of TRIM a feature that's planned for the future? If so,
when? If not, why not?

André

Re: [dm-crypt] Status of trim for SSds?

[Milan Broz]

On 07/14/2011 04:46 PM, André Gall wrote:

> Is the support of TRIM a feature that's planned for the future? If so,
> when? If not, why not?

Patch is in dm-devel list, hopefully in linux-next soon for kernel 3.1.
http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-crypt-optionally-support-discard-requests.patch

Optional cryptsetup support will follow later (currently you have to use dmsetup).

My opinion is that TRIM for encrypted disk is stupid idea, but so many people
requested it... So enjoy shooting yourself in the foot ;-)

Note - it will NEVER be enabled by default.

Milan

Re: [dm-crypt] Status of trim for SSds?

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

On Thu, 2011-07-14 at 17:55 +0200, Milan Broz wrote:
> Note - it will NEVER be enabled by default.
+1

:-)

Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Status of trim for SSds?

[Philipp Wendler]

Hello,

Am 14.07.2011 17:55, schrieb Milan Broz:

> My opinion is that TRIM for encrypted disk is stupid idea,

I would be interested in the reasons for this, as I also have dm-crypt
on an SSD, and wondered whether it is a good idea to enable trim or not
(as soon as its ready).
What could an attacker do with the information which blocks are used and
which are unused?

I always thought that using trim would essentially be the same as not
writing random data to your disk before encrypting it, and this behavior
is actually the default.

Greetings, Philipp

Re: [dm-crypt] Status of trim for SSds?

[Milan Broz]

On 07/14/2011 06:39 PM, Philipp Wendler wrote:
> I always thought that using trim would essentially be the same as not
> writing random data to your disk before encrypting it, and this behavior
> is actually the default.

mkfs will TRIM the whole device, so only data written after are there.
(You can do this later using fstrim command - all fs unused space is discarded.)

So in your case (like device wiped by zeros initially), yes, it is the same,
you can easily distinguish zeroes from random noise.

But if you fill disk by random and someone later run fstrim while
device was mounted, it will uncover various patterns there. This is new problem.

I am almost sure that filesystem type could be detected from ciphertext device
by using non-discarded block pattern analysis. What else depends on situation.

If you have some analysis what is possible to recover, please post it to the list,
it could be very interesting.

Milan

Re: [dm-crypt] Status of trim for SSds?

[Philipp Wendler]

Hi,

Am 14.07.2011 18:52, schrieb Milan Broz:

> But if you fill disk by random and someone later run fstrim while
> device was mounted, it will uncover various patterns there. This is new problem.
> 
> I am almost sure that filesystem type could be detected from ciphertext device
> by using non-discarded block pattern analysis. What else depends on situation.

I agree on that. But then again, just guessing the filesystem would
probably be easier (I guess that most people use ext3/4).
And you could even look at the content of the initrd to see which
filesystem is used for /, for example.

I was thinking that perhaps you can guess some of the metadata of the
filesystem (free-block list etc.), but as far as I known there are no
relevant known-plaintext attacks on AES, so I'd be willing to take that
risk.

> If you have some analysis what is possible to recover, please post it to the list,
> it could be very interesting.

No, unfortunately I have never heard of such an analysis, that's why I
was asking.

Greetings, Philipp

Re: [dm-crypt] Status of trim for SSds?

[Christian Hesse]

Milan Broz <mbroz@redhat.com> on Thu, 14 Jul 2011 17:55:25 +0200:
> On 07/14/2011 04:46 PM, André Gall wrote:
> 
> > Is the support of TRIM a feature that's planned for the future? If
> > so, when? If not, why not?
> 
> Patch is in dm-devel list, hopefully in linux-next soon for kernel
> 3.1.
> http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-crypt-optionally-support-discard-requests.patch
> 
> Optional cryptsetup support will follow later (currently you have to
> use dmsetup).

Ok, I do have a kernel with discard on dm-crypt support now. How do I
set this option allow_discards for my device using dmsetup? dmsetup's
manpage does not tell anything about it.
-- 
Schoene Gruesse
Chris

Re: [dm-crypt] Status of trim for SSds?

[Milan Broz]

On 07/15/2011 03:59 PM, Christian Hesse wrote:
> Ok, I do have a kernel with discard on dm-crypt support now. How do I
> set this option allow_discards for my device using dmsetup? dmsetup's
> manpage does not tell anything about it.

Backup your data, really. Note there could be still bugs.

You have to manually reload table with discard enabled for now,
it is quite complicated and dangerous because you will manipulate with
master key string directly:

1) Activate device using cryptsetup, remember active table for your device,
including key:

# dmsetup table <your_device> --showkeys

table will look like "0 1234 crypt aes-xts-plain64 <key> 0 8:2 8192"
(with different parameters according to your device,
do not forget --showkeys option)

2) Reload table with discard enabled, (add " 1 allow_discards"
to the end of table line)

# dmsetup load <your_device> --"<line above> 1 allow_discards"

3) activate new table

# dmsetup resume <your_device>

(check that dmsetup table again - it should print discard support now)

Alternatively, you can activate table directly (instead of cryptsetup)

# dmsetup create <your_device> --table "<line above> 1 allow_discards")

If you do not understand what are you doing here, please _wait_ until there
is official userspace support.

Any mistake here will cause data corruption or complete data loss!

Milan

Re: [dm-crypt] Status of trim for SSds?

[Christian Hesse]

Milan Broz <mbroz@redhat.com> on Fri, 15 Jul 2011 16:48:01 +0200:
> On 07/15/2011 03:59 PM, Christian Hesse wrote:
> > Ok, I do have a kernel with discard on dm-crypt support now. How do I
> > set this option allow_discards for my device using dmsetup? dmsetup's
> > manpage does not tell anything about it.
> 
> Backup your data, really. Note there could be still bugs.

I do have good backup. Really. ;)

> You have to manually reload table with discard enabled for now,
> it is quite complicated and dangerous because you will manipulate with
> master key string directly:
> 
> 1) Activate device using cryptsetup, remember active table for your device,
> including key:
> 
> # dmsetup table <your_device> --showkeys
> 
> table will look like "0 1234 crypt aes-xts-plain64 <key> 0 8:2 8192"
> (with different parameters according to your device,
> do not forget --showkeys option)
> 
> 2) Reload table with discard enabled, (add " 1 allow_discards"
> to the end of table line)
> 
> # dmsetup load <your_device> --"<line above> 1 allow_discards"
> 
> 3) activate new table
> 
> # dmsetup resume <your_device>
> 
> (check that dmsetup table again - it should print discard support now)
> 
> Alternatively, you can activate table directly (instead of cryptsetup)
> 
> # dmsetup create <your_device> --table "<line above> 1 allow_discards")
> 
> If you do not understand what are you doing here, please _wait_ until there
> is official userspace support.
> 
> Any mistake here will cause data corruption or complete data loss!

If I understand correctly the table reload suspends my device? With the root
partition inside the crypt device I would have to do this in initram disk I
think...
Perhaps I really should wait for support in cryptsetup. :D

However... Thanks a lot for your work and the quick response!
-- 
Schoene Gruesse
Chris

Re: [dm-crypt] Status of trim for SSds?

[Milan Broz]

On 07/18/2011 10:45 AM, Christian Hesse wrote:
> If I understand correctly the table reload suspends my device? With the root
> partition inside the crypt device I would have to do this in initram disk I
> think...

No. "load" will just load table into inactive slot. Following "resume" will implicitly
suspend device and immediately resume with new table (in kernel) so it should be safe.

> Perhaps I really should wait for support in cryptsetup. :D

In devel tree is already "--allow-discard" option for luksOpen/create command.
(But I guess /etc/ctypttab need new option here as well for system devices but
that's must be fixed by initscripts. There will be no cryptsetup command to enable it
on-fly, just for activation commands.)

Milan

Re: [dm-crypt] Status of trim for SSds?

[Christian Hesse]

Milan Broz <mbroz@redhat.com> on Mon, 18 Jul 2011 12:04:18 +0200:
> On 07/18/2011 10:45 AM, Christian Hesse wrote:
> > If I understand correctly the table reload suspends my device? With the
> > root partition inside the crypt device I would have to do this in initram
> > disk I think...
> 
> No. "load" will just load table into inactive slot. Following "resume" will
> implicitly suspend device and immediately resume with new table (in kernel)
> so it should be safe.

Ok, good to know.

> > Perhaps I really should wait for support in cryptsetup. :D
> 
> In devel tree is already "--allow-discard" option for luksOpen/create
> command.

Already compiled. ;)

> (But I guess /etc/ctypttab need new option here as well for system
> devices but that's must be fixed by initscripts. There will be no
> cryptsetup command to enable it on-fly, just for activation commands.)

I do not use crypttab. All I need is a modified hook in my initrd...
-- 
Schoene Gruesse
Chris

Re: [dm-crypt] Status of trim for SSds?

[Christian Hesse]

Christian Hesse <list@eworm.de> on Mon, 18 Jul 2011 12:16:25 +0200:
> Milan Broz <mbroz@redhat.com> on Mon, 18 Jul 2011 12:04:18 +0200:
> > On 07/18/2011 10:45 AM, Christian Hesse wrote:
> > > If I understand correctly the table reload suspends my device? With the
> > > root partition inside the crypt device I would have to do this in
> > > initram disk I think...
> > 
> > No. "load" will just load table into inactive slot. Following "resume"
> > will implicitly suspend device and immediately resume with new table (in
> > kernel) so it should be safe.
> 
> Ok, good to know.
> 
> > > Perhaps I really should wait for support in cryptsetup. :D
> > 
> > In devel tree is already "--allow-discard" option for luksOpen/create
> > command.
> 
> Already compiled. ;)
> 
> > (But I guess /etc/ctypttab need new option here as well for system
> > devices but that's must be fixed by initscripts. There will be no
> > cryptsetup command to enable it on-fly, just for activation commands.)
> 
> I do not use crypttab. All I need is a modified hook in my initrd...

Everything seems to work here...

14:50:07 root@leda:~# dmsetup table /dev/mapper/cvg
0 922742784 crypt aes-cbc-essiv:sha256
0000000000000000000000000000000000000000000000000000000000000000 0 8:2 4096 1
allow_discards
14:51:48 root@leda:~# dumpe2fs /dev/cvg/log | grep discard
dumpe2fs 1.41.14 (22-Dec-2010)
Default mount options:    discard

However mount does not list the discard option... Even when explicitly
remounting. Is this because it is the default mount option?

14:51:52 root@leda:~# mount | grep log
/dev/mapper/cvg-log on /var/log type ext4
(rw,relatime,user_xattr,acl,barrier=1,data=ordered)

Thanks again for you work!
-- 
Schoene Gruesse
Chris

Re: [dm-crypt] Status of trim for SSds?

[MkFly]

Will this also enable TRIM support for LVM volumes inside a
LUKS-encrypted partition?


On Thu, Jul 14, 2011 at 8:55 AM, Milan Broz <mbroz@redhat.com> wrote:
> On 07/14/2011 04:46 PM, André Gall wrote:
>
>> Is the support of TRIM a feature that's planned for the future? If so,
>> when? If not, why not?
>
> Patch is in dm-devel list, hopefully in linux-next soon for kernel 3.1.
> http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-crypt-optionally-support-discard-requests.patch
>
> Optional cryptsetup support will follow later (currently you have to use dmsetup).
>
> My opinion is that TRIM for encrypted disk is stupid idea, but so many people
> requested it... So enjoy shooting yourself in the foot ;-)
>
> Note - it will NEVER be enabled by default.
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Status of trim for SSds?

[Milan Broz]

On 07/24/2011 07:18 PM, MkFly wrote:
> Will this also enable TRIM support for LVM volumes inside a
> LUKS-encrypted partition?

yes, it should. (with exception of lvm snapshot LVs which do not support discards).

Milan

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Thu, Jul 14, 2011 at 04:12:45PM +0200, Heiko Rosemann wrote:
> On 07/14/2011 03:35 PM, Arno Wagner wrote:
> > On Thu, Jul 14, 2011 at 01:55:50PM +0200, Ma Begaj wrote:
> >>> Also note that an attacker that has access to the storage could 
> >>> patch your GnuPG binary or other system components.
> >> 
> >> well that is an another story because an attacker could in that
> >> case patch cryptsetup too. if s/he can do that it is not important
> >> whether you use encrypted key file on usb stick or directly
> >> cryptsetup.
> > 
> > Indeed. But are there any realistic scenarios where
> > 
> > a) a passphrase is signifiacntly less secure than an encrypted 
> > passphrase stored on USB with a second pasphrase to decrypt that
> > 
> > and
> > 
> > b) the attacker does not have the possibility to patch 
> > GnuPG/cryptup/other things that make the second passphrase just as
> > weak as the first one?
> > 
> > My claim is that a realistic risk analysis will show there are no
> > such scenarios that are typical and hence having an encrypted
> > passphrase on an USB stick does not offer improved security.
> 
> Improved security over which other setup?
> 
> a) Unencrypted passphrase stored on a USB key. Here the second
> encryption step will probably give additional security in case the user
> looses the USB key.

And the default situation does not have an USB key. So a net
security loss.
 
> b) Directly entering passphrase without the need of a USB key. Here we
> have a typical risk of users using the same passphrase for different
> things or even of writing it down (on a post-it note on the screen or
> keyboard...). If we depend upon a USB stick with the real passphrase
> (encrypted by the one on the post-it note) being present at boot the
> attacker won't be able to utilize that passphrase.

If we have stupid users, they will just tape the USB key to the
monitor besides the post-it. Or put it on a pice of string.
Then passphrase reuse will have the original risks, no improvement
by USB key usage.

If they are not stupid, they will have different passphrases 
and not post-it to the screen. 

> If we move kernel+initrd+cryptsetup to the USB stick and boot the
> machine from USB, we can even encrypt the entire harddisk, thus even
> someone with physical access to the machine cannot patch cryptsetup/gnupg.

Leaveing the scenario there. In this scenario we can use the
conventional passphrase input mechnism without any loss of 
security. no need for an encrypted passphrase on the USB key.
 
> Now it only boils down to whether a user writing down his passphrase
> will remember to remove the USB key ;)

Indeed.

> Regards, Heiko
> 
> P.S: Thinking of law enforcement as the attacker (guess that is not that
> a great risk for most of us), it is possible to destroy all access to
> your data by destroying all the USB keys with the encrypted passphrase
> on them - and then you can even tell them your passphrase...

You an do that with LUKS, just overwrite the slots you are using
with random passphrases. The question is what is easier. My guess
would be that fast destruction of USB keys is not that easy.

Not wanting to be obstinate here (but I have a lot experience
with risk evaluation), the main risk I see is that the USB-key
scheme is more complex and exposes you to a higher risk of data
loss as a consequence. I still do not see any advantage to 
having a separetely encrypted passphrase in a disk file.

I do see advantages to the kernel+initrd+cryptsetup on USB
option. That would indeed help against some attacks.


Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Passphrase protected key file?

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/14/2011 09:27 PM, Arno Wagner wrote:
> On Thu, Jul 14, 2011 at 04:12:45PM +0200, Heiko Rosemann wrote:
>> On 07/14/2011 03:35 PM, Arno Wagner wrote:
>>> Indeed. But are there any realistic scenarios where
>>> 
>>> a) a passphrase is signifiacntly less secure than an encrypted 
>>> passphrase stored on USB with a second pasphrase to decrypt that
>>> 
>>> and
>>> 
>>> b) the attacker does not have the possibility to patch 
>>> GnuPG/cryptup/other things that make the second passphrase just
>>> as weak as the first one?
>>> 
>>> My claim is that a realistic risk analysis will show there are
>>> no such scenarios that are typical and hence having an encrypted 
>>> passphrase on an USB stick does not offer improved security.
>> 
>> Improved security over which other setup?
>> 
>> a) Unencrypted passphrase stored on a USB key. Here the second 
>> encryption step will probably give additional security in case the
>> user looses the USB key.
> 
> And the default situation does not have an USB key. So a net security
> loss.
> 
>> b) Directly entering passphrase without the need of a USB key. Here
>> we have a typical risk of users using the same passphrase for
>> different things or even of writing it down (on a post-it note on
>> the screen or keyboard...). If we depend upon a USB stick with the
>> real passphrase (encrypted by the one on the post-it note) being
>> present at boot the attacker won't be able to utilize that
>> passphrase.
> 
> If we have stupid users, they will just tape the USB key to the 
> monitor besides the post-it. Or put it on a pice of string. Then
> passphrase reuse will have the original risks, no improvement by USB
> key usage.
> 
> If they are not stupid, they will have different passphrases and not
> post-it to the screen.

True up to that point where remembering a great number of different good
passphrases becomes impossible.

>> If we move kernel+initrd+cryptsetup to the USB stick and boot the 
>> machine from USB, we can even encrypt the entire harddisk, thus
>> even someone with physical access to the machine cannot patch
>> cryptsetup/gnupg.
> 
> Leaveing the scenario there. In this scenario we can use the 
> conventional passphrase input mechnism without any loss of security.
> no need for an encrypted passphrase on the USB key.

If the LUKS-drive gets lost or stolen together with (knowledge about)
the conventional passphrase (i.e. a laptop with a passphrase-post-it)
the thief will still need to steal the USB key as well, if there is an
encrypted passphrase on it. I'm not sure about others, but I tend to
carry my USB keys in my pocket or on my keychain, not in my laptop case.

>> P.S: Thinking of law enforcement as the attacker (guess that is not
>> that a great risk for most of us), it is possible to destroy all
>> access to your data by destroying all the USB keys with the
>> encrypted passphrase on them - and then you can even tell them your
>> passphrase...
> 
> You an do that with LUKS, just overwrite the slots you are using with
> random passphrases. The question is what is easier. My guess would be
> that fast destruction of USB keys is not that easy.

It depends :)

The main advantage I see about the USB key option is that the USB key
does not have to be in the same room as the encrypted device. I.e. the
FBI could come to your home while you are away and take away your
computer and when you arrive you notice something is wrong and have the
time to destroy the USB key (I'm thinking of some physical way here like
burning it on a barbeque, cooking it in solder, cutting the chips apart
with a micro-drill...) and can then openly tell a court that you don't
have any access to your data anymore.

Or you notice your harddrive has been stolen and then you can delete the
key without any remaining worries about possible social engineering to
get your passphrase. Or the police knock on your door at night and you
flush the USB key down the toilet (matter of seconds) instead of booting
up your PC and overwriting all key slots (matter of minutes, police
kicking in your door in the meantime)

Might be I've been watching too many bad hacker movies to do good risk
evaluation ;)

> Not wanting to be obstinate here (but I have a lot experience with
> risk evaluation), the main risk I see is that the USB-key scheme is
> more complex and exposes you to a higher risk of data loss as a
> consequence. I still do not see any advantage to having a separetely
> encrypted passphrase in a disk file.
> 
> I do see advantages to the kernel+initrd+cryptsetup on USB option.
> That would indeed help against some attacks.

It can also - to a very casual attacker - hide the encrypted area by
booting a different OS from the harddrive when there is no USB key
attached. Or if you are very, very, very sure never to forget to plug in
the correct USB key, you could automatically wipe the LUKS key slots
when the machine is booted without the USB key.

Regards, Heiko
- -- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4fXdgACgkQ/Vb5NagElAVaAQCfSd6bn4VbuOzL8FZywdEExTUj
gEgAnRf1IMz932/i0MjdbzEDPYJdK/UP
=W+uF
-----END PGP SIGNATURE-----

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Thu, Jul 14, 2011 at 11:21:28PM +0200, Heiko Rosemann wrote:
> On 07/14/2011 09:27 PM, Arno Wagner wrote:
> > On Thu, Jul 14, 2011 at 04:12:45PM +0200, Heiko Rosemann wrote:
> >> On 07/14/2011 03:35 PM, Arno Wagner wrote:
> >>> Indeed. But are there any realistic scenarios where
> >>> 
> >>> a) a passphrase is signifiacntly less secure than an encrypted 
> >>> passphrase stored on USB with a second pasphrase to decrypt that
> >>> 
> >>> and
> >>> 
> >>> b) the attacker does not have the possibility to patch 
> >>> GnuPG/cryptup/other things that make the second passphrase just
> >>> as weak as the first one?
> >>> 
> >>> My claim is that a realistic risk analysis will show there are
> >>> no such scenarios that are typical and hence having an encrypted 
> >>> passphrase on an USB stick does not offer improved security.
> >> 
> >> Improved security over which other setup?
> >> 
> >> a) Unencrypted passphrase stored on a USB key. Here the second 
> >> encryption step will probably give additional security in case the
> >> user looses the USB key.
> > 
> > And the default situation does not have an USB key. So a net security
> > loss.
> > 
> >> b) Directly entering passphrase without the need of a USB key. Here
> >> we have a typical risk of users using the same passphrase for
> >> different things or even of writing it down (on a post-it note on
> >> the screen or keyboard...). If we depend upon a USB stick with the
> >> real passphrase (encrypted by the one on the post-it note) being
> >> present at boot the attacker won't be able to utilize that
> >> passphrase.
> > 
> > If we have stupid users, they will just tape the USB key to the 
> > monitor besides the post-it. Or put it on a pice of string. Then
> > passphrase reuse will have the original risks, no improvement by USB
> > key usage.
> > 
> > If they are not stupid, they will have different passphrases and not
> > post-it to the screen.
> 
> True up to that point where remembering a great number of different good
> passphrases becomes impossible.

That is a problem, yes. But let's face it, how many do you have? 
I have one for disk encryption (reuse there is not a big risk,
all are under my control) and one for GnuPG and that is it.
 
> >> If we move kernel+initrd+cryptsetup to the USB stick and boot the 
> >> machine from USB, we can even encrypt the entire harddisk, thus
> >> even someone with physical access to the machine cannot patch
> >> cryptsetup/gnupg.
> > 
> > Leaveing the scenario there. In this scenario we can use the 
> > conventional passphrase input mechnism without any loss of security.
> > no need for an encrypted passphrase on the USB key.
> 
> If the LUKS-drive gets lost or stolen together with (knowledge about)
> the conventional passphrase (i.e. a laptop with a passphrase-post-it)
> the thief will still need to steal the USB key as well, if there is an
> encrypted passphrase on it. I'm not sure about others, but I tend to
> carry my USB keys in my pocket or on my keychain, not in my laptop case.

But I bet you do not have a post-it with the passphrase on
the laptop either ;-)

 
> >> P.S: Thinking of law enforcement as the attacker (guess that is not
> >> that a great risk for most of us), it is possible to destroy all
> >> access to your data by destroying all the USB keys with the
> >> encrypted passphrase on them - and then you can even tell them your
> >> passphrase...
> > 
> > You an do that with LUKS, just overwrite the slots you are using with
> > random passphrases. The question is what is easier. My guess would be
> > that fast destruction of USB keys is not that easy.
> 
> It depends :)
> 
> The main advantage I see about the USB key option is that the USB key
> does not have to be in the same room as the encrypted device. I.e. the
> FBI could come to your home while you are away and take away your
> computer and when you arrive you notice something is wrong and have the
> time to destroy the USB key (I'm thinking of some physical way here like
> burning it on a barbeque, cooking it in solder, cutting the chips apart
> with a micro-drill...) and can then openly tell a court that you don't
> have any access to your data anymore.

Well, that was the old approach, until they found out they
could not break modern disk or file encryption. Now they will 
either break in silently and install a hardware keylogger and
a camera to find out what you are using, or they will break 
down your door while the machine is running and decrypted. 

You can buy forensic kits that let you separate a running PC 
from the power lines and transport it without shutting it off. 
This is in fact not difficult to do. Material is basically
an UPS, some mains-capable clamps, isolation-gloves and
a standard AC voltmeter. I have simulated doing this myself
(with 500V rated gloves, welding-goggles and an ground fault
proector in the line) and it is quite doable.

> Or you notice your harddrive has been stolen and then you can delete the
> key without any remaining worries about possible social engineering to
> get your passphrase. Or the police knock on your door at night and you
> flush the USB key down the toilet (matter of seconds) instead of booting
> up your PC and overwriting all key slots (matter of minutes, police
> kicking in your door in the meantime)

Well, I think these are borderline scenarios. Also remember than unless
you are in certain states like the UK or the US, the police cannot 
force you to give them your passphrase. But in certain situations, 
these might be valid approaches. I see your point.

> Might be I've been watching too many bad hacker movies to do good risk
> evaluation ;)

Possibly. The trick is to keep the whole risk-landscape in view
and palance your efforts.

> > Not wanting to be obstinate here (but I have a lot experience with
> > risk evaluation), the main risk I see is that the USB-key scheme is
> > more complex and exposes you to a higher risk of data loss as a
> > consequence. I still do not see any advantage to having a separetely
> > encrypted passphrase in a disk file.
> > 
> > I do see advantages to the kernel+initrd+cryptsetup on USB option.
> > That would indeed help against some attacks.
> 
> It can also - to a very casual attacker - hide the encrypted area by
> booting a different OS from the harddrive when there is no USB key
> attached. Or if you are very, very, very sure never to forget to plug in
> the correct USB key, you could automatically wipe the LUKS key slots
> when the machine is booted without the USB key.

Oooooh, a solution for _real_ men! I like it ;-)

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Passphrase protected key file?

[Iggy]

On 07/14/2011 05:44 PM, Arno Wagner wrote:
> On Thu, Jul 14, 2011 at 11:21:28PM +0200, Heiko Rosemann wrote:
>> On 07/14/2011 09:27 PM, Arno Wagner wrote:
>>> On Thu, Jul 14, 2011 at 04:12:45PM +0200, Heiko Rosemann wrote:
>>>> On 07/14/2011 03:35 PM, Arno Wagner wrote:
[...]
>>
>> The main advantage I see about the USB key option is that the USB key
>> does not have to be in the same room as the encrypted device. I.e. the
>> FBI could come to your home while you are away and take away your
>> computer and when you arrive you notice something is wrong and have the
>> time to destroy the USB key (I'm thinking of some physical way here like
>> burning it on a barbeque, cooking it in solder, cutting the chips apart
>> with a micro-drill...) and can then openly tell a court that you don't
>> have any access to your data anymore.
> Well, that was the old approach, until they found out they
> could not break modern disk or file encryption. Now they will 
> either break in silently and install a hardware keylogger and
> a camera to find out what you are using, or they will break 
> down your door while the machine is running and decrypted. 
The fact that breaking modern strong encryption has not yet been used to
prosecute criminal or other cases tried in open court does not mean that
"they" cannot break it.  It is common for legal cases, or certain
charges, to be dropped when prosecuting them would disclose the
existence of advanced surveillance/espionage techniques that are closely
held/very useful.

Many spies that have been outed in the US have not been prosecuted for
this very reason.  A more direct example is found with the ability to
remotely (and invisibly to the user) open the audio channel on some cell
phones/networks.  US law enforcement was apparently able to do this for
a number of years before they first mentioned it publicly in a case
against a Boston mobster some few years ago.  In that case the defendant
had been sneaky enough for long enough that the FBI felt it was worth
outing that technology in order to get their prosecution.

There is plenty of data out there (fortunately none that I control!)
that is valuable enough for major powers to be willing to spend a lot of
money to acquire, even if they can never publicize that acquisition. 
Underestimating the US NSA seems unwise.

[...]
>> Or you notice your harddrive has been stolen and then you can delete the
>> key without any remaining worries about possible social engineering to
>> get your passphrase. Or the police knock on your door at night and you
>> flush the USB key down the toilet (matter of seconds) instead of booting
>> up your PC and overwriting all key slots (matter of minutes, police
>> kicking in your door in the meantime)
> Well, I think these are borderline scenarios. Also remember than unless
> you are in certain states like the UK or the US, the police cannot 
> force you to give them your passphrase. But in certain situations, 
> these might be valid approaches. I see your point.
These may be a marginal percentage of total use-cases, but they may also
be some of the strongest cases for using strong encryption. 
Unfortunately in these severe cases you may protect your data, but the
fact that you are not able to reveal the data may not protect you from
the rubber hose or worse.

[...]
>> It can also - to a very casual attacker - hide the encrypted area by
>> booting a different OS from the harddrive when there is no USB key
>> attached. Or if you are very, very, very sure never to forget to plug in
>> the correct USB key, you could automatically wipe the LUKS key slots
>> when the machine is booted without the USB key.
That's certainly a bold setup.  But for those marginal cases, possibly a
useful one.  You'd also have to wipe the script that overwrites the key
slots (and be using a non-journaling file system to be able to do that
securely).  Depending on the setup and situation this may allow, or at
least be a step toward allowing, one to plausibly deny the existence of
encrypted data.  Which in turn may just save our hypothetical user from
the rubber hose.

Of course, any number of human or technical errors (cracked solder joint
in USB port scares me) could result in total data loss.  Maybe our user
is doing encrypted remote backups via TOR and VPN?  Either way, it
requires bigger genitalia than I have.  It's a severe risk-landscape
that would justify this solution, but interesting to imagine.

-Ig

[...]

Re: [dm-crypt] Passphrase protected key file?

[Laurence Darby]

Iggy wrote:

> 
> 
> On 07/14/2011 05:44 PM, Arno Wagner wrote:
> > Well, I think these are borderline scenarios. Also remember than
> > unless you are in certain states like the UK or the US, the police
> > cannot force you to give them your passphrase. But in certain
> > situations, these might be valid approaches. I see your point.
> These may be a marginal percentage of total use-cases, but they may
> also be some of the strongest cases for using strong encryption. 
> Unfortunately in these severe cases you may protect your data, but the
> fact that you are not able to reveal the data may not protect you from
> the rubber hose or worse.
> 

That's what I've been wondering about.  In the UK with the RIPA act, if
the key is destroyed, my guess is they will still send you to prison
out of spite and as an example to others to not do that.

Some other things I've been thinking about - I don't think TrueCrypt's
plausible deniability is worth anything, it depends on your ability to
lie to people whose job it is to tell when people are lying, and if
they don't believe you then it was pointless.  So it may be useful to
be able to prove everything has been decrypted, eg. by comparing disk
sizes of decrypted vs encrypted data.

A really bad scenario is there _isn't_ any encrypted data, it's just
a random data, and they believe it's encrypted, then you are up shit
creek in a barbed wire canoe and will go to prison for nothing.  That
could even be used as an attack - random data and relevant decryption
software could be planted on someone, that could ruin their day, you
don't even have to obtain real illegal information to plant on them
(until they make encryption software illegal, that is)

Laurence

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Wed, Aug 03, 2011 at 01:09:26PM +0100, Laurence Darby wrote:
> Iggy wrote:
> 
> > 
> > 
> > On 07/14/2011 05:44 PM, Arno Wagner wrote:
> > > Well, I think these are borderline scenarios. Also remember than
> > > unless you are in certain states like the UK or the US, the police
> > > cannot force you to give them your passphrase. But in certain
> > > situations, these might be valid approaches. I see your point.
> > These may be a marginal percentage of total use-cases, but they may
> > also be some of the strongest cases for using strong encryption. 
> > Unfortunately in these severe cases you may protect your data, but the
> > fact that you are not able to reveal the data may not protect you from
> > the rubber hose or worse.
> > 
> 
> That's what I've been wondering about.  In the UK with the
> RIPA act, if the key is destroyed, my guess is they will still
> send you to prison out of spite and as an example to others to
> not do that.

Or they can just claim that the "destruction" was a misdirection
and that you surely still have the key. Simple scenario:
You have a LUKS header that you do not use and really do 
plain dm-crypt with an offset inside. No way for you to prove 
you do not. Well, maybe if the unused sectors contain
unencrypted zeros.

The whole situation with authorities being able to force you 
to give up keys is really quite amoral, as you never can
conclusively prove you do not have any. It negates "in dubio
pro reo" which is a fundamental guiding principle of all
modern criminal law.
 
> Some other things I've been thinking about - I don't think
> TrueCrypt's plausible deniability is worth anything, it
> depends on your ability to lie to people whose job it is to
> tell when people are lying, and if they don't believe you then
> it was pointless.  So it may be useful to be able to prove
> everything has been decrypted, eg.  by comparing disk sizes of
> decrypted vs encrypted data.

I completely agree on both points. Actually this is one reason
why I recommend either not using TrueCrypt or having a hidden 
container you can turn over. TrueCrypt without hidden container
is a serious risk, expecially as the hidden container is easily 
found in the documentation, even if you do not understand crypto.

> A really bad scenario is there _isn't_ any encrypted data,
> it's just a random data, and they believe it's encrypted, then
> you are up shit creek in a barbed wire canoe and will go to
> prison for nothing.  That could even be used as an attack -
> random data and relevant decryption software could be planted
> on someone, that could ruin their day, you don't even have to
> obtain real illegal information to plant on them (until they
> make encryption software illegal, that is)

As far as I know, TrueCrypt does cryto-overwite blank space,
removing all possibility of you proving you have given them
everything. I should probably add a warning in the FAQ that
blanking an encrypted device could expose you to the rubber 
hose. Or maybe a complete section about countries that can force
you to give up keys.... :-/

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Passphrase protected key file?

[Laurence Darby]

Hello again,

Arno Wagner wrote:

> > Alternatively, I could just do this:
> > 
> > ( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file
> > - /dev/loop1 loop1
> > 
> > so I still have to provide both the key and passphrase, terminated
> > with Ctrl-D.  Any thoughts?
> 
> Yes, why do you not use the passphrase entry function of cryptsetup
> directly? Without a specific and credible risk, there is no
> reason to do anything of what you describe here...


Ok, but I may have a reason I need to do this anyway, that probably no
one else has - these disks are external usb connected disks and they are
noisy, so I keep them powered off unless backing up to them. Their power
management is really broken, or maybe linux is, so I connected them to
a relay on the parallel port to properly power them off. That setup has
been working for years, and to keep it automated with encryption, the
key has to be stored somewhere, doesn't it?

I'm not sure I understand the point of having a key file, if that key
file isn't protected somehow - an attacker would have access to the
machine that stores the key as well.  (I'm not going to spend €50000 on
a HSM for this, that would be overamplifing risks by a very long way)

An attacker would have to break into the system after I've entered the
passphrase, without powering it off (notwithstanding cold-boot
attacks), but that's the same case as with normal disk encryption,
isn't it? If the disks were kept powered on, I would enter the
passphrase once at boot up, and keep the disk mounted.  Isn't that what
everyone else does? To get the same but with the disks powering off, I
would decrypt the passphrase to a ramfs (not /dev/shm, as that can get
written to swap), and make cryptsetup read it from there. 



> I would suggest you read up a bit more on cryptography. 
> "Cryptography Engineering" by Schneier et al. is a good book for
> example, to get a good understanding of cryto technology
> and risks.
> 
> You are at the moment in this dangerous "half-knowledge" state, 
> were you see some risks and overamplify them, while you completely 
> miss others. It is normal to go through this stage, but make sure 
> you leave it behind. 

Yes, well, I know that, and really if I didn't overamplify some
risks, then I would probably just not bother with disk encryption at
all, but that doesn't achieve or teach me anything. Anyway, I live in
the UK which has the RIPA act, so they send people to prison simply for
not handing over the keys. Check the references on
http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000

Laurence

Re: [dm-crypt] Passphrase protected key file?

[Arno Wagner]

On Wed, Aug 03, 2011 at 12:35:55PM +0100, Laurence Darby wrote:
> 
> Hello again,
> 
> Arno Wagner wrote:
> 
> > > Alternatively, I could just do this:
> > > 
> > > ( cat ~/pass_key ; cat ) | cryptsetup luksOpen --key-file
> > > - /dev/loop1 loop1
> > > 
> > > so I still have to provide both the key and passphrase, terminated
> > > with Ctrl-D.  Any thoughts?
> > 
> > Yes, why do you not use the passphrase entry function of cryptsetup
> > directly? Without a specific and credible risk, there is no
> > reason to do anything of what you describe here...
> 
> 
> Ok, but I may have a reason I need to do this anyway, that probably no
> one else has - these disks are external usb connected disks and they are
> noisy, so I keep them powered off unless backing up to them. Their power
> management is really broken, or maybe linux is, so I connected them to
> a relay on the parallel port to properly power them off. That setup has
> been working for years, and to keep it automated with encryption, the
> key has to be stored somewhere, doesn't it?

Yes.
 
> I'm not sure I understand the point of having a key file, if that key
> file isn't protected somehow - an attacker would have access to the
> machine that stores the key as well.  (I'm not going to spend ?50000 on
> a HSM for this, that would be overamplifing risks by a very long way)
> 
> An attacker would have to break into the system after I've entered the
> passphrase, without powering it off (notwithstanding cold-boot
> attacks), but that's the same case as with normal disk encryption,
> isn't it? If the disks were kept powered on, I would enter the
> passphrase once at boot up, and keep the disk mounted.  Isn't that what
> everyone else does? To get the same but with the disks powering off, I
> would decrypt the passphrase to a ramfs (not /dev/shm, as that can get
> written to swap), and make cryptsetup read it from there. 

Why don't you just use decrypt_derived or have an encrypted
partition that is not powered down? You can put the keys there
without additional protection (well, root read rights, but not
more)?
 
> > I would suggest you read up a bit more on cryptography. 
> > "Cryptography Engineering" by Schneier et al. is a good book for
> > example, to get a good understanding of cryto technology
> > and risks.
> > 
> > You are at the moment in this dangerous "half-knowledge" state, 
> > were you see some risks and overamplify them, while you completely 
> > miss others. It is normal to go through this stage, but make sure 
> > you leave it behind. 
> 
> Yes, well, I know that, and really if I didn't overamplify some
> risks, then I would probably just not bother with disk encryption at
> all, but that doesn't achieve or teach me anything. Anyway, I live in
> the UK which has the RIPA act, so they send people to prison simply for
> not handing over the keys. Check the references on
> http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000

Pretty bad that, I agree. The UK has given up on being 
civilized and having a fair legal system in that regard.

Arno 
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier