From: Jonas <jonas@freesources.org>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] nuke password to delete luks header
Date: Tue, 21 Jan 2014 23:40:05 +0100 [thread overview]
Message-ID: <52DEF745.5040507@freesources.org> (raw)
In-Reply-To: <52D6EF1B.4020206@gmail.com>
Hey,
Am 15.01.2014 21:27, schrieb Milan Broz:
> On 01/14/2014 05:30 AM, Arno Wagner wrote:
>> I think that in your scenario, "nuke" does not have any real
>> advantages over just not having the passphrase, and that one
>> is dangerous.
>
> Well, this idea is not new and I responded very similar months ago.
> http://code.google.com/p/cryptsetup/issues/detail?id=110#c1
>
> But seems there is a lot of people in disagreement.
>
> I was quite surprised that most of people from
> our university security&crypto lab I met today and asked
> (to have some other opinions) said that despite "nuke password"
> has very limited use it is worth to have something like that...
>
> Sigh... :)
>
> But what I really want to avoid is that every distribution will
> add some random patches implementing something like this.
>
> It is perhaps better to implement and document this upstream.
Milan, have you made your decision yet, whether you add the nuke feature
to libcryptsetup (and cryptsetup util)?
Sorry to raising this topic again ;-p
> From the pure technical POV (ignoring the use case discussion)
> https://raw.github.com/offensive-security/cryptsetup-nuke-keys/master/cryptsetup_1.6.1+nuke_keys.diff
>
> The principle is ok (it should be implemented on libcryptsetup
> level, so it works from every GUI extension etc).
>
> But I do not like the details:
>
> - we do not need additional luksAddNuke command, switch like
> "--use-slot-destruction-key" option to luksAddKey is enough
>
> - I do not like that special key is all zeroes.
> (This is sometimes used for testing etc).
>
> IMHO "nuke key" should be linked to exact header key
> (if you copy this keyslot area to another LUKS header it
> should not work there).
> To be extra paranoid, I think nuke key should be randomized.
>
> This can be done e.g. if nuke key contains some salt, part
> of real key fingerprint (from LUKS header) and some magic string.
>
> - I think that "nuke" keyslot should remain active.
> (not really sure about this)
>
> Opinions?
I agree with all your points here, except the last one. Here I'm with
Arno: the nuke feature should remove evidence of its existance when
being used.
Kind regards,
jonas
next prev parent reply other threads:[~2014-01-21 22:40 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 2:10 [dm-crypt] nuke password to delete luks header Jim O'Gorman
2014-01-14 2:41 ` .. ink ..
2014-01-14 2:52 ` Jim O'Gorman
2014-01-14 4:04 ` .. ink ..
2014-01-14 4:36 ` Arno Wagner
2014-01-14 5:00 ` .. ink ..
2014-01-14 7:11 ` Arno Wagner
2014-01-14 12:05 ` .. ink ..
2014-01-14 14:34 ` Arno Wagner
2014-01-14 19:22 ` .. ink ..
2014-01-15 19:36 ` Milan Broz
2014-01-16 11:50 ` Arno Wagner
2014-01-14 4:30 ` Arno Wagner
2014-01-14 5:01 ` Jim O'Gorman
2014-01-14 7:39 ` [dm-crypt] Re2: " Arno Wagner
2014-01-14 22:42 ` Jonas Meurer
2014-01-15 6:01 ` Arno Wagner
2014-01-15 10:00 ` Jonas Meurer
2014-01-15 10:47 ` Arno Wagner
2014-01-15 11:39 ` Matthias Schniedermeyer
2014-01-15 12:40 ` Arno Wagner
2014-01-15 12:59 ` Matthias Schniedermeyer
2014-01-15 13:38 ` .. ink ..
2014-01-15 20:27 ` [dm-crypt] " Milan Broz
2014-01-16 9:50 ` Ondrej Kozina
2014-01-16 10:30 ` Thomas Bastiani
2014-01-16 13:09 ` Florian Junghanns
2014-01-16 19:33 ` Milan Broz
2014-01-16 20:09 ` helices
2014-01-16 20:11 ` Iggy
2014-01-16 21:36 ` Matthias Schniedermeyer
2014-01-16 21:55 ` Arno Wagner
2014-01-16 22:49 ` Claudio Moretti
2014-01-17 8:17 ` Thomas Bastiani
2014-01-17 23:18 ` Claudio Moretti
2014-01-18 8:43 ` Arno Wagner
2014-01-18 12:42 ` Claudio Moretti
2014-01-18 19:18 ` Arno Wagner
2014-01-16 20:18 ` Matthias Schniedermeyer
2014-01-16 20:28 ` .. ink ..
2014-01-16 21:02 ` Brian
2014-01-16 21:24 ` Arno Wagner
2014-01-16 20:59 ` Milan Broz
2014-01-16 21:43 ` Arno Wagner
2014-01-17 12:43 ` Jonas Meurer
2014-01-17 13:12 ` Arno Wagner
2014-01-17 14:27 ` Jonas Meurer
2014-01-17 15:16 ` Matthias Schniedermeyer
2014-01-17 14:32 ` Rick Moritz
2014-01-17 14:32 ` Jonas Meurer
2014-01-17 14:57 ` Arno Wagner
2014-01-17 14:51 ` Heiko Rosemann
2014-01-17 15:10 ` Arno Wagner
2014-01-16 12:01 ` Arno Wagner
2014-01-16 11:59 ` Arno Wagner
2014-01-21 22:40 ` Jonas [this message]
2014-01-23 21:26 ` Milan Broz
2014-01-23 22:11 ` .. ink ..
2014-01-23 22:30 ` Milan Broz
2014-01-23 23:43 ` Arno Wagner
2014-01-27 9:04 ` Jonas Meurer
2014-01-27 12:44 ` Arno Wagner
2014-01-27 20:30 ` Milan Broz
2014-01-28 10:28 ` Jonas Meurer
-- strict thread matches above, loose matches on Subject: below --
2014-01-06 21:01 R3s1stanc3
2014-01-06 21:39 ` Heinz Diehl
2014-01-06 21:44 ` R3s1stanc3
2014-01-06 23:33 ` Claudio Moretti
2014-01-06 23:38 ` R3s1stanc3
2014-01-07 0:03 ` Arno Wagner
2014-01-07 0:01 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52DEF745.5040507@freesources.org \
--to=jonas@freesources.org \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.