[dm-crypt] nuke password to delete luks header
dm-crypt at mdsresource.net
Thu Jan 16 21:09:25 CET 2014
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
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 at 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
> 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
> 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
> 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.
> dm-crypt mailing list
> dm-crypt at saout.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt