[dm-crypt] nuke password to delete luks header

[dm-crypt] nuke password to delete luks header

[R3s1stanc3]

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi
today I read this post by the developers of Kali Linux:
http://www.kali.org/how-to/emergency-self-destruction-luks-kali/

I think, this is a really great feature and should be officially added
to the cryptsetup source.
So I wrote Milan and he told me, that there would be no additional
security, because an "attacker will simple first backup header and then
use this (or will use key from memory if device is mounted)."
He also told me to move the discussion to the mailinglist and if we
would find some valuable use case, they would think about it.
So now I'm here
In my opinion, a valuable use case would be the following case:
If you got the possibility to access your computer for a few seconds,
before an attacker does, you simply could enter your nuke password and
delete the luks header. This would be much faster, than entering your
real password, booting your system and deleting the header, using the
system's tools

Are there any other ideas of valuable use cases?

greets R3s1stanc3
-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlLLGcQACgkQUaCkMJCt6r7pMAD/ahtaUWTCmuw4Q8QwdlpD/dZM
SSDgTw2U/fM6mZH618AA/0MuHeitb94r+mNVFniPBiKVz53ZtoguFXnXsczx7Qs4
=f/OJ
-----END PGP SIGNATURE-----


[-- Attachment #2: 0xDBCB4A0A.asc --]
[-- Type: application/pgp-keys, Size: 21034 bytes --]

[-- Attachment #3: 0xDBCB4A0A.asc.sig --]
[-- Type: application/pgp-signature, Size: 96 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Heinz Diehl]

On 06.01.2014, R3s1stanc3 wrote: 

> If you got the possibility to access your computer for a few seconds,
> before an attacker does, you simply could enter your nuke password and
> delete the luks header.

You maybe could just switch off the power?! Depends on the situation..

Re: [dm-crypt] nuke password to delete luks header

[R3s1stanc3]

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On 06.01.2014, Heinz Diehl wrote:
> On 06.01.2014, R3s1stanc3 wrote:
>
>> If you got the possibility to access your computer for a few seconds,
>> before an attacker does, you simply could enter your nuke password and
>> delete the luks header.
>
> You maybe could just switch off the power?! Depends on the situation..
>
>
I'm thinking of the most extreme case, where the attacker has the
resources to bruteforce your password.
Also the case is, that your computer is turned off. If you start it and
enter your nuke password, then the header will be deleted.
-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlLLI60ACgkQUaCkMJCt6r62mQD8C5sgzqWscWPRBwYJOgeBxuk4
BlCPvYkbfOsODQ0am0gBAKb5SP8tGGFjVDdfISutX+XtGgsT7iBjCw/L/JfDleJl
=LMXR
-----END PGP SIGNATURE-----


[-- Attachment #2: 0xDBCB4A0A.asc --]
[-- Type: application/pgp-keys, Size: 21034 bytes --]

[-- Attachment #3: 0xDBCB4A0A.asc.sig --]
[-- Type: application/pgp-signature, Size: 96 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Claudio Moretti]

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

On Mon, Jan 6, 2014 at 9:44 PM, R3s1stanc3 <r3s1stanc3@riseup.net> wrote:

> I'm thinking of the most extreme case, where the attacker has the
> resources to bruteforce your password.
>

Or something like https://xkcd.com/538/ ?

[-- Attachment #2: Type: text/html, Size: 609 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[R3s1stanc3]

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On 07.01.2014, Claudio Moretti wrote:
> On Mon, Jan 6, 2014 at 9:44 PM, R3s1stanc3 <r3s1stanc3@riseup.net> wrote:
>
>> I'm thinking of the most extreme case, where the attacker has the
>> resources to bruteforce your password.
>>
>
> Or something like https://xkcd.com/538/ ?
Well yeah, we all know that they will try to force you, to tell your
password. But the attacker will also know, that without the master key,
there is simply no way of restoring the data
-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlLLPmMACgkQUaCkMJCt6r6G3wD9EZS+e0YaoxaIY2VuaGa8ilrH
DOzxDg7TM8yKPHxpKOUA/A9xvdEZFSxp+gvNzhWHlW3EZT3wZ9eJg94VpyuSQ9/I
=BPfa
-----END PGP SIGNATURE-----


[-- Attachment #2: 0xDBCB4A0A.asc --]
[-- Type: application/pgp-keys, Size: 21034 bytes --]

[-- Attachment #3: 0xDBCB4A0A.asc.sig --]
[-- Type: application/pgp-signature, Size: 96 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Mon, Jan 06, 2014 at 22:44:13 CET, R3s1stanc3 wrote:
> 
> 
> On 06.01.2014, Heinz Diehl wrote:
> > On 06.01.2014, R3s1stanc3 wrote:
> >
> >> If you got the possibility to access your computer for a few seconds,
> >> before an attacker does, you simply could enter your nuke password and
> >> delete the luks header.
> >
> > You maybe could just switch off the power?! Depends on the situation..
> >
> >
> I'm thinking of the most extreme case, where the attacker has the
> resources to bruteforce your password.

An attacker that can brute-force your password will not allow you
a chance to nuke it first. Please stop dreaming.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Mon, Jan 06, 2014 at 22:01:56 CET, R3s1stanc3 wrote:
> 
> Hi
> today I read this post by the developers of Kali Linux:
> http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
> 
> I think, this is a really great feature and should be officially added
> to the cryptsetup source.
> So I wrote Milan and he told me, that there would be no additional
> security, because an "attacker will simple first backup header and then
> use this (or will use key from memory if device is mounted)."

And he is right. There are border-cases though: If you, for example, 
cross the border of some unnamed but well-known states and they ask
you to unlock your LUKS container (a low/no-suspicion situation; on
medium and above suspicion they will already mirror your disk first), 
entering your nuke password will make you unable to do so.

Now, have you won or lost? 

You have lost. First, they will arrest you because you fail to unlock 
your computer. If you are unlucky, they will find the nuke-patch or 
its effects and suspect you of having nuked the container (and maybe 
find out that you indeed did). Then they will not only hold you for 
deportation, but maybe a few years imprisonment first for "destroying 
evidence". Or maybe a long time without trial for being a "terrorist 
suspect".

If you do this on an SSD, all data may still be there anyways. 

If they look at this stuff on medium or higher suspicion and
find the nuke-password option, then you may be screwed in a 
similar fashion, just because of this. 

So, no, this does not add security, but it can get you into 
really bad trouble, including a significant time in prison.

(Yes, it should not, but authoritarian regimes do not have laws 
based on ethics or benefit to its citizens. They have sbverted the 
idea of "the law" to make it an effective instrument of oppression, 
i.e., a weapon against ordinary people. This tendency can now be 
observed in the western world in several places.)	 

My advice for the use-case "border crossing" is to not have 
encrypted data or suspicious data of any kind in the first 
place. If you have encrypted data, immediately and without 
question, allow them access to it.

If you need confidental data in such a situation, download it
later over the net, PGP/GnuPG is still out of the TLA's ability
to break is the passphrase is good. 

> He also told me to move the discussion to the mailinglist and if we
> would find some valuable use case, they would think about it.
> So now I'm here
> In my opinion, a valuable use case would be the following case:
> If you got the possibility to access your computer for a few seconds,
> before an attacker does, you simply could enter your nuke password and
> delete the luks header. This would be much faster, than entering your
> real password, booting your system and deleting the header, using the
> system's tools
> 
> Are there any other ideas of valuable use cases?

That is not an use case. That is merely a description of a technical
situation. A use-case needs a credible real-world situation of some 
detail, see my border-crossing example. It is just way to easy to come 
up with higly abstracted technical situations that do not have any 
real-world equivalent or are missing important real-world aspects, 
such as effects from using the technical feature. 

And, yes, this has been discussed time and again, without ever finding
a situation where it helps and quite a few where it harms. I will add
an FAQ entry for this, I think. But please, feel free to try for
any real-world use-cases. If there are any credible ones, I will add
them to the FAQ entry as well.

Arno 
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Jim O'Gorman]

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

> Hi
> today I read this post by the developers of Kali Linux:
> http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
...
> Are there any other ideas of valuable use cases?
>
> greets R3s1stanc3

Hi there! We were just pointed to this discussion so thought we would chime in.

The practical application of this functionality is real for us. This is not an academic issue for us, as we will often travel in the real world with large amounts of encrypted data to areas where high speed internet is not accessible. Please check a common use case we deploy very often, that we documented at http://www.kali.org/how-to/nuke-kali-linux-luks/

In that, we mention:

> Our main purpose for introducing this feature in Kali Linux is to simplify the process of securely traveling with confidential client information. While “LUKS Nuking” your drive will result in an inaccessible disk, it is possible to backup your keyslots beforehand and restore them after the fact. What this allows us to do is to “brick” our sensitive laptops before any travel, separate ourselves from the restoration keys (which we encrypt), and then “restore” them to the machines once back in a safe location. This way, if our hardware is lost or otherwise accessed midway through our travels, no one is able to restore the data on it, including ourselves.
>
> There are other ways to delete your keyslots, however the advantage of the Nuke option is it is quick, easy, and does not require you to fully login to your Kali installation. If you maintain a backup of your header, you can Nuke the keyslots whenever you feel uncomfortable. Then conduct a restoration when you feel secure.

This situation is very common for us in situations where systems may be inspected by parties that may not be friendly to us. Border crossings are a common example of this.

I am not a big believer in the concept of providing the nuke password to this unfriendly third party, but more of using it yourself without having to fully log into the system (with the assumption that you travel with the systems fully powered off). The Nuke option, for us makes this process of deleting the keys quick, simple, and error proof. Having the ability to restore the data later on makes this practical to do on a regular basis. 

Additionally it is important to be realistic about who your adversary is. Is it really a nation state? Or is it simply a customs agent? We don't think its practical to cover all threats with a function like this, and we don't believe that "if you can't do it all, its better to do nothing". Remember, that in most cases when you can't/won't give up an encryption password in the US the hardware is simply taken from you. You don't go right to jail unless there is other suspicion to justify incarceration. 

Thanks everyone!
-- 
Jim O'Gorman
jim@offensive-security.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 710 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

> This situation is very common for us in situations where systems may be
> inspected by parties that may not be friendly to us. Border crossings are a
> common example of this.
>
>
whats the recommended answer to give in such situation where an encrypted
volume is clearly visible since its LUKS but you are unable to open it when
asked by authorities since you nuked all key slots?If you cant open the
volume and If you are not believed,then any answer you will give most
likely will not be believable and hence "the password was XXX but it now
doesnt work because i nuked it" is just as believable as "i dont remember
the password" or "i dont know the password,i am just carrying the laptop
for a friend".

[-- Attachment #2: Type: text/html, Size: 1020 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Jim O'Gorman]

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

On 13 Jan 2014, at 21:41, .. ink .. wrote:
>> This situation is very common for us in situations where systems may be
>> inspected by parties that may not be friendly to us. Border crossings are a
>> common example of this.
>>
>>
> whats the recommended answer to give in such situation where an encrypted
> volume is clearly visible since its LUKS but you are unable to open it when
> asked by authorities since you nuked all key slots?If you cant open the
> volume and If you are not believed,then any answer you will give most
> likely will not be believable and hence "the password was XXX but it now
> doesnt work because i nuked it" is just as believable as "i dont remember
> the password" or "i dont know the password,i am just carrying the laptop
> for a friend".

Personally, I think the "right" answer is going to be different for everyone and we can only speak to what we do.

We feel strongly about not lying in these sort of situations. I agree, that a lie and a truth is very much the same and hard to separate one from the other for a front line individual such as a normal customs agent. However, its better not to complicate the situation. So, we will truthfully say:

"As a matter of company policy, no employees travel with sensitive data stored in a manner that is accessible in transit. As such, I have no way of accessing any of the data on this system."

Realistically, in the vast majority of the cases this is perfectly adequate as all they are really looking to do is ensure the device is a real working laptop and not a bomb of some sort. In cases where you may be suspected of transferring contraband they will often have other supporting evidence. As all the work we do is sensitive, but legitimate, this is not an issue that we lose any sleep over. 
-- 
Jim O'Gorman
jim@offensive-security.com




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 710 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

> We feel strongly about not lying in these sort of situations. I agree,
> that a lie and a truth is very much the same and hard to separate one from
> the other for a front line individual such as a normal customs agent.
> However, its better not to complicate the situation. So, we will truthfully
> say:
>
>
perhaps the best way to pass sensitive data through unsuspecting customs
agent is to hide an encrypted volume under a normal file system.

with cryptsetup,the way to do it would be:
1. start with a block device like a usb stick
2. blank it out with random data.
3. put a regular file system like vfat at the beginning of the device.
4. put an encrypted plain volume somewhere at the back of the device.

If someone ask to see whats on the drive,you just open it with udisks or
any other mounting tool and show them its contents.
If they take the drive and check it out in their window's machine,they will
see a regular fat file system and they will be non the wiser.They will have
to inspect the drive with forensic tool first to see high quality random
data at the back of the file system and at this point,you can play the
plausible deniability thing but they wouldnt do this if they didnt already
suspect you are carrying something they want.

The above seem like a better alternative than a crippled LUKS volume.

[-- Attachment #2: Type: text/html, Size: 1717 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Tue, Jan 14, 2014 at 05:04:35 CET, .. ink .. wrote:
> > We feel strongly about not lying in these sort of situations. I agree,
> > that a lie and a truth is very much the same and hard to separate one from
> > the other for a front line individual such as a normal customs agent.
> > However, its better not to complicate the situation. So, we will truthfully
> > say:
> >
> >
> perhaps the best way to pass sensitive data through unsuspecting customs
> agent is to hide an encrypted volume under a normal file system.

Actually, that is the worst option. If found, you will be under
strong suspicion, as you tried to hide things.
 
> with cryptsetup,the way to do it would be:
> 1. start with a block device like a usb stick
> 2. blank it out with random data.
> 3. put a regular file system like vfat at the beginning of the device.
> 4. put an encrypted plain volume somewhere at the back of the device.

And any reasonable disk forensics tool will find that automatically
and fast. My keyslot-checker could be adapted to find something like
that in maybe one hour.

> If someone ask to see whats on the drive,you just open it with udisks or
> any other mounting tool and show them its contents.

Good luck with that.

Sure, of they just want to harass you, may work. But if they do
an actual search (and they may just do that), they will find it.
There will have to be some method in place to deal with true-crypt
hidden containers, but these are very much not foolproof either, 
see past discussions.

> If they take the drive and check it out in their window's machine,they will
> see a regular fat file system and they will be non the wiser.They will have
> to inspect the drive with forensic tool first to see high quality random
> data at the back of the file system and at this point,you can play the
> plausible deniability thing but they wouldnt do this if they didnt already
> suspect you are carrying something they want.

And you think they will not run that forensics tool? Plausible 
deniability does not work in practice.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

> > with cryptsetup,the way to do it would be:
> > 1. start with a block device like a usb stick
> > 2. blank it out with random data.
> > 3. put a regular file system like vfat at the beginning of the device.
> > 4. put an encrypted plain volume somewhere at the back of the device.
>
> And any reasonable disk forensics tool will find that automatically
> and fast. My keyslot-checker could be adapted to find something like
> that in maybe one hour.
>
>
are you saying that,if i create a 100MB file with data from "/dev/urandom"
and then put a vfat file system on it,and then i open a plain mapper at
50MB offset and create a second file system on the file through the
mapper,then your keyslot-checker or any other forensic tool will be able to
detect the presence of this plain volume?

If true,then i would appreciate any link to any discussion of it because i
am unaware of it.

[-- Attachment #2: Type: text/html, Size: 1253 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Tue, Jan 14, 2014 at 06:00:23 CET, .. ink .. wrote:
> > > with cryptsetup,the way to do it would be:
> > > 1. start with a block device like a usb stick
> > > 2. blank it out with random data.
> > > 3. put a regular file system like vfat at the beginning of the device.
> > > 4. put an encrypted plain volume somewhere at the back of the device.
> >
> > And any reasonable disk forensics tool will find that automatically
> > and fast. My keyslot-checker could be adapted to find something like
> > that in maybe one hour.
> >
> >
> are you saying that,if i create a 100MB file with data from "/dev/urandom"
> and then put a vfat file system on it,and then i open a plain mapper at
> 50MB offset and create a second file system on the file through the
> mapper,then your keyslot-checker or any other forensic tool will be able to
> detect the presence of this plain volume?

No, if you crypto-blank it, it will not. But you need to protect
the additional container against overwriting in some way. One
way is to not write the outer container at all. This is obvious,
as it is going to be either old and not written for a long time
or brand-new, i.e. container has been creatded for the border-
crossing. The way TC does it by preventing writes to that
area is likely to leacve traces of the failed writes.

> If true,then i would appreciate any link to any discussion of it because i
> am unaware of it.

See above.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

On Tue, Jan 14, 2014 at 2:11 AM, Arno Wagner <arno@wagner.name> wrote:

> On Tue, Jan 14, 2014 at 06:00:23 CET, .. ink .. wrote:
> > > > with cryptsetup,the way to do it would be:
> > > > 1. start with a block device like a usb stick
> > > > 2. blank it out with random data.
> > > > 3. put a regular file system like vfat at the beginning of the
> device.
> > > > 4. put an encrypted plain volume somewhere at the back of the device.
> > >
> > > And any reasonable disk forensics tool will find that automatically
> > > and fast. My keyslot-checker could be adapted to find something like
> > > that in maybe one hour.
> > >
> > >
> > are you saying that,if i create a 100MB file with data from
> "/dev/urandom"
> > and then put a vfat file system on it,and then i open a plain mapper at
> > 50MB offset and create a second file system on the file through the
> > mapper,then your keyslot-checker or any other forensic tool will be able
> to
> > detect the presence of this plain volume?
>
> No, if you crypto-blank it, it will not. But you need to protect
> the additional container against overwriting in some way. One
> way is to not write the outer container at all. This is obvious,
> as it is going to be either old and not written for a long time
> or brand-new, i.e. container has been creatded for the border-
> crossing. The way TC does it by preventing writes to that
> area is likely to leacve traces of the failed writes.
>
>
Its possible to use the first volume normally without harming the hidden
one by not filling up the out volume
to near capacity.If you dont cross past 30% volume utilization of the outer
volume,then the hidden volume will be
safe.This assumes using a proper file system and fat seem to be the best
one to use since its the most advanced
among the simplest file systems.

The scenario i am working with says something like this,you are at a border
cross with a external hard drive and there are 10 other people with
external hard drives and there is a government agent who is tasked with
examining external hard drives.What he may do is ask everybody to put their
hard drives in a bucket and he may go through them one by one.He will take
one,plug it in to a computer and look into it by doing file searches,then
go to the next one and do the same.If they reach yours,plug it in and get a
LUKS prompt,then they will call you up and ask you to open it,they will
probably be annoyed at you for slowing them down too.Once there,bringing up
the fifth amendment to the constitution or any other privacy related
explanation will probably not do you any good.The more you delay them,the
more they will be unhappy with you and the more unpleasant they will be.

If they have no reason to suspect you have an encrypted volume hidden at
the back of a regular file system,they will not look for it or ask you
about it and will just go past your hard drive uneventfully,the only time
they will examine your hard drive forensically is if you are already at the
backroom being interrogated while your possessions are being closely
scrutinized and they will do this most likely because they already know who
you are and what you could be carrying and you did something stupid to draw
suspicion to your hard drive.

If asked if the drive has a hidden volume,you could then answer "yes" and
proceed to do what you would have done if asked to unlock a LUKS volume or
any other encrypted volume.






> > If true,then i would appreciate any link to any discussion of it because
> i
> > am unaware of it.
>
> See above.
>
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
> ----
> There are two ways of constructing a software design: One way is to make it
> so simple that there are obviously no deficiencies, and the other way is to
> make it so complicated that there are no obvious deficiencies. The first
> method is far more difficult.  --Tony Hoare
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

[-- Attachment #2: Type: text/html, Size: 5229 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Tue, Jan 14, 2014 at 13:05:32 CET, .. ink .. wrote:
[...]
> > No, if you crypto-blank it, it will not. But you need to protect
> > the additional container against overwriting in some way. One
> > way is to not write the outer container at all. This is obvious,
> > as it is going to be either old and not written for a long time
> > or brand-new, i.e. container has been creatded for the border-
> > crossing. The way TC does it by preventing writes to that
> > area is likely to leacve traces of the failed writes.
> >
> >
> Its possible to use the first volume normally without harming the hidden
> one by not filling up the out volume
> to near capacity.If you dont cross past 30% volume utilization of the outer
> volume,then the hidden volume will be
> safe.This assumes using a proper file system and fat seem to be the best
> one to use since its the most advanced
> among the simplest file systems.

While I have not looked at it for some time, the last time I looked,
FAT did a create-at-end Strategy. This way the data "wanders" over 
the partition towrds the end. ext2/3/4 will create files all over 
the disk in the first place.

> The scenario i am working with says something like this,you are at a border
> cross with a external hard drive and there are 10 other people with
> external hard drives and there is a government agent who is tasked with
> examining external hard drives.What he may do is ask everybody to put their
> hard drives in a bucket and he may go through them one by one.He will take
> one,plug it in to a computer and look into it by doing file searches,then
> go to the next one and do the same.If they reach yours,plug it in and get a
> LUKS prompt,then they will call you up and ask you to open it,they will
> probably be annoyed at you for slowing them down too.Once there,bringing up
> the fifth amendment to the constitution or any other privacy related
> explanation will probably not do you any good.The more you delay them,the
> more they will be unhappy with you and the more unpleasant they will be.
> 
> If they have no reason to suspect you have an encrypted volume hidden at
> the back of a regular file system,they will not look for it or ask you
> about it and will just go past your hard drive uneventfully,the only time
> they will examine your hard drive forensically is if you are already at the
> backroom being interrogated while your possessions are being closely
> scrutinized and they will do this most likely because they already know who
> you are and what you could be carrying and you did something stupid to draw
> suspicion to your hard drive.
> 
> If asked if the drive has a hidden volume,you could then answer "yes" and
> proceed to do what you would have done if asked to unlock a LUKS volume or
> any other encrypted volume.

Well, if you are willing to give up a hidden volume, that would
work, I guess.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

> While I have not looked at it for some time, the last time I looked,
> FAT did a create-at-end Strategy. This way the data "wanders" over
> the partition towrds the end. ext2/3/4 will create files all over
> the disk in the first place.
>
>
My own tests have shown that with fat fs,files are not added randomly all
over the disk and are added sequentially.Meaning,if the volume is used
normally without exceeding a certain amount of disk space,the rest of the
disk will remain untouched.

I looked into this last week and my google searches on how fat handles
files have so far been unsuccessful.Most discussions i have found go
straight to implementation of the file system and my looking into that so
far produced nothing.

I tested this in an image file through a loop device so i assume a ready
block device would produce the same behavior.

[-- Attachment #2: Type: text/html, Size: 1191 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/14/2014 08:22 PM, .. ink .. wrote:
>  
> 
>     While I have not looked at it for some time, the last time I looked,
>     FAT did a create-at-end Strategy. This way the data "wanders" over
>     the partition towrds the end. ext2/3/4 will create files all over
>     the disk in the first place.
> 
> 
> My own tests have shown that with fat fs,files are not added randomly
> all over the disk and are added sequentially.Meaning,if the volume is
> used normally without exceeding a certain amount of disk space,the
> rest of the disk will remain untouched.

The whole hidden disk idea in TrueCrypt is based on this assumption,
and it works.

From "Filesystem Forensic Analysis" by Brian Carrier
(ISBN 978-0-321-26817-4), page 224, FAT allocation algorithms:

"The OS gets to choose which allocation algorithm it uses when it allocates
the clusters. I tested Windows98 and XP, and it appeared that a next available
algorithm was being used in both. The next available algorithm searches for
the first available cluster starting from the previously allocated cluster."

I think this will be very similar for other FAT implementations.

Milan

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Wed, Jan 15, 2014 at 20:36:53 CET, Milan Broz wrote:
> On 01/14/2014 08:22 PM, .. ink .. wrote:
> >  
> > 
> >     While I have not looked at it for some time, the last time I looked,
> >     FAT did a create-at-end Strategy. This way the data "wanders" over
> >     the partition towrds the end. ext2/3/4 will create files all over
> >     the disk in the first place.
> > 
> > 
> > My own tests have shown that with fat fs,files are not added randomly
> > all over the disk and are added sequentially.Meaning,if the volume is
> > used normally without exceeding a certain amount of disk space,the
> > rest of the disk will remain untouched.
> 
> The whole hidden disk idea in TrueCrypt is based on this assumption,
> and it works.
> 
> >From "Filesystem Forensic Analysis" by Brian Carrier
> (ISBN 978-0-321-26817-4), page 224, FAT allocation algorithms:
> 
> "The OS gets to choose which allocation algorithm it uses when it allocates
> the clusters. I tested Windows98 and XP, and it appeared that a next available
> algorithm was being used in both. The next available algorithm searches for
> the first available cluster starting from the previously allocated cluster."
> 
> I think this will be very similar for other FAT implementations.
> 
> Milan

Indeed. However if you delete files and add files over a time,
the allocated area has a tendency to wander towards the 
end. If you just create and extend, all will be at the
start in FAT, but that does not represent normal operation.

Because of this. TrueCrypt does protect the hidden container
when it is open or "protected". (It cannot protect it when it 
is not.) The effects of this protection can be visible.
See here:

http://www.truecrypt.org/docs/hidden-volume-protection

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Tue, Jan 14, 2014 at 03:52:37 CET, Jim O'Gorman wrote:
> On 13 Jan 2014, at 21:41, .. ink .. wrote:
> >> This situation is very common for us in situations where systems may be
> >> inspected by parties that may not be friendly to us. Border crossings
> >> are a common example of this.

I Assume you have seen my posting of what may happen to you
if you try this stunt? If not, here is a reference:

http://permalink.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7090

The problem is that the customs-person cannot distinguish between
a "nuked" LUKS header or one with passphrases you do not have or
one with passphrases you do have but refuse to give out. Sure, 
"nuking" could be done in a way that zeros the keyslots, making
it obvious. Could sill mean sitting in prison several weeks until
a forensics expert has the time to verify your claim. 

Even than, you could have placed a plain dm-crypt container at the
data-offset that you actually have the password for.

I think that in your scenario, "nuke" does not have any real
advantages over just not having the passphrase, and that one
is dangerous.


> >>
> > whats the recommended answer to give in such situation where an encrypted
> > volume is clearly visible since its LUKS but you are unable to open it when
> > asked by authorities since you nuked all key slots?If you cant open the
> > volume and If you are not believed,then any answer you will give most
> > likely will not be believable and hence "the password was XXX but it now
> > doesnt work because i nuked it" is just as believable as "i dont remember
> > the password" or "i dont know the password,i am just carrying the laptop
> > for a friend".
> 
> Personally, I think the "right" answer is going to be different for
> everyone and we can only speak to what we do.

In many cases the only right answer is not to get into that situation
in the first place. 

Never give "i am just carrying the laptop for a friend"!  That is the 
usual drug-mule story and customs may immediately recognize it as such.
 
> We feel strongly about not lying in these sort of situations. I agree,
> that a lie and a truth is very much the same and hard to separate one from
> the other for a front line individual such as a normal customs agent. 
> However, its better not to complicate the situation.  So, we will
> truthfully say:
> 
> "As a matter of company policy, no employees travel with sensitive data
> stored in a manner that is accessible in transit.  As such, I have no way
> of accessing any of the data on this system."
> 
> Realistically, in the vast majority of the cases this is perfectly
> adequate as all they are really looking to do is ensure the device is a
> real working laptop and not a bomb of some sort.  

Not true: In many cases, including UK and US, they are searching
for "illicit" material, like specific types of pornography and, 
I suspect, unlicensed music and movies. And they will check 
business laptops also.

While not lying is the right approach, it could still mean a few 
weeks in a cell. If that riek is covered by your contracts and
your employees are willing to risk it, that may be acceptable.

> In cases where you may
> be suspected of transferring contraband they will often have other
> supporting evidence.  As all the work we do is sensitive, but legitimate,
> this is not an issue that we lose any sleep over.

Until it goes wrong. I hope you have a good layer well versed in the
law of your target countries.

But, no, nothing in gere is a good case for a "nuke" option. It is
just a slight variant of the "I do not have the passphrase" version, 
and that is fully supported by LUKS as it is.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Jim O'Gorman]

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

On 13 Jan 2014, at 23:30, Arno Wagner wrote:
> I Assume you have seen my posting of what may happen to you
> if you try this stunt? If not, here is a reference:
>
> http://permalink.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7090
>
> The problem is that the customs-person cannot distinguish between
> a "nuked" LUKS header or one with passphrases you do not have or
> one with passphrases you do have but refuse to give out. Sure,
> "nuking" could be done in a way that zeros the keyslots, making
> it obvious. Could sill mean sitting in prison several weeks until
> a forensics expert has the time to verify your claim.
...
> Not true: In many cases, including UK and US, they are searching
> for "illicit" material, like specific types of pornography and,
> I suspect, unlicensed music and movies. And they will check
> business laptops also.
>
> While not lying is the right approach, it could still mean a few
> weeks in a cell. If that riek is covered by your contracts and
> your employees are willing to risk it, that may be acceptable.

We have a fair number of people on the team and do a large amount of international travel. To date, none of us have ended up in prison. In one case a device was taken and the only way we could get it back was to provide the password. So we replaced the device.

I understand that you are concerned about the risk of being sent to jail but I am not sure that concern is inline with what we are encountering in the real world. If you look at the ACLU's guidance on the matter, https://www.aclunc.org/blog/privacy-your-laptop-international-borders, the risk of jail is not even mentioned. 

Additionally I would recommend the EFF, https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices, as a great resource on this topic. On that page, they have a number of case scenarios and the likely consequences of not giving up the password. Our scenario that we mention is very similar to the "Case Scenario: Business Concerns" sidebar, where the traveler does not have the password.

Every time we have worked with the EFF, we have found them to be very knowledgable and we have a lot of respect for them. They take these matters seriously and are well informed on the topic. They suggest:

> If a border agent asks you to provide an account password or encryption passphrase or to decrypt data stored on your device, you don’t have to comply. Only a judge can force you to reveal information to the government, and only to the extent that you do not have a valid Fifth Amendment right against self-incrimination.38
>
> However, if you refuse to provide information or assistance upon request, the border agent may seize your device for further inspection or consider you uncooperative, which the agent may take into consideration when deciding whether to allow you to enter the United States.
>
> If you are planning to bring encrypted or password-protected information over the border, it’s best to decide ahead of time how you would respond to a border agent’s request for help to inspect data. The best answer for your particular circumstance may be to cooperate or to politely decline to provide information.

Its important to not be alarmist on the actual threat posed. If you can provide me with cases where people are actually sent to prison that would be an interesting read.
-- 
Jim O'Gorman
jim@offensive-security.com







[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 710 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/14/2014 05:30 AM, Arno Wagner wrote:
> I think that in your scenario, "nuke" does not have any real
> advantages over just not having the passphrase, and that one
> is dangerous.

Well, this idea is not new and I responded very similar months ago.
http://code.google.com/p/cryptsetup/issues/detail?id=110#c1

But seems there is a lot of people in disagreement.

I was quite surprised that most of people from
our university security&crypto lab I met today and asked
(to have some other opinions) said that despite "nuke password"
has very limited use it is worth to have something like that...

Sigh... :)

But what I really want to avoid is that every distribution will
add some random patches implementing something like this.

It is perhaps better to implement and document this upstream.

Anyway, you have to manually create such key.
And cryptsetup never blocked you from shooting yourself in
the foot if you really want.
...

From the pure technical POV (ignoring the use case discussion)
https://raw.github.com/offensive-security/cryptsetup-nuke-keys/master/cryptsetup_1.6.1+nuke_keys.diff

The principle is ok (it should be implemented on libcryptsetup
level, so it works from every GUI extension etc).

But I do not like the details:

- we do not need additional luksAddNuke command, switch like
"--use-slot-destruction-key" option to luksAddKey is enough

- I do not like that special key is all zeroes.
(This is sometimes used for testing etc).

IMHO "nuke key" should be linked to exact header key
(if you copy this keyslot area to another LUKS header it
should not work there).
To be extra paranoid, I think nuke key should be randomized.

This can be done e.g. if nuke key contains some salt, part
of real key fingerprint (from LUKS header) and some magic string.

- I think that "nuke" keyslot should remain active.
(not really sure about this)

Opinions?

Thanks,
Milan

Re: [dm-crypt] nuke password to delete luks header

[Ondrej Kozina]

On 01/15/2014 09:27 PM, Milan Broz wrote:
> On 01/14/2014 05:30 AM, Arno Wagner wrote:
>> I think that in your scenario, "nuke" does not have any real
>> advantages over just not having the passphrase, and that one
>> is dangerous.
>
> Well, this idea is not new and I responded very similar months ago.
> http://code.google.com/p/cryptsetup/issues/detail?id=110#c1
>
> But seems there is a lot of people in disagreement.
>
> I was quite surprised that most of people from
> our university security&crypto lab I met today and asked
> (to have some other opinions) said that despite "nuke password"
> has very limited use it is worth to have something like that...
>
> Sigh... :)

In that case, let me join you with my humble Sigh as well.

> But what I really want to avoid is that every distribution will
> add some random patches implementing something like this.
>
> It is perhaps better to implement and document this upstream.

Ok, I just think that this new feature is quite heavily disputed 
already. This is perhaps third discussion I found on that topic in a few 
minutes of searching. Please, make "nuke password" option configurable 
so that it can be easily removed from any distribution that wouldn't 
agree with arguments for including it.

Best regards
Ondra

Re: [dm-crypt] nuke password to delete luks header

[Thomas Bastiani]

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

Hi guys,

I've been following this discussion for a few days. And I feel like giving
my opinion... :-)

On 16 January 2014 09:50, Ondrej Kozina <okozina@redhat.com> wrote:

> On 01/15/2014 09:27 PM, Milan Broz wrote:
>
>> On 01/14/2014 05:30 AM, Arno Wagner wrote:
>>
>>> I think that in your scenario, "nuke" does not have any real
>>> advantages over just not having the passphrase, and that one
>>> is dangerous.
>>>
>>
>> Well, this idea is not new and I responded very similar months ago.
>> http://code.google.com/p/cryptsetup/issues/detail?id=110#c1
>>
>> But seems there is a lot of people in disagreement.
>>
>> I was quite surprised that most of people from
>> our university security&crypto lab I met today and asked
>> (to have some other opinions) said that despite "nuke password"
>> has very limited use it is worth to have something like that...
>>
>> Sigh... :)
>>
>
> In that case, let me join you with my humble Sigh as well.


Yes, I also tend to agree with Arno's arguments and I feel that there is no
real (non-dangerous) use case for this.


>
>
>  But what I really want to avoid is that every distribution will
>> add some random patches implementing something like this.
>>
>> It is perhaps better to implement and document this upstream.
>>
>
I would argue that it's really independent from any actual crypto logic.
The only thing that need's to be done is wrap the password/key prompt and
check the password against a known salted hash or PBKDF (same as all Linux
distros do). Then "nuking" the container is actually quite simple. Just
erase the LUKS header by zeroing it. This is not any more complex than what
distros already have to do to support root-on-LUKS.

Actually this functionality is simple enough that anyone actually wanting
it can just write their own password prompt wrapper script.

I would point out that this doesn't require any more information from LUKS
internals than mouting a block device from /etc/crypttab would. And so it's
entirely possible to keep the code layered and simple. KISS applies.

Moreover, I think it's wrong to assume that distros don't share any of
their code. Proof is, they fork each other. It wouldn't have to be
implemented a dozen times.


> Ok, I just think that this new feature is quite heavily disputed already.
> This is perhaps third discussion I found on that topic in a few minutes of
> searching. Please, make "nuke password" option configurable so that it can
> be easily removed from any distribution that wouldn't agree with arguments
> for including it.
>
> Best regards
> Ondra
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Just my .02$,
--
Thomas Bastiani

[-- Attachment #2: Type: text/html, Size: 4527 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Florian Junghanns]

On 01/16/2014 11:30 AM, Thomas Bastiani wrote:
> Hi guys,
>
> I've been following this discussion for a few days. And I feel like giving
> my opinion... :-)

Hello everyone,

I'm feeling the same way as Thomas does. Please see below for my 
explanation and proposal.

>
> On 16 January 2014 09:50, Ondrej Kozina <okozina@redhat.com> wrote:
>
>> On 01/15/2014 09:27 PM, Milan Broz wrote:
>>
[...]
>>
>>   But what I really want to avoid is that every distribution will
>>> add some random patches implementing something like this.
>>>
>>> It is perhaps better to implement and document this upstream.
>>>
>>
> I would argue that it's really independent from any actual crypto logic.
> The only thing that need's to be done is wrap the password/key prompt and
> check the password against a known salted hash or PBKDF (same as all Linux
> distros do). Then "nuking" the container is actually quite simple. Just
> erase the LUKS header by zeroing it. This is not any more complex than what
> distros already have to do to support root-on-LUKS.
>
> Actually this functionality is simple enough that anyone actually wanting
> it can just write their own password prompt wrapper script.
>
> I would point out that this doesn't require any more information from LUKS
> internals than mouting a block device from /etc/crypttab would. And so it's
> entirely possible to keep the code layered and simple. KISS applies.
>
> Moreover, I think it's wrong to assume that distros don't share any of
> their code. Proof is, they fork each other. It wouldn't have to be
> implemented a dozen times.
>

It is my opinion as well that this should be solved by external wrappers 
of the Linux distribution used. Also, I do not see how this is a 
different area than e.g. caching the passphrase for mounting multiple 
encrypted volumes on boot, a functionality that is provided e.g. by the 
Debian distribution (not by dm-crypt). The functionality to make the 
LUKS header unusable is provided by the 'dd' command with correct 
parameters. IFF you want to provide the functionality of making the LUKS 
header unusable via dm-crypt, I believe the *addition of a 'force' flag 
to luksHeaderRestore* in order to enable a file that is not a LUKS 
header backup file to be used as source is more sensible, e.g. 
*'cryptsetup luksHeaderRestore /dev/sda1 -f 
--header-backup-file=/dev/zero'*. This is a clear maintenance operation 
which is - in my opinion - a saner solution than adding this very 
unusual 'nuke' functionality. If you're still going to implement it, I 
strongly feel it should be called something like 'destroy' instead of 
'nuke'. Even better would be 'overwrite' or 'disable', since - as 
discussed before - on e.g. SSD drives this does not necessarily 'nuke' 
the header rather than 'displace'/'unlink' it from the former position 
in the block register.

As already indicated above, I feel that this is a maintenance operation. 
Without putting yourself in danger, there are two use cases when you 
will want to 'nuke' your header. The one is before you depart from your 
original location. Then you have your device booted and can use the 
normal system tools ('dd', or - if the -f flag is implemented - 
luksHeaderRestore) to disable the LUKS header. The other situation is 
that you are short on time and cannot manage to boot your device without 
e.g. missing your flight. In that case, you need the option to disable 
the header without actually booting the device. This however is not the 
core functionality and responsibility of dm-crypt but rather of the 
distribution in use which can do this with a wrapper script just like 
Debian does already for caching passphrases.
Any other use case I can think of is - as discussed to some extent in 
the last few days - either stupid or heavily endangering yourself or 
both. It is not the task of dm-crypt to enable people to do such things.

Best regards,
   Florian

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/16/2014 11:30 AM, Thomas Bastiani wrote:

> I would argue that it's really independent from any actual crypto
> logic. The only thing that need's to be done is wrap the password/key
> prompt and check the password against a known salted hash or PBKDF
> (same as all Linux distros do). Then "nuking" the container is
> actually quite simple. Just erase the LUKS header by zeroing it. This
> is not any more complex than what distros already have to do to
> support root-on-LUKS.

Yes, these are perfectly valid arguments.

Another one is just use detached LUKS header on USB flash
which is kept separately.

Another one is to use steganography (either hidden disk or whatever you like).

Another one is to use special distro with customized wrapper scripts.
...

But let's think out of the (engineering) box...

This destroy functionality (btw yes, I do not want to name it "nuke"
either) should be used only in very specific situations and almost
for sure it could create danger situation for you.

But that's your problem to decide if it is worth it.

People (like war journalist) are usually not technical people, they are
trained to handle such risky situations.
Let's assume that they had data which can put them (or others) in more
danger if revealed.

Some crazy situation, please take it as illustrations...

- you can destroy keys before some problematic meeting keeping
notebook in ram suspend. If notebook is later confiscated (and you
managed to switch it off) you can sleep better - there was no key,
no data recovery possible. (If you have separated LUKS on USB,
they will confiscate it with nb as well of course.)

Obviously, they can torture you or just confiscate running nb
and get key from RAM. But still, it could help to secure some
situations. Or not - that's the risk.

It will never protect you from sophisticated attacks but
it can help when someone had a chance to copy your encrypted notebook
when you end up in some unexpected situation (think some strange
hotel when you missed a flight).
You can destroy it as prevention - they cannot be successful in recovery
of nuked disk. And you can recover it from backup later.

- you can destroy key on disk of your colleague if there is a need,
but you have no access to his data (you know only destroy password)

- you can do this for LUKS USB flash in ANY Linux computer,
even from user account (mounting LUKS removal devices is enabled
for user usually, this is enough for this code to work)
[obviously this expects distro maintainers will not disable it :)]

Yes, I know million ways how to destroy it other ways - but these
users are not unix gurus, and entering passwords through any
Linux distro gui is very simple, it can be easily learned and
moreover it is not too suspicious behavior.

And yes, I am playing Devil's advocate now :)

I am afraid there are people who need to do crazy thinks like this sometimes.

I see many situations when using this feature is just utterly stupid
and solves nothing.

But I cannot say that all possible situations comes under this qualification.
Maybe it can help someone in dangerous situation to not leak some important data
which later help others. Dunno.

Still it doesn't mean it is worth to be implemented but let's think
at least twice here please.

Milan

Re: [dm-crypt] nuke password to delete luks header

[helices]

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

This all seems quite simple to me:

As long as there is NO local LUKS header, the disk cannot be decrypted.

So long as the LUKS header remains remote to the encrypted disk, the disk
cannot be decrypted.

If, indeed, you can store and keep the LUKS header remote from the
encrypted disk, what is the difference between this and this toy story
"nuke" functionality?

Furthermore, as long as you can bring the remote LUKS header local to the
encrypted disk, it is practical to decrypt the disk.

This is not a new idea. Prior to the digital world, it has been common to
keep codes and cyphers separate.

What am I missing?


On Thu, Jan 16, 2014 at 1:33 PM, Milan Broz <gmazyland@gmail.com> wrote:

> On 01/16/2014 11:30 AM, Thomas Bastiani wrote:
>
> > I would argue that it's really independent from any actual crypto
> > logic. The only thing that need's to be done is wrap the password/key
> > prompt and check the password against a known salted hash or PBKDF
> > (same as all Linux distros do). Then "nuking" the container is
> > actually quite simple. Just erase the LUKS header by zeroing it. This
> > is not any more complex than what distros already have to do to
> > support root-on-LUKS.
>
> Yes, these are perfectly valid arguments.
>
> Another one is just use detached LUKS header on USB flash
> which is kept separately.
>
> Another one is to use steganography (either hidden disk or whatever you
> like).
>
> Another one is to use special distro with customized wrapper scripts.
> ...
>
> But let's think out of the (engineering) box...
>
> This destroy functionality (btw yes, I do not want to name it "nuke"
> either) should be used only in very specific situations and almost
> for sure it could create danger situation for you.
>
> But that's your problem to decide if it is worth it.
>
> People (like war journalist) are usually not technical people, they are
> trained to handle such risky situations.
> Let's assume that they had data which can put them (or others) in more
> danger if revealed.
>
> Some crazy situation, please take it as illustrations...
>
> - you can destroy keys before some problematic meeting keeping
> notebook in ram suspend. If notebook is later confiscated (and you
> managed to switch it off) you can sleep better - there was no key,
> no data recovery possible. (If you have separated LUKS on USB,
> they will confiscate it with nb as well of course.)
>
> Obviously, they can torture you or just confiscate running nb
> and get key from RAM. But still, it could help to secure some
> situations. Or not - that's the risk.
>
> It will never protect you from sophisticated attacks but
> it can help when someone had a chance to copy your encrypted notebook
> when you end up in some unexpected situation (think some strange
> hotel when you missed a flight).
> You can destroy it as prevention - they cannot be successful in recovery
> of nuked disk. And you can recover it from backup later.
>
> - you can destroy key on disk of your colleague if there is a need,
> but you have no access to his data (you know only destroy password)
>
> - you can do this for LUKS USB flash in ANY Linux computer,
> even from user account (mounting LUKS removal devices is enabled
> for user usually, this is enough for this code to work)
> [obviously this expects distro maintainers will not disable it :)]
>
> Yes, I know million ways how to destroy it other ways - but these
> users are not unix gurus, and entering passwords through any
> Linux distro gui is very simple, it can be easily learned and
> moreover it is not too suspicious behavior.
>
> And yes, I am playing Devil's advocate now :)
>
> I am afraid there are people who need to do crazy thinks like this
> sometimes.
>
> I see many situations when using this feature is just utterly stupid
> and solves nothing.
>
> But I cannot say that all possible situations comes under this
> qualification.
> Maybe it can help someone in dangerous situation to not leak some
> important data
> which later help others. Dunno.
>
> Still it doesn't mean it is worth to be implemented but let's think
> at least twice here please.
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

[-- Attachment #2: Type: text/html, Size: 5142 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Iggy]

I have watched this thread, and other similar ones, with interest for
months.

Now, time to weigh in.

I agree, that the use for this feature is limited.

Also, I agree that it is dangerous.  But so, inherently, is LUKS.  Or
reading your kindle in the bathtub.  People cannot (should not?) be
prevented from doing stupid, dangerous things.

I think there are a few, but real, legitimate uses for this feature.
Yes, for every legitimate use-case, there are other ways to achieve the
same end, but perhaps none so non-technical.

Not everyone who needs to ensure their data does not fall into the wrong
hands is technically savvy.  Relatedly, not everyone values their
physical well-being over the compromise of their data.  To demand
otherwise seems short sighted.

There are many (at least a few) cases where a simple, quick,
innocuous-seeming method to destroy key-slot data will be desirable to
people.  Is it for us to attempt to conceive of every possible use-case,
and then judge it as a Good Idea or a Bad Idea?  I submit, no.

I encourage the (much exalted and appreciated) developers of dm-crypt to
kindly allow users to shoot themselves in the foot, if they so desire.

Furthermore, I agree that plausible deniability regarding hidden volumes
and such is hard, nigh unto impossible.

But, there are many cases when a user might not want to have access to
her data at any given moment, with the possibility to achieve access
again in the future, without restoring GBs of data from backup.  Some of
these scenarios have been mentioned in this thread.  Furthermore, there
are some (fewer) scenarios where quickly removing all potential of
access to the data may be deemed by the user to be the Right Choice,
even if it means significant unpleasant acquaintance with the rubber
hose in the days and months to come.

So, my vote is in favor of adding a (differently-named) "nuke" option.
In particular, one that is quick, can be run on a non-fully-booted
system, and that allows the option of giving a third party the nuke
password, but not the decryption password.  I think (but am not sure)
that these parameters speak to implementing this as an internal dm-crypt
option, based upon a specialized keyslot and it's associated
password/phrase.




Most Sincerely,

-Iggy


PS:  An interesting, but only marginally helpful, byproduct of such a
feature is that on the off-chance that an adversary were attempting to
brute-force the password on their only copy of a volume (this is the
unlikely bit), and the nuke password had less entropy than the
decryption passphrase, then there is a chance the adversary themselves
would remove access to the data, without intervention from the target of
the attack, by accidentally brute-forcing the nuke password.




On 01/16/2014 02:33 PM, Milan Broz wrote:
> On 01/16/2014 11:30 AM, Thomas Bastiani wrote:
> 
>> I would argue that it's really independent from any actual crypto
>> logic. The only thing that need's to be done is wrap the password/key
>> prompt and check the password against a known salted hash or PBKDF
>> (same as all Linux distros do). Then "nuking" the container is
>> actually quite simple. Just erase the LUKS header by zeroing it. This
>> is not any more complex than what distros already have to do to
>> support root-on-LUKS.
> 
> Yes, these are perfectly valid arguments.
> 
> Another one is just use detached LUKS header on USB flash
> which is kept separately.
> 
> Another one is to use steganography (either hidden disk or whatever you like).
> 
> Another one is to use special distro with customized wrapper scripts.
> ...
> 
> But let's think out of the (engineering) box...
> 
> This destroy functionality (btw yes, I do not want to name it "nuke"
> either) should be used only in very specific situations and almost
> for sure it could create danger situation for you.
> 
> But that's your problem to decide if it is worth it.
> 
> People (like war journalist) are usually not technical people, they are
> trained to handle such risky situations.
> Let's assume that they had data which can put them (or others) in more
> danger if revealed.
> 
> Some crazy situation, please take it as illustrations...
> 
> - you can destroy keys before some problematic meeting keeping
> notebook in ram suspend. If notebook is later confiscated (and you
> managed to switch it off) you can sleep better - there was no key,
> no data recovery possible. (If you have separated LUKS on USB,
> they will confiscate it with nb as well of course.)
> 
> Obviously, they can torture you or just confiscate running nb
> and get key from RAM. But still, it could help to secure some
> situations. Or not - that's the risk.
> 
> It will never protect you from sophisticated attacks but
> it can help when someone had a chance to copy your encrypted notebook
> when you end up in some unexpected situation (think some strange
> hotel when you missed a flight).
> You can destroy it as prevention - they cannot be successful in recovery
> of nuked disk. And you can recover it from backup later.
> 
> - you can destroy key on disk of your colleague if there is a need,
> but you have no access to his data (you know only destroy password)
> 
> - you can do this for LUKS USB flash in ANY Linux computer,
> even from user account (mounting LUKS removal devices is enabled
> for user usually, this is enough for this code to work)
> [obviously this expects distro maintainers will not disable it :)]
> 
> Yes, I know million ways how to destroy it other ways - but these
> users are not unix gurus, and entering passwords through any
> Linux distro gui is very simple, it can be easily learned and
> moreover it is not too suspicious behavior.
> 
> And yes, I am playing Devil's advocate now :)
> 
> I am afraid there are people who need to do crazy thinks like this sometimes.
> 
> I see many situations when using this feature is just utterly stupid
> and solves nothing.
> 
> But I cannot say that all possible situations comes under this qualification.
> Maybe it can help someone in dangerous situation to not leak some important data
> which later help others. Dunno.
> 
> Still it doesn't mean it is worth to be implemented but let's think
> at least twice here please.
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] nuke password to delete luks header

[Matthias Schniedermeyer]

On 16.01.2014 15:11, Iggy wrote:
> 
> 
> PS:  An interesting, but only marginally helpful, byproduct of such a
> feature is that on the off-chance that an adversary were attempting to
> brute-force the password on their only copy of a volume (this is the
> unlikely bit), and the nuke password had less entropy than the
> decryption passphrase, then there is a chance the adversary themselves
> would remove access to the data, without intervention from the target of
> the attack, by accidentally brute-forcing the nuke password.

You wouldn't brute force using the actual system, much too slow.

You make a copy and brute force the data with something that allows as 
much key/s as possible. Which means you can't use the actual system. 
That also means the system that is actually used to do the brute-forcing 
won't implement the "nuke" capability (Assuming at least some competence 
on the attacker side) but may include code determine that it is a nuke 
key, because there has to be a way to identify that status at least 
after you found the correct passwort. Otherwise the feature would simply 
be impossible to implement.




-- 

Matthias

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Thu, Jan 16, 2014 at 22:36:19 CET, Matthias Schniedermeyer wrote:
> On 16.01.2014 15:11, Iggy wrote:
> > 
> > 
> > PS:  An interesting, but only marginally helpful, byproduct of such a
> > feature is that on the off-chance that an adversary were attempting to
> > brute-force the password on their only copy of a volume (this is the
> > unlikely bit), and the nuke password had less entropy than the
> > decryption passphrase, then there is a chance the adversary themselves
> > would remove access to the data, without intervention from the target of
> > the attack, by accidentally brute-forcing the nuke password.
> 
> You wouldn't brute force using the actual system, much too slow.

The other thing is that the first thing drilled into any IT
forensics worker is to never work on the originals. So only
a terminally incompetent attacker would do this.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Claudio Moretti]

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

>
> Ok, here is one proposal:
>
> Lets split this discussion. I think this simplifies things.
>
> 1. Have a secure erase that is easy to use. This will
>    help anybody that is not a technical person but
>    needs to securely get rid of a luks header fast when
>    still free to act as thay chose.
>    This can just be a key-slot kill for all slots or the like.
>    It can also be a full header erase.
>    Maybe "cryptsetup luksEraseAll" or something like it
>    and requiring a "YES" like luksFormat.
>
> [snip]
>
>
I think having 1. generally is good, as it is a dedicated operation
> that really does only one thing and does it well, namely making
> the LUKS container irrecoverable while the user is still free to
> act as they chose. The journalist from the example would only need
> to memorize this one command ad an emergency "red button".
>

I agree. Also, the same journalist could create an alias (say alias
EMERGENCY="/sbin/cryptsetup luksEraseAll /dev/sda"), set a NOPASSWD option
ini /etc/sudoers (if he's using sudo) and have a

$ sudo EMERGENCY

that triggers (1).

Even faster, and pretty useful to him


> 2. Have the option of unlocking a keyslot created with a specific
>    option to trigger the function implemented in 1.
>

>
[snip]


>
 For 2. all the pros and cons apply though. I would at the very
>
least make its presence a compile-time option and put very strong
> warnings that this is dangerous in the documentation. It may still
> be desirable to not have 2. at all (I think it is so, as it does more
> harm than good), as it really is only something useful when already
> not free to act or under close superwision of what command one types.
> And that is a situation that is highly problematic and we cannot even
> come close to help the user mastering this situation.
>

While it's actually not a "command", that a person is typing, but just a
password, a question comes to mind:
Once you get to the password prompt, it's clear you have an encrypted disk.
So, unless you're really, really, really in trouble you'd never use the
"wipe" password.
Three cases come to mind:
1) you have something really, really illegal on your HD and you get stopped
at a security checkpoint. In this case, (a) you're an idiot who took that
kind of stuff on a laptop instead of having a clean laptop and retrieving
it via a secure connection and (b) even if you wipe your hard drive you're
in big trouble, because they'll know you did it.
2) Your life is in danger and somebody wants something from your laptop:
what do you think will happen then, if you wipe your key?

The only real time you're going to need such functionality is if you have
data on your computer, you know someone's coming and your computer is
turned _off_: you have very little time, so you just boot, type in the wipe
password and unplug.

In this case, though, it's not enough wiping the keyslots: you'd have to
wipe the entire header, because otherwise the only thing that "someone"
will see is you not giving them the correct password.


>
> As tool-makers we have a responsibility to balance functionality
> and risks as we understand the tool better than most of the users.
> Of course, the user may understand the situation he finds himself
> in better than we do (or not), but that is why it is a balance.
> Neither "deny everything even a bit riksy" nor "allow everything"
> is morally right for a tool that is mainly used by non-experts.
>

I believe that the best course of action in this case would be to implement
it as "highly experimental not guaranteed[1]" with a (or a couple of)
compile flag, but at least we can give the users a choice. And, with a
compile flag, very few people are going to be able to put that in place.

I must admit I did not read the 60+ emails in the whole discussion, so I
might have repeated something someone had already said.
If so, please disregard it :)

Cheers,

Claudio

[1] Not guaranteed because of the issues with SSDs.

[-- Attachment #2: Type: text/html, Size: 5838 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Thomas Bastiani]

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

On 16 January 2014 22:49, Claudio Moretti <flyingstar16@gmail.com> wrote:
>
> While it's actually not a "command", that a person is typing, but just a
> password, a question comes to mind:
> Once you get to the password prompt, it's clear you have an encrypted
> disk. So, unless you're really, really, really in trouble you'd never use
> the "wipe" password.
> Three cases come to mind:
> 1) you have something really, really illegal on your HD and you get
> stopped at a security checkpoint. In this case, (a) you're an idiot who
> took that kind of stuff on a laptop instead of having a clean laptop and
> retrieving it via a secure connection and (b) even if you wipe your hard
> drive you're in big trouble, because they'll know you did it.
>

Agreed.


>  2) Your life is in danger and somebody wants something from your laptop:
> what do you think will happen then, if you wipe your key?
>

I believe Iggy made a point earlier:
" [...] not everyone values their physical well-being over the compromise
of their data."

Which is a surprisingly (to me) valid point. There might be cases where
someone might actually want to protect something at the cost of their life.


> The only real time you're going to need such functionality is if you have
> data on your computer, you know someone's coming and your computer is
> turned _off_: you have very little time, so you just boot, type in the wipe
> password and unplug.
>

The way I use LUKS is that I've got a passworded rsa certificate that I use
to encrypt my key. Both files (encrypted LUKS key and passworded
certificate) are then stored on my boot partition on a USB dongle in my
pocket. If I wanted to prevent someone from accessing my LUKS partition(s),
I'd simply wipe those files. Or, worst case, repeatedly smash the dongle
with a hammer. The point is that I can't give access to my LUKS protected
data anymore, which is the point of  the "nuke" feature. My point here is
that if you use a key instead of a password, and thus can't give access to
the required data from memory, it's easy enough to delete the key. Also,
erasing a file from a FAT formatted USB dongle should be more secure than
erasing the header from an SSD. I might be wrong but I believe that current
USB keys don't have fancy wear-leveling and storage overprovision that
modern SSDs do.


> In this case, though, it's not enough wiping the keyslots: you'd have to
> wipe the entire header, because otherwise the only thing that "someone"
> will see is you not giving them the correct password.
>

You can't prove that you don't have a separate header backup.

>
> As tool-makers we have a responsibility to balance functionality
>> and risks as we understand the tool better than most of the users.
>> Of course, the user may understand the situation he finds himself
>> in better than we do (or not), but that is why it is a balance.
>> Neither "deny everything even a bit riksy" nor "allow everything"
>> is morally right for a tool that is mainly used by non-experts.
>>
>
> I believe that the best course of action in this case would be to
> implement it as "highly experimental not guaranteed[1]" with a (or a couple
> of) compile flag, but at least we can give the users a choice. And, with a
> compile flag, very few people are going to be able to put that in place.
>

What if the <insert popular user-friendly distro name> package maintainer
decides it's a cool feature?

--
Thomas Bastiani

[-- Attachment #2: Type: text/html, Size: 6010 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Claudio Moretti]

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

On Fri, Jan 17, 2014 at 8:17 AM, Thomas Bastiani <thom@codehawks.eu> wrote:

> On 16 January 2014 22:49, Claudio Moretti <flyingstar16@gmail.com> wrote:
>>
>>  2) Your life is in danger and somebody wants something from your
>> laptop: what do you think will happen then, if you wipe your key?
>>
>
> I believe Iggy made a point earlier:
> " [...] not everyone values their physical well-being over the compromise
> of their data."
>
> Which is a surprisingly (to me) valid point. There might be cases where
> someone might actually want to protect something at the cost of their life.
>

I hadn't thought about that, but now that you mention it I've given it a
little thought and I agree. Suppose you're a police officer, you're
carrying an encrypted laptop with thousands of names of people in a witness
protection program, and you're captured by the mob.

Without diving into further examples concerning the safety of the people
someone holds most dear, I believe this is the perfect example.


>
>
>> The only real time you're going to need such functionality is if you have
>> data on your computer, you know someone's coming and your computer is
>> turned _off_: you have very little time, so you just boot, type in the wipe
>> password and unplug.
>>
>
> The way I use LUKS is that I've got a passworded rsa certificate that I
> use to encrypt my key. Both files (encrypted LUKS key and passworded
> certificate) are then stored on my boot partition on a USB dongle in my
> pocket. If I wanted to prevent someone from accessing my LUKS partition(s),
> I'd simply wipe those files. Or, worst case, repeatedly smash the dongle
> with a hammer. The point is that I can't give access to my LUKS protected
> data anymore, which is the point of  the "nuke" feature. My point here is
> that if you use a key instead of a password, and thus can't give access to
> the required data from memory, it's easy enough to delete the key. Also,
> erasing a file from a FAT formatted USB dongle should be more secure than
> erasing the header from an SSD. I might be wrong but I believe that current
> USB keys don't have fancy wear-leveling and storage overprovision that
> modern SSDs do.
>

That's not how I do it, but only because I'm lazy and tend to forget
everything, everywhere.
Also, I have a friend who does that, and I clearly remember about the time
he forgot his USB key home :P

But, anyway, that's the best way to do it: there's no header, no nothing on
the drive that might give away the fact that you have an encrypted
partition.

Even though "You can't prove that you don't have a separate header backup."
:)


>
>> In this case, though, it's not enough wiping the keyslots: you'd have to
>> wipe the entire header, because otherwise the only thing that "someone"
>> will see is you not giving them the correct password.
>>
>
> You can't prove that you don't have a separate header backup.
>

You're right, but remember that when someone tries to turn on your wiped
computer, the computer will give a "disk error/no boot partition
available/root partition not found/etc." error. You can claim ignorance ;)
Also, forensic analysis will be useless, because there's nothing to be
found, whereas if they're able to "dd" your disk, they can try as many
times as they want, and if a judge orders you to surrender the password (I
don't know if it's legal in some countries, I'm just saying) if you just
wiped the keyslots you can't actually prove it: the only thing anyone will
see will be "there is no key available with this passphrase"; and if you
actually tell them "I have wiped my LUKS slots before you showed up", they
can say "we don't believe you", and you have no way of proving you're not
lying :/


>
>> As tool-makers we have a responsibility to balance functionality
>>> and risks as we understand the tool better than most of the users.
>>> Of course, the user may understand the situation he finds himself
>>> in better than we do (or not), but that is why it is a balance.
>>> Neither "deny everything even a bit riksy" nor "allow everything"
>>> is morally right for a tool that is mainly used by non-experts.
>>>
>>
>> I believe that the best course of action in this case would be to
>> implement it as "highly experimental not guaranteed[1]" with a (or a couple
>> of) compile flag, but at least we can give the users a choice. And, with a
>> compile flag, very few people are going to be able to put that in place.
>>
>
> What if the <insert popular user-friendly distro name> package maintainer
> decides it's a cool feature?
>

I actually thought about this, before adding that paragraph, but IMHO it's
not our concern. If the functionality ever gets added, how long will it
take to be able to find DEBs and RPMs in various personal repos, that have
the functionality enabled? IMHO a really short time. It's not only a
maintainer issue.

Nevertheless, I believe it should be the user's choice. Anyone can achieve
similar results with a
# dd if=/dev/urandom of=/dev/sda
so maybe yeah, my "sudo EMERGENCY" idea could do that instead, but with the
header wipe we won't touch the actual data so if you do have a hedaer
backup...

It's a really tricky topic, and everyone's opinion is slightly different;
that's one of the reasons I believe it should be the user who decides.
There is no way of warning users about the possible legal/real implications
of this (aside from data loss) and I expect somebody someday to come in
here and say "hey, my cat was on my keyboard and typed 'sudo cryptsetup
luksWipe /dev/sda'! How do I get my data back?", but I also believe that
people who have to really protect themselves already have a custom made
patched version of cryptsetup that does that...

Claudio

[-- Attachment #2: Type: text/html, Size: 9280 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Sat, Jan 18, 2014 at 00:18:27 CET, Claudio Moretti wrote:
> On Fri, Jan 17, 2014 at 8:17 AM, Thomas Bastiani <thom@codehawks.eu> wrote:
> 
> > On 16 January 2014 22:49, Claudio Moretti <flyingstar16@gmail.com> wrote:
> >>
> >>  2) Your life is in danger and somebody wants something from your
> >> laptop: what do you think will happen then, if you wipe your key?
> >>
> >
> > I believe Iggy made a point earlier:
> > " [...] not everyone values their physical well-being over the compromise
> > of their data."
> >
> > Which is a surprisingly (to me) valid point. There might be cases where
> > someone might actually want to protect something at the cost of their life.
> >
> 
> I hadn't thought about that, but now that you mention it I've given it a
> little thought and I agree. Suppose you're a police officer, you're
> carrying an encrypted laptop with thousands of names of people in a witness
> protection program, and you're captured by the mob.

The mob has IT security experts and will not allow this person to
trick them. 
 
> Without diving into further examples concerning the safety of the people
> someone holds most dear, I believe this is the perfect example.

For my option 1. "erase container while still free to act" it is
a valid example. For option 2. "try to trick adversaries while 
already in their power", it is just as bad as all the others.

Arno
 
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Claudio Moretti]

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

On Sat, Jan 18, 2014 at 8:43 AM, Arno Wagner <arno@wagner.name> wrote:

> The mob has IT security experts and will not allow this person to
> trick them.
>
>
Fair enough


>  > Without diving into further examples concerning the safety of the people
> > someone holds most dear, I believe this is the perfect example.
>
> For my option 1. "erase container while still free to act" it is
> a valid example. For option 2. "try to trick adversaries while
> already in their power", it is just as bad as all the others.
>

 "try to trick" is the keyword here, and we can circle back to something
you said (more or less) before: is there any case in which trying to trick
someone is going to give you any benefits?

I suppose for every specific case there is a possible counter-response (see
my mob example and your answer). Still, real life is not so black and
white, so maybe it could be possible to trick someone.. But here it all
depends by the person trying to trick (and his or her skills in lying) so...

Claudio

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Sat, Jan 18, 2014 at 13:42:10 CET, Claudio Moretti wrote:
> On Sat, Jan 18, 2014 at 8:43 AM, Arno Wagner <arno@wagner.name> wrote:
> 
> > The mob has IT security experts and will not allow this person to
> > trick them.
> >
> >
> Fair enough
> 
> 
> >  > Without diving into further examples concerning the safety of the people
> > > someone holds most dear, I believe this is the perfect example.
> >
> > For my option 1. "erase container while still free to act" it is
> > a valid example. For option 2. "try to trick adversaries while
> > already in their power", it is just as bad as all the others.
> >
> 
>  "try to trick" is the keyword here, and we can circle back to something
> you said (more or less) before: is there any case in which trying to trick
> someone is going to give you any benefits?
> 
> I suppose for every specific case there is a possible counter-response (see
> my mob example and your answer). Still, real life is not so black and
> white, so maybe it could be possible to trick someone.. But here it all
> depends by the person trying to trick (and his or her skills in lying) so...

Just my point. It depends on personal skill far more than on 
technical thing and not everybody is "The Mentalist" and can
trick people easily.

The other thing is that in cases where you have a good chance of
pulling it off, "I forgot it" or "I don't know" may work just as 
well as trying a technical trick, but the risks of the technical
trick are far far worse. If they are about to torture you, on the
other hand, they will also make that forensic copy and the "nuke"
option is worthless. Really, "nuke" only helps if they are willing 
to put so much pressure on you that you fear you cannot refuse 
giving the password (whether directly, or by "I do not know it")
but on the other hand, they are incompetent enough to not make
that forensic copy. 

I really do not see this combination happen with any relevant 
probability, except maybe in a war area or the like. But that 
is something we should definitely place out of scope for LUKS. 
In such cases password and data should travel two distinct 
paths and should not travel at the same time.

Incidentally, for very high value data, that method is used
in peace-time as well, namely have one group take that 
encrypted data and have a second group take the password and 
do not have both out of a protected environment at the same 
time. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Matthias Schniedermeyer]

On 16.01.2014 20:33, Milan Broz wrote:
> 
> But I cannot say that all possible situations comes under this qualification.
> Maybe it can help someone in dangerous situation to not leak some important data
> which later help others. Dunno.
> 
> Still it doesn't mean it is worth to be implemented but let's think
> at least twice here please.

Meanwhile increasing the risk of everybody else, because once that 
feature is a documented part of the system everybody will assume that 
everybody will use it. Good look defending against a "Destruction of 
Evidence" accusation, in case that happens in a situation with a LEO.

Same as the hidden volume "feature" of Truecypt which everybody will 
assume you use, because it's such a swell feature. (Plausible 
deniabilty? Yeah sure <snort>)


In short:
The documented existence of such a feature is a risk by itself.



-- 

Matthias

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

if this feature is implemented as proposed.Can somebody tell a LUKS volume
has a "kill switch" simply by looking at the LUKS header?

do destroyed key slots leaves traces of their destruction? ie,can a person
know a slot was once used simply by looking at the LUKS header?

if this feature is implemented as proposed, can somebody "sneak in" a "kill
switch" by modifying a used/unused slot manually?

[-- Attachment #2: Type: text/html, Size: 678 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Brian]

I'd suppose the guarantees of [nuke] become weaker on SSD which is a common storage media at this point; especially for the mobile use-cases. 

Very interesting thread. 


> On Jan 16, 2014, at 12:28, ".. ink .." <mhogomchungu@gmail.com> wrote:
> 
> 
> if this feature is implemented as proposed.Can somebody tell a LUKS volume has a "kill switch" simply by looking at the LUKS header?
> 
> do destroyed key slots leaves traces of their destruction? ie,can a person know a slot was once used simply by looking at the LUKS header?
> 
> if this feature is implemented as proposed, can somebody "sneak in" a "kill switch" by modifying a used/unused slot manually?
> 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

Difficult to answer in general. On a magnetic disk, it could
be implemented in a way that the header and _any_ of its
features are impossible to recover and the only thing left
is an indicator of encrypted data. On a hubrid disk or SSD,
it gets far more murky. The "sneak in" depends on the 
implementation. If it is an additional flag (bad, as this
would require modification of the ehader), then yes. 
If decryption yields a modified master key or some special 
value derived from the master key, then no. 

Arno

On Thu, Jan 16, 2014 at 21:28:55 CET, .. ink .. wrote:
> if this feature is implemented as proposed.Can somebody tell a LUKS volume
> has a "kill switch" simply by looking at the LUKS header?
> 
> do destroyed key slots leaves traces of their destruction? ie,can a person
> know a slot was once used simply by looking at the LUKS header?
> 
> if this feature is implemented as proposed, can somebody "sneak in" a "kill
> switch" by modifying a used/unused slot manually?

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/16/2014 09:18 PM, Matthias Schniedermeyer wrote:
> On 16.01.2014 20:33, Milan Broz wrote:
>>
>> But I cannot say that all possible situations comes under this qualification.
>> Maybe it can help someone in dangerous situation to not leak some important data
>> which later help others. Dunno.
>>
>> Still it doesn't mean it is worth to be implemented but let's think
>> at least twice here please.
> 
> Meanwhile increasing the risk of everybody else, because once that 
> feature is a documented part of the system everybody will assume that 
> everybody will use it. Good look defending against a "Destruction of 
> Evidence" accusation, in case that happens in a situation with a LEO.
> 
> Same as the hidden volume "feature" of Truecypt which everybody will 
> assume you use, because it's such a swell feature. (Plausible 
> deniabilty? Yeah sure <snort>)
> 
> 
> In short:
> The documented existence of such a feature is a risk by itself.

Hm. I do not think TrueCrypt hidden disk and this feature can be compared
this way.

For TrueCrypt, yes, you cannot prove that random noise is not a hidden disk.
So it can be assumed there is one.

But LUKS keyslot are clearly marked as used / unused.
If all slots are unused, the disk key is gone. (You can do this
today easily with luksKillSlot already.)

If some slot is used - it is up to you to provide proper password or
destruction one when requested. In one situation you reveal the data
(and possible nuke password is then irrelevant) in the second case you
just deleted all slots and revealed you had a destruction password.

And not providing any password will have the same effect as before IMHO.

Perhaps missing something, too late here :)

Milan

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

Ok, here is one proposal:

Lets split this discussion. I think this simplifies things.

1. Have a secure erase that is easy to use. This will
   help anybody that is not a technical person but 
   needs to securely get rid of a luks header fast when
   still free to act as thay chose.
   This can just be a key-slot kill for all slots or the like.
   It can also be a full header erase.
   Maybe "cryptsetup luksEraseAll" or something like it 
   and requiring a "YES" like luksFormat.

2. Have the option of unlocking a keyslot created with a specific
   option to trigger the function implemented in 1. 
   
I think having 1. generally is good, as it is a dedicated operation
that really does only one thing and does it well, namely making
the LUKS container irrecoverable while the user is still free to 
act as they chose. The journalist from the example would only need 
to memorize this one command ad an emergency "red button". 

For 2. all the pros and cons apply though. I would at the very 
least make its presence a compile-time option and put very strong
warnings that this is dangerous in the documentation. It may still 
be desirable to not have 2. at all (I think it is so, as it does more
harm than good), as it really is only something useful when already
not free to act or under close superwision of what command one types. 
And that is a situation that is highly problematic and we cannot even 
come close to help the user mastering this situation. 

As tool-makers we have a responsibility to balance functionality 
and risks as we understand the tool better than most of the users. 
Of course, the user may understand the situation he finds himself 
in better than we do (or not), but that is why it is a balance. 
Neither "deny everything even a bit riksy" nor "allow everything" 
is morally right for a tool that is mainly used by non-experts.

But please, keep the discussion going by any means, especially
for cases where my function 2. is needed when 1. is already 
available. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Jonas Meurer]

Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
> On 16.01.2014 20:33, Milan Broz wrote:
>>
>> But I cannot say that all possible situations comes under this qualification.
>> Maybe it can help someone in dangerous situation to not leak some important data
>> which later help others. Dunno.
>>
>> Still it doesn't mean it is worth to be implemented but let's think
>> at least twice here please.
> 
> Meanwhile increasing the risk of everybody else, because once that 
> feature is a documented part of the system everybody will assume that 
> everybody will use it. Good look defending against a "Destruction of 
> Evidence" accusation, in case that happens in a situation with a LEO.
> 
> Same as the hidden volume "feature" of Truecypt which everybody will 
> assume you use, because it's such a swell feature. (Plausible 
> deniabilty? Yeah sure <snort>)
> 
> 
> In short:
> The documented existence of such a feature is a risk by itself.

Same logic applied, even the existence of this discussion is a risk by
itself. It proves that people might use a patched cryptsetup with added
nuke feature already.

Kind regards,
 jonas

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
> > On 16.01.2014 20:33, Milan Broz wrote:
> >>
> >> But I cannot say that all possible situations comes under this qualification.
> >> Maybe it can help someone in dangerous situation to not leak some important data
> >> which later help others. Dunno.
> >>
> >> Still it doesn't mean it is worth to be implemented but let's think
> >> at least twice here please.
> > 
> > Meanwhile increasing the risk of everybody else, because once that 
> > feature is a documented part of the system everybody will assume that 
> > everybody will use it. Good look defending against a "Destruction of 
> > Evidence" accusation, in case that happens in a situation with a LEO.
> > 
> > Same as the hidden volume "feature" of Truecypt which everybody will 
> > assume you use, because it's such a swell feature. (Plausible 
> > deniabilty? Yeah sure <snort>)
> > 
> > 
> > In short:
> > The documented existence of such a feature is a risk by itself.
> 
> Same logic applied, even the existence of this discussion is a risk by
> itself. It proves that people might use a patched cryptsetup with added
> nuke feature already.
> 
> Kind regards,
>  jonas

Yes, it is. That is one of the reasons why I strongly recommend 
not taking ecrypted data into danger at all and making sure all
unused space on storage media is zeroed.

However, the risk gets more serious if it is a standard feature.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Jonas Meurer]

Am 17.01.2014 14:12, schrieb Arno Wagner:
> On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
>> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
>>> Meanwhile increasing the risk of everybody else, because once that 
>>> feature is a documented part of the system everybody will assume that 
>>> everybody will use it. Good look defending against a "Destruction of 
>>> Evidence" accusation, in case that happens in a situation with a LEO.
>>> [...]
>>> In short:
>>> The documented existence of such a feature is a risk by itself.
>>
>> Same logic applied, even the existence of this discussion is a risk by
>> itself. It proves that people might use a patched cryptsetup with added
>> nuke feature already.
> 
> Yes, it is. That is one of the reasons why I strongly recommend 
> not taking ecrypted data into danger at all and making sure all
> unused space on storage media is zeroed.

While in general I agree to your suggestion, Matthias' point rather
seems like a non-argument to me.

I agree that one should consider possible negative implications of wrong
usage of the feature in question. But I don't agree that the risk
created by "documented existance of such a feature" is an argument
against implementing it. Same logic applied again, we should stop
shipping crypto software in distributions at all just because in some
countries it might bring you into trouble, right?

Kind regards,
 jonas

Re: [dm-crypt] nuke password to delete luks header

[Matthias Schniedermeyer]

On 17.01.2014 15:27, Jonas Meurer wrote:
> Am 17.01.2014 14:12, schrieb Arno Wagner:
> > On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
> >> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
> >>> Meanwhile increasing the risk of everybody else, because once that 
> >>> feature is a documented part of the system everybody will assume that 
> >>> everybody will use it. Good look defending against a "Destruction of 
> >>> Evidence" accusation, in case that happens in a situation with a LEO.
> >>> [...]
> >>> In short:
> >>> The documented existence of such a feature is a risk by itself.
> >>
> >> Same logic applied, even the existence of this discussion is a risk by
> >> itself. It proves that people might use a patched cryptsetup with added
> >> nuke feature already.
> > 
> > Yes, it is. That is one of the reasons why I strongly recommend 
> > not taking ecrypted data into danger at all and making sure all
> > unused space on storage media is zeroed.
> 
> While in general I agree to your suggestion, Matthias' point rather
> seems like a non-argument to me.
> 
> I agree that one should consider possible negative implications of wrong
> usage of the feature in question. But I don't agree that the risk
> created by "documented existance of such a feature" is an argument
> against implementing it.

There is a difference, it is relativly easy to prove you don't have 
anything encrypted(*), but it's hard to prove you didn't use a 
documented part of the encryption software you are using.

So, the mere existance of encryption software doesn't increase the risk 
of people not using encryption software as there is a "provability" of 
not using encryption. The same "provability" is NOT given in the case of 
"nuking" or e.g. the "Hidden Volumes"-Feature of Truecrypt.



*: Ignoring Steganography

-- 

Matthias

Re: [dm-crypt] nuke password to delete luks header

[Rick Moritz]

While I haven't followed each and every post in this thread, I do feel like there is still some confusion about what dm-crypt does, and what it does not do.
I do suppose, that with the explanations given in the previous messages, things are a bit clearer, but I would like to incite a little further development of the FAQ, extending it by something of a mission statement, and reference use cases.
This makes it easier to make design choices, defend existing design choices and educate new and old users to the purpose of dm-crypt, while making clear that other uses are not supported. Some of the unsupported use cases could also be listed, to avoid repeat threads reagarding physical access, border controls and such. Education is clearly just as important, as is the actual code of dm-crypt, and should therefore be/remain a priority, in my opinion.

Just to give a better idea of what I have in mind, I will outline the three use cases/attack scenarios that I see, where an encrypted block device provides strong security:
1) Theft of a properly shut down computer, or of a computer where the encrypted block device has not been opened at the time of theft, or of an encrypted storage device.
2) A single interception of encrypted block devices in physical transit
3) Computer/drive repairs by third parties, resale of encrypted drives without santiation.

IIRC, the FAQ already outlines some scenarios, where security is compromised (physical access to a machine, remote access if the system is suitably vulnerable, duress due to suspicion, social engineering), but they should be added in proximity of these supported scenarios.
This should make the design considerations and real world limitations more clear, and in the future most issues that arise from threads like this can be streamlined, by having them dealt with in the FAQ.
BTW, the case that sparked the initial discussion, where surrendering the laptop is sufficient to freely continue into the destination country is clearly a case of scenarios 1 and 2, and does not fall under the duress rule, and is therefore a supported use case. It requires no nuking functionality (and if you really want to get fancy, you carry the LUKS header on a micro SIM someplace hidden - physical security trumps data security) and just works.

If this is too heavy for the FAQ - it should be a brief document after all - maybe the first question in the FAQ should be "So why would I want to use encryption anyway?" with the usual warning about lost data and unsuitability to purpose in the answer, and a link to an external document that delves deeper into the real world motivations.

I would say that in general that the practical considerations are a bit far down in the FAQ, which already is a bit large. Section 5 should maybe in total be moved to a separate document, more in the style of a "read-me-first", than a classical FAQ. While some technical aspects (hashes, fips, xts, plain) have their place in a FAQ style document, others require explanations that in my experience go beyond the scale of what the FAQ should (and can reasonably) provide. With a link to the secondary document, there should also be no worry about being able to find it via Google.

...Maybe this consideration should be in a separate thread, but this thread made me realize this shortcoming and the now 27 messages in the thread kept it on my mind ;)

Best,

Rick


On Fri, 17 Jan 2014 14:12:09 +0100 Arno Wagner <arno@wagner.name> wrote:

> On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
> > Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
> > > On 16.01.2014 20:33, Milan Broz wrote:
> > >>
> > >> But I cannot say that all possible situations comes under this qualification.
> > >> Maybe it can help someone in dangerous situation to not leak some important data
> > >> which later help others. Dunno.
> > >>
> > >> Still it doesn't mean it is worth to be implemented but let's think
> > >> at least twice here please.
> > > 
> > > Meanwhile increasing the risk of everybody else, because once that 
> > > feature is a documented part of the system everybody will assume that 
> > > everybody will use it. Good look defending against a "Destruction of 
> > > Evidence" accusation, in case that happens in a situation with a LEO.
> > > 
> > > Same as the hidden volume "feature" of Truecypt which everybody will 
> > > assume you use, because it's such a swell feature. (Plausible 
> > > deniabilty? Yeah sure <snort>)
> > > 
> > > 
> > > In short:
> > > The documented existence of such a feature is a risk by itself.
> > 
> > Same logic applied, even the existence of this discussion is a risk by
> > itself. It proves that people might use a patched cryptsetup with added
> > nuke feature already.
> > 
> > Kind regards,
> >  jonas
> 
> Yes, it is. That is one of the reasons why I strongly recommend 
> not taking ecrypted data into danger at all and making sure all
> unused space on storage media is zeroed.
> 
> However, the risk gets more serious if it is a standard feature.
> 
> Arno

Re: [dm-crypt] nuke password to delete luks header

[Jonas Meurer]

Am 17.01.2014 14:12, schrieb Arno Wagner:
> On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
>> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
>>> Meanwhile increasing the risk of everybody else, because once that 
>>> feature is a documented part of the system everybody will assume that 
>>> everybody will use it. Good look defending against a "Destruction of 
>>> Evidence" accusation, in case that happens in a situation with a LEO.
>>> [...]
>>> In short:
>>> The documented existence of such a feature is a risk by itself.
>>
>> Same logic applied, even the existence of this discussion is a risk by
>> itself. It proves that people might use a patched cryptsetup with added
>> nuke feature already.
> 
> Yes, it is. That is one of the reasons why I strongly recommend 
> not taking ecrypted data into danger at all and making sure all
> unused space on storage media is zeroed.

While in general I agree to your suggestion, Matthias' point rather
seems like a non-argument to me.

I agree that one should consider possible negative implications of wrong
usage of the feature in question. But I don't agree that the risk
created by "documented existance of such a feature" is an argument
against implementing it. Same logic applied again, we should stop
shipping crypto software in distributions at all just because in some
countries it might bring you into trouble, right?

Kind regards,
 jonas

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Fri, Jan 17, 2014 at 15:32:20 CET, Jonas Meurer wrote:
> Am 17.01.2014 14:12, schrieb Arno Wagner:
> > On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
> >> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
> >>> Meanwhile increasing the risk of everybody else, because once that 
> >>> feature is a documented part of the system everybody will assume that 
> >>> everybody will use it. Good look defending against a "Destruction of 
> >>> Evidence" accusation, in case that happens in a situation with a LEO.
> >>> [...]
> >>> In short:
> >>> The documented existence of such a feature is a risk by itself.
> >>
> >> Same logic applied, even the existence of this discussion is a risk by
> >> itself. It proves that people might use a patched cryptsetup with added
> >> nuke feature already.
> > 
> > Yes, it is. That is one of the reasons why I strongly recommend 
> > not taking ecrypted data into danger at all and making sure all
> > unused space on storage media is zeroed.
> 
> While in general I agree to your suggestion, Matthias' point rather
> seems like a non-argument to me.
> 
> I agree that one should consider possible negative implications of wrong
> usage of the feature in question. But I don't agree that the risk
> created by "documented existance of such a feature" is an argument
> against implementing it. Same logic applied again, we should stop
> shipping crypto software in distributions at all just because in some
> countries it might bring you into trouble, right?
> 
> Kind regards,
>  jonas

I agree. We should not stop discussing these things, because the
negative impact of doing so is far worse than the risk. But 
implementing a feature is different from discussiong it.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Heiko Rosemann]

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

On 01/17/2014 02:12 PM, Arno Wagner wrote:
> On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
>> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
>>> In short: The documented existence of such a feature is a risk
>>> by itself.
>> 
>> Same logic applied, even the existence of this discussion is a
>> risk by itself. It proves that people might use a patched
>> cryptsetup with added nuke feature already.
>> 
>> Kind regards, jonas
> 
> Yes, it is. That is one of the reasons why I strongly recommend not
> taking ecrypted data into danger at all and making sure all unused
> space on storage media is zeroed.

...which could, by the same logic applied earlier, make the LEO at the
border suspicious of you having destroyed evidence. Unless you provide
a proof of purchase, showing that the hard-drive is in fact new and
therefore still factory-zeroed.

This train of thought goes some very ugly ways very quickly, and
probably boils down to: Social problems can't be solved by technology.

Just my 2 cents,
Heiko
- -- 
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEUEARECAAYFAlLZQ2AACgkQ/Vb5NagElAWsHgCgqnwGDuagmZXMG5Ej6L3mDIpg
n5sAlj/brCK9og9w10oypThJisAVNaY=
=eHzo
-----END PGP SIGNATURE-----

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Fri, Jan 17, 2014 at 15:51:16 CET, Heiko Rosemann wrote:
> On 01/17/2014 02:12 PM, Arno Wagner wrote:
> > On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote:
> >> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer:
> >>> In short: The documented existence of such a feature is a risk
> >>> by itself.
> >> 
> >> Same logic applied, even the existence of this discussion is a
> >> risk by itself. It proves that people might use a patched
> >> cryptsetup with added nuke feature already.
> >> 
> >> Kind regards, jonas
> > 
> > Yes, it is. That is one of the reasons why I strongly recommend not
> > taking ecrypted data into danger at all and making sure all unused
> > space on storage media is zeroed.
> 
> ...which could, by the same logic applied earlier, make the LEO at the
> border suspicious of you having destroyed evidence. Unless you provide
> a proof of purchase, showing that the hard-drive is in fact new and
> therefore still factory-zeroed.

That is not likely to happen. First, it is only the UNused space
to be zeroed, and second, the LEO is not a forensics expert. The
zeroing is not for the LEO, but for some forensics tools
he may be able to hook up  or some real forensic examination.

And there is nothing wrong with haing only zeros and non-encrypted 
data. Having a lot of zeros in a place where a header ro encrypted
data would be might be a different story. But here we run into 
issues. For example, while it is recommended to overwrite a new
LUKS volume (on the decrypted side), it is not done automatically.
So not zeroing the LUKS header but crypto-blanking it can be just
as problematic.

I would say trying to get clever with encrypted containers 
(real-time nuke while a LEO or criminal watches, hidden containers, 
etc.) is not a good idea in general at this time. On the other hand,
erasing data while you are free to act does not need trickery
and should be legal (even if many LEOs will not like that).

That is why I proposed to split the discussion: 1. Explicite 
erase command 2. "trickery" like an erase-password.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Thu, Jan 16, 2014 at 10:50:22 CET, Ondrej Kozina wrote:
> On 01/15/2014 09:27 PM, Milan Broz wrote:
> >On 01/14/2014 05:30 AM, Arno Wagner wrote:
> >>I think that in your scenario, "nuke" does not have any real
> >>advantages over just not having the passphrase, and that one
> >>is dangerous.
> >
> >Well, this idea is not new and I responded very similar months ago.
> >http://code.google.com/p/cryptsetup/issues/detail?id=110#c1
> >
> >But seems there is a lot of people in disagreement.
> >
> >I was quite surprised that most of people from
> >our university security&crypto lab I met today and asked
> >(to have some other opinions) said that despite "nuke password"
> >has very limited use it is worth to have something like that...
> >
> >Sigh... :)
> 
> In that case, let me join you with my humble Sigh as well.
> 
> >But what I really want to avoid is that every distribution will
> >add some random patches implementing something like this.
> >
> >It is perhaps better to implement and document this upstream.
> 
> Ok, I just think that this new feature is quite heavily disputed
> already. This is perhaps third discussion I found on that topic in a
> few minutes of searching. Please, make "nuke password" option
> configurable so that it can be easily removed from any distribution
> that wouldn't agree with arguments for including it.

Good idea!

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Wed, Jan 15, 2014 at 21:27:07 CET, Milan Broz wrote:
> On 01/14/2014 05:30 AM, Arno Wagner wrote:
> > I think that in your scenario, "nuke" does not have any real
> > advantages over just not having the passphrase, and that one
> > is dangerous.
> 
> Well, this idea is not new and I responded very similar months ago.
> http://code.google.com/p/cryptsetup/issues/detail?id=110#c1
> 
> But seems there is a lot of people in disagreement.
> 
> I was quite surprised that most of people from
> our university security&crypto lab I met today and asked
> (to have some other opinions) said that despite "nuke password"
> has very limited use it is worth to have something like that...
> 
> Sigh... :)

Indeed.
 
> But what I really want to avoid is that every distribution will
> add some random patches implementing something like this.

That would be even worse, agreed.
 
> It is perhaps better to implement and document this upstream.
>
> Anyway, you have to manually create such key.
> And cryptsetup never blocked you from shooting yourself in
> the foot if you really want.
> ...

Well, yes. So lets just keep clear warnings in place (the FAQ 
already has one, just need to modify it a bit.)
Then we can at least say "we told you so"...
 
> >From the pure technical POV (ignoring the use case discussion)
> https://raw.github.com/offensive-security/cryptsetup-nuke-keys/master/cryptsetup_1.6.1+nuke_keys.diff
> 
> The principle is ok (it should be implemented on libcryptsetup
> level, so it works from every GUI extension etc).
> 
> But I do not like the details:
> 
> - we do not need additional luksAddNuke command, switch like
> "--use-slot-destruction-key" option to luksAddKey is enough

I agree.

> - I do not like that special key is all zeroes.
> (This is sometimes used for testing etc).
>
> IMHO "nuke key" should be linked to exact header key
> (if you copy this keyslot area to another LUKS header it
> should not work there).
> To be extra paranoid, I think nuke key should be randomized.
> 
> This can be done e.g. if nuke key contains some salt, part
> of real key fingerprint (from LUKS header) and some magic string.

I think that is the best option. 
 
> - I think that "nuke" keyslot should remain active.
> (not really sure about this)
> 
> Opinions?

If we want to do this right, the nuke key must be gone after 
nuking. If we allow to just have a nuke-keyslot, the key-slot 
would need to stay active. But what would be the use of that?
Hence I think the nuke key itself needs to be nuked as well,
because while otherwise the owner could not be forced to give
up an "unlock"-key, they could still be forced to give up that
they know the nuke-key. Or, if, say, they do not input it themselves,
the attacker could verify that it was indeed a nuke key.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] nuke password to delete luks header

[Jonas]

Hey,

Am 15.01.2014 21:27, schrieb Milan Broz:
> On 01/14/2014 05:30 AM, Arno Wagner wrote:
>> I think that in your scenario, "nuke" does not have any real
>> advantages over just not having the passphrase, and that one
>> is dangerous.
> 
> Well, this idea is not new and I responded very similar months ago.
> http://code.google.com/p/cryptsetup/issues/detail?id=110#c1
> 
> But seems there is a lot of people in disagreement.
> 
> I was quite surprised that most of people from
> our university security&crypto lab I met today and asked
> (to have some other opinions) said that despite "nuke password"
> has very limited use it is worth to have something like that...
> 
> Sigh... :)
> 
> But what I really want to avoid is that every distribution will
> add some random patches implementing something like this.
> 
> It is perhaps better to implement and document this upstream.

Milan, have you made your decision yet, whether you add the nuke feature
to libcryptsetup (and cryptsetup util)?

Sorry to raising this topic again ;-p

> From the pure technical POV (ignoring the use case discussion)
> https://raw.github.com/offensive-security/cryptsetup-nuke-keys/master/cryptsetup_1.6.1+nuke_keys.diff
> 
> The principle is ok (it should be implemented on libcryptsetup
> level, so it works from every GUI extension etc).
> 
> But I do not like the details:
> 
> - we do not need additional luksAddNuke command, switch like
> "--use-slot-destruction-key" option to luksAddKey is enough
> 
> - I do not like that special key is all zeroes.
> (This is sometimes used for testing etc).
> 
> IMHO "nuke key" should be linked to exact header key
> (if you copy this keyslot area to another LUKS header it
> should not work there).
> To be extra paranoid, I think nuke key should be randomized.
> 
> This can be done e.g. if nuke key contains some salt, part
> of real key fingerprint (from LUKS header) and some magic string.
> 
> - I think that "nuke" keyslot should remain active.
> (not really sure about this)
> 
> Opinions?

I agree with all your points here, except the last one. Here I'm with
Arno: the nuke feature should remove evidence of its existance when
being used.

Kind regards,
 jonas

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/21/2014 11:40 PM, Jonas wrote:
>> But what I really want to avoid is that every distribution will
>> add some random patches implementing something like this.
>>
>> It is perhaps better to implement and document this upstream.
> 
> Milan, have you made your decision yet, whether you add the nuke feature
> to libcryptsetup (and cryptsetup util)?

Hi,

as Arno said, let's split this to two parts.

> 1. Have a secure erase that is easy to use. [...]
>
> 2. Have the option of unlocking a keyslot created with a specific
>   option to trigger the function implemented in 1. [...]

For 1, I think we can introduce new CLI command "erase" (with alias luksErase)
which will remove all keyslots (in fact it is equivalent of luksKillSlot called
for all active slots).
In libcryptsetup API it can be extension of existing crypt_keyslot_destroy() call.

(It can be easily parameter to luksKillSlot but special command is easy
to understand and remember. Moreover, for some possible formats the keyslot
in command name can be confusing - think TrueCrypt)

(And it should work for future other FDE formats as well. The main use case
is that it removes master key from device but not ciphertext data itself.)

This is not controversial and it is easy to use. Also it can be used in distro
wrappers around cryptsetup. (I can imagine special emergency user login which
will erase header. IMHO much better solution than 2.)

For 2, (aka self destroy passphrase) - I tried to read the discussion again
and I am really not convinced yet we want it.

BTW original patch is INCOMPLETE and DANGEROUS.

(For example, did anyone think about cryptsetup-reencrypt? Guess what will
happen if user try to *reencrypt* device with this destroy passphrase?
Try it... or better not ;-) And there are more missing code which just
do not convince me that it was properly thought-out work.

I think there is only negligible set of users who really have use for nuke pwd
(I do not count "toy" cases.) Note the is already way to do it outside of cryptsetup.

(BTW reencryption (regular key change) is way more better to increase security - even
if anyone have old header backups, it makes these backups unusable.
And I still have very few reports of cryptsetup-reencrypt success stories.
I would like remove experimental warning one day.
... While the list is full of nuke passwords mails...
One would remember http://bikeshed.com/ ... ehm, sorry :-D)

...

Whatever, I can implement 1) easily (even in 1.6.4).

The 2) is question for next version (1.7) but as I said - my current opinion
is still it is not worth to do it.

Milan

Re: [dm-crypt] nuke password to delete luks header

[.. ink ..]

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

speaking of "cryptsetup-reencrypt",any plans to expose its functionality
through the library API?

[-- Attachment #2: Type: text/html, Size: 187 bytes --]

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/23/2014 11:11 PM, .. ink .. wrote:
> 
> speaking of "cryptsetup-reencrypt",any plans to expose its functionality through the library API?

TBH I have never thought about it, it was designed as a standalone tool for LUKS only.

Maybe it would be nice to have integrated this through libcryptsetup but I am afraid it means
a lot of code rewrite.

Milan

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Thu, Jan 23, 2014 at 22:26:42 CET, Milan Broz wrote:
> On 01/21/2014 11:40 PM, Jonas wrote:
> >> But what I really want to avoid is that every distribution will
> >> add some random patches implementing something like this.
> >>
> >> It is perhaps better to implement and document this upstream.
> > 
> > Milan, have you made your decision yet, whether you add the nuke feature
> > to libcryptsetup (and cryptsetup util)?
> 
> Hi,
> 
> as Arno said, let's split this to two parts.
> 
> > 1. Have a secure erase that is easy to use. [...]
> >
> > 2. Have the option of unlocking a keyslot created with a specific
> >   option to trigger the function implemented in 1. [...]
> 
> For 1, I think we can introduce new CLI command "erase" (with alias
> luksErase) which will remove all keyslots (in fact it is equivalent of
> luksKillSlot called for all active slots).  In libcryptsetup API it can be
> extension of existing crypt_keyslot_destroy() call.

This should work well and allow anybody to do a reliable erase.
 
> (It can be easily parameter to luksKillSlot but special command is easy
> to understand and remember. Moreover, for some possible formats the keyslot
> in command name can be confusing - think TrueCrypt)
> 
> (And it should work for future other FDE formats as well. The main use case
> is that it removes master key from device but not ciphertext data itself.)

Indeed. The future-proofness is one argument for this that I 
had not thought about, but it is a good one. 
 
> This is not controversial and it is easy to use. Also it can be used in
> distro wrappers around cryptsetup.  (I can imagine special emergency user
> login which will erase header.  IMHO much better solution than 2.)

Or have anybody that wants it write a wrapper around cryptsetup
that triggers the erase on a specific passphrase. For the situations
described that is about as good as integrating it. In fact it is
better as it is simpler and customizable and there is no need to mess
with key-slot semantics.

> For 2, (aka self destroy passphrase) - I tried to read the discussion 
> again and I am really not convinced yet we want it.

Same here. I think it is about half for, half against, but the "for" 
have really weak arguments. The idea of this feature and the reality
are vastly different. With an "erase" command people can however 
script whatever they want and it is still going to work with future 
versions of cryptsetup.
 
> BTW original patch is INCOMPLETE and DANGEROUS.
> 
> (For example, did anyone think about cryptsetup-reencrypt? Guess what will
> happen if user try to *reencrypt* device with this destroy passphrase?

Simple: 1. Reencrypt all data
        2. Erase all keyslots

That is the "ultra-slow" variant of destroying the data ;-)

> Try it... or better not ;-) And there are more missing code which just
> do not convince me that it was properly thought-out work.
> 
> I think there is only negligible set of users who really have use for nuke
> pwd (I do not count "toy" cases.) Note the is already way to do it outside
> of cryptsetup.
> 
> (BTW reencryption (regular key change) is way more better to increase security - even
> if anyone have old header backups, it makes these backups unusable.
> And I still have very few reports of cryptsetup-reencrypt success stories.
> I would like remove experimental warning one day.
> ... While the list is full of nuke passwords mails...
> One would remember http://bikeshed.com/ ... ehm, sorry :-D)
> 
> ...
> 
> Whatever, I can implement 1) easily (even in 1.6.4).
>
> The 2) is question for next version (1.7) but as I said - my current
> opinion is still it is not worth to do it.

Same here. And with 1) there is really no reason to patch
cryptsetup anymore. Wrappers are a lot easier with it.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] nuke password to delete luks header

[Jonas Meurer]

Am 2014-01-23 22:26, schrieb Milan Broz:
> On 01/21/2014 11:40 PM, Jonas wrote:
>>> But what I really want to avoid is that every distribution will
>>> add some random patches implementing something like this.
>>> 
>>> It is perhaps better to implement and document this upstream.
>> 
>> Milan, have you made your decision yet, whether you add the nuke 
>> feature
>> to libcryptsetup (and cryptsetup util)?
> 
> Hi,
> 
> as Arno said, let's split this to two parts.
> 
>> 1. Have a secure erase that is easy to use. [...]
>> 
>> 2. Have the option of unlocking a keyslot created with a specific
>>   option to trigger the function implemented in 1. [...]
> 
> For 1, I think we can introduce new CLI command "erase" (with alias 
> luksErase)
> which will remove all keyslots (in fact it is equivalent of 
> luksKillSlot called
> for all active slots).
> In libcryptsetup API it can be extension of existing
> crypt_keyslot_destroy() call.
> 
> (It can be easily parameter to luksKillSlot but special command is easy
> to understand and remember. Moreover, for some possible formats the 
> keyslot
> in command name can be confusing - think TrueCrypt)
> 
> (And it should work for future other FDE formats as well. The main use 
> case
> is that it removes master key from device but not ciphertext data 
> itself.)
> 
> This is not controversial and it is easy to use. Also it can be used in 
> distro
> wrappers around cryptsetup. (I can imagine special emergency user login 
> which
> will erase header. IMHO much better solution than 2.)

Great, sounds like a good plan.

> For 2, (aka self destroy passphrase) - I tried to read the discussion 
> again
> and I am really not convinced yet we want it.

Do you intend to protect the erase feature by asking for a password? In 
that
case it will be hard to build a nuke wrapper around 'cryptsetup erase'.
Especially if the nuke password should not reveal access to encrypted 
data
and merely allow to erase LUKS header.

> BTW original patch is INCOMPLETE and DANGEROUS.
> 
> (For example, did anyone think about cryptsetup-reencrypt? Guess what 
> will
> happen if user try to *reencrypt* device with this destroy passphrase?
> Try it... or better not ;-) And there are more missing code which just
> do not convince me that it was properly thought-out work.

Isn't that a good argument for implementing it properly upstream? ;)

> I think there is only negligible set of users who really have use for 
> nuke pwd
> (I do not count "toy" cases.) Note the is already way to do it outside
> of cryptsetup.


> (BTW reencryption (regular key change) is way more better to increase
> security - even
> if anyone have old header backups, it makes these backups unusable.
> And I still have very few reports of cryptsetup-reencrypt success 
> stories.
> I would like remove experimental warning one day.
> ... While the list is full of nuke passwords mails...

While I see your argument, reencryption takes a lot more time than using 
a
nuke feature. Both features serve completely different purposes.

And if you merely want to destroy access to the data, overwriting it is 
still
better than reencrypting, isn't it?

Kind regards,
  jonas

Re: [dm-crypt] nuke password to delete luks header

[Arno Wagner]

On Mon, Jan 27, 2014 at 10:04:28 CET, Jonas Meurer wrote:
> Am 2014-01-23 22:26, schrieb Milan Broz:
> >Hi,
> >
> >as Arno said, let's split this to two parts.
> >
> >>1. Have a secure erase that is easy to use. [...]
> >>
> >>2. Have the option of unlocking a keyslot created with a specific
> >>  option to trigger the function implemented in 1. [...]
[...]
> Do you intend to protect the erase feature by asking for a password?
> In that
> case it will be hard to build a nuke wrapper around 'cryptsetup erase'.
> Especially if the nuke password should not reveal access to
> encrypted data
> and merely allow to erase LUKS header.

I think it should not ask for a password, but ask for confirmation,
like having the user type "ERASE" in shell-interaction, unless
-q/--batch-mode is given. 

The password would not protect better as a user that can run 
cryptsetup can also (but less intuitively) call luksFormat to 
erase the container.

Incidentally, that means wrappers are already possible. 
(In fact, Ubuntu already demonstrated erase-on-install, 
abeit unintentionally, see FAQ Item 1.3.) A luksErase 
command is better, as it works cleaner, erasing is its 
primary purpose, not just a side-effect and it does
not ask for a new password. 
 
> >BTW original patch is INCOMPLETE and DANGEROUS.
> >
> >(For example, did anyone think about cryptsetup-reencrypt? Guess
> >what will
> >happen if user try to *reencrypt* device with this destroy passphrase?
> >Try it... or better not ;-) And there are more missing code which just
> >do not convince me that it was properly thought-out work.
> 
> Isn't that a good argument for implementing it properly upstream? ;)

People making a mess of it? No. Otherwise you would have a really 
easy tool to force upstream to implement things. People making
a mess of it is just a hint that things may be more complicated
than they claim they are. A common occurence, especially with 
security functionality.

Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] nuke password to delete luks header

[Milan Broz]

On 01/27/2014 10:04 AM, Jonas Meurer wrote:
>> For 2, (aka self destroy passphrase) - I tried to read the discussion 
>> again
>> and I am really not convinced yet we want it.
> 
> Do you intend to protect the erase feature by asking for a password? In 
> that
> case it will be hard to build a nuke wrapper around 'cryptsetup erase'.
> Especially if the nuke password should not reveal access to encrypted 
> data
> and merely allow to erase LUKS header.

No, only usual YES/no question should (will) be there
(which can be switched off with batch -q option as in other commands).

The luksKillSlot is doing exactly the same, just for one keyslot.

Actually, it is just simple code as
  for all active keyslots:
     crypt_destroy_slot()

>> BTW original patch is INCOMPLETE and DANGEROUS.
>>
>> (For example, did anyone think about cryptsetup-reencrypt? Guess what 
>> will
>> happen if user try to *reencrypt* device with this destroy passphrase?
>> Try it... or better not ;-) And there are more missing code which just
>> do not convince me that it was properly thought-out work.
> 
> Isn't that a good argument for implementing it properly upstream? ;)

I think this argument was mentioned by me :) But I think we have found better
way how to implement it without this feature.
Avoiding upstream to become bloatware is also important ;-)

...

> While I see your argument, reencryption takes a lot more time than using 
> a
> nuke feature. Both features serve completely different purposes.

Sure, it was just a complain about features importance...

(And btw there is in git already function to change only header (hash)
without reencrypting the whole device. This will be a workaround
to solve bad gcrypt whirlpool case. Once gcrypt 1.6.1 is out...)
...

> And if you merely want to destroy access to the data, overwriting it is 
> still
> better than reencrypting, isn't it?

Yes, and removing key with "erase" command should do the same quickly as well.

Milan

Re: [dm-crypt] nuke password to delete luks header

[Jonas Meurer]

Am 2014-01-27 21:30, schrieb Milan Broz:
> On 01/27/2014 10:04 AM, Jonas Meurer wrote:
>>> For 2, (aka self destroy passphrase) - I tried to read the discussion
>>> again
>>> and I am really not convinced yet we want it.
>> 
>> Do you intend to protect the erase feature by asking for a password? 
>> In
>> that
>> case it will be hard to build a nuke wrapper around 'cryptsetup 
>> erase'.
>> Especially if the nuke password should not reveal access to encrypted
>> data
>> and merely allow to erase LUKS header.
> 
> No, only usual YES/no question should (will) be there
> (which can be switched off with batch -q option as in other commands).
> 
> The luksKillSlot is doing exactly the same, just for one keyslot.
> 
> Actually, it is just simple code as
>   for all active keyslots:
>      crypt_destroy_slot()

Great, sounds good to me.

>>> BTW original patch is INCOMPLETE and DANGEROUS.
>>> 
>>> (For example, did anyone think about cryptsetup-reencrypt? Guess what
>>> will
>>> happen if user try to *reencrypt* device with this destroy 
>>> passphrase?
>>> Try it... or better not ;-) And there are more missing code which 
>>> just
>>> do not convince me that it was properly thought-out work.
>> 
>> Isn't that a good argument for implementing it properly upstream? ;)
> 
> I think this argument was mentioned by me :) But I think we have found 
> better
> way how to implement it without this feature.
> Avoiding upstream to become bloatware is also important ;-)

You're correct.

I still would prefer the nuke feature being implemented upstream. One 
argument in the discussion was, that the mere existance of this feature 
could bring you in trouble. I would reverse the argument: given that the 
nuke feature destroys evidence of its existance in the luks header, a 
custom wrapper implementations in your initramfs make things worse. It 
is much more suspicious than as standard upstream feature that is 
available on every installation.

But for sure I see that the decision is not easy, and arguments against 
implementing it do exist. If it's your decision to not implement nuke 
feature upstream, then that's the way it is. You're the upstream author 
after all ;)

>> While I see your argument, reencryption takes a lot more time than 
>> using
>> a nuke feature. Both features serve completely different purposes.
> 
> Sure, it was just a complain about features importance...

I see. By the way I used reencryption feature several times, and it 
works like a charm for me.

>> And if you merely want to destroy access to the data, overwriting it 
>> is
>> still
>> better than reencrypting, isn't it?
> 
> Yes, and removing key with "erase" command should do the same quickly 
> as well.

Except that this doesn't protect against header backups, just like you 
mentioned before.

Kind regards,
  jonas