Re: nuke password to delete luks header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux