Re: nuke password to delete luks header

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

 



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@xxxxxxxxxxx
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@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