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