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