All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Pass+keyfile
Date: Wed, 3 Dec 2014 00:22:27 +0100	[thread overview]
Message-ID: <20141202232227.GA17650@tansi.org> (raw)
In-Reply-To: <adde56a139b7e10669b4ff030ee73075@unseen.is>

On Tue, Dec 02, 2014 at 23:48:51 CET, 0x14@unseen.is wrote:
> >I beg to differ: Good quality paper has a life-expectancy
> >of several hundred years, and so has good quality ink.
> >Make it waterproof with a zip-lock bag. Make it non-obvious by
> >folding it.
> >
> >Even an industial SD card only has 10 years data life expectancy,
> >your ordinary commercial "quality" one can become shaky after as
> >little as a year and a "no name" one even sooner.
> 
> Hm, I think you compare some spaceship technology paper and ink with
> noname sd car manufacturer. 

No. Ordinary, acid-free white copy paper has a life-expectancy 
of several hundred years. Ordinary, non-acidic pigmented ink 
does too. And as to digital flash storage media, have a look
at data-sheets.

> I have no idea where I can get that
> eternal paper and ink that never wares while active use, but I have
> 3 n-year old 1 gb sd and microsd cards that I can still use without
> problem. I have even older working 256-mb flash drive...

You have been lucky.
 
> I still don`t get why I shouldn`t use encrypted keyfile for the
> purpose of destroying information. You tell me that there is an
> alternative. That`s good! But what`s wrong with my way?

I have given a few things. Feel free to ignore my advice.
 
> >>it is not resistant to
> >>water, it could be easily copied by attacker and not by you (if you
> >>don`t trust electronics)...
> >
> >Huh? And the SD card cannot be copied?
> 
> SD could be copied of course, but not as easy as to make a foto of
> piece of paper.
> 
> >And why shoudl the attacker
> >have any advantage here?
> 
> Because then I cannot destroy encrypted container with destroying my
> copy of keyfile.

But why should the attackr have any advantage for the case of
paper over the case of flash storage?
 
> >>and I don`t mention convenience like
> >>ability to carry as many keyfiles as I want without being looking
> >>strange, etc.
> >>
> >>Also, for example, 1024 or 16k letters is far more better for
> >>security than 50+what_you_can_remember letters for passphrase...from
> >>"cryptographical perspective", please excuse my ignorance :)
> >
> >They get hashed to 160 bits by the passphrase input. From
> >about 30 characters onwards, you do not get a better hash.
> 
> That is another thing I wanted to talk about later, but you mention
> it here. Quentin Lefebvre wrote before: "it's worth remembering hash
> algorithms are ignored with key files in plain mode, so that the
> --hash=sha512 is not effective and actually equivalent to
> --hash=plain in this case".

That is not the hash for the password hashing. That is the
hash used in the passphrase iteration and the AF-splitter.
Initial passphrase hashing is done with ripmed160 (as far 
as I remember) and non-configurable.
 
> I have three questions:
> 
> 1. Are you saying passphrases longer than "about 30 characters" are
> useless with plain mode?
> 
> 2. So it is more secure to remove --key-file=- and pass unencrypted
> keyfile as passphrase but make sure I have no new lines there? Then
> I could use --hash=sha512 and it would be effective?
> 
> 3. When I try to replace "--hash=sha512" with "--hash=plain", I
> cannot mount mapped device, so it is not the same. Em?
> 
> I may write very stupid things here, so I apologise in advance for
> that :)
> 
> 
> >It really depends on the details of the scenario.
> 
> Ok, let`s stay in IT security. It could be some sort of timer, and I
> must remotely do something before data get destroyed (phone special
> number, go to website and type password, send email, pay bills,
> etc), then timer resets.

Forget it. This "remotely doing something" is far too open to 
attack and observation.
 
> >>>>3. Attacker can attach a hidden camera behind me while I typing
> >>>>password (or do similar approach) and then get a copy of encrypted
> >>>>data (it is far easier than get full root access)
> >>>
> >>>Oh? Just have the attacker look with the camera while you type
> >>>in your root password...
> >>
> >>Root password != full access right away. Also, they could "catch"
> >>one password and not other.
> >
> >Sorry, but irrelevant. If you do not notice, they have all the time
> >they want. If you notice, then even "right away" is not fast enough.
> >
> >There may be small residual benefit from scenarios where you notice,
> >but only a short time later.
> 
> I could be in video-controlled area for a short period of time, and
> they can get video and data copy far later, when it is obvious it is
> needed. But I agree, this is not very practical case. In other hand,
> not impossible :) IDK

If you want security, then you need to do risk management, not
wishful thinking. Risk management takes the real world into
account. Sure, what you propose _could_ be secure, but
then nobody _could_ be attacking you anyways and not even
encrypting could be secure.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

  reply	other threads:[~2014-12-02 23:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-01 14:54 [dm-crypt] Pass+keyfile 0x14
2014-12-01 16:39 ` Arno Wagner
2014-12-01 16:49   ` Sven Eschenberg
2014-12-01 17:37   ` 0x14
2014-12-01 22:25     ` Arno Wagner
2014-12-02  0:15       ` 0x14
2014-12-02  1:03         ` Arno Wagner
2014-12-02  2:43           ` 0x14
2014-12-02  3:31             ` Arno Wagner
2014-12-02  3:51               ` 0x14
2014-12-02 19:16       ` 0x14
2014-12-02 21:02         ` Arno Wagner
2014-12-02 22:48           ` 0x14
2014-12-02 23:22             ` Arno Wagner [this message]
2014-12-02 23:40               ` 0x14
2014-12-03 16:15                 ` Arno Wagner
2014-12-03 16:19                   ` Dragan Milivojević
  -- strict thread matches above, loose matches on Subject: below --
2014-12-01  2:54 0x14
2014-12-01 12:49 ` Arno Wagner
2014-12-01 13:49   ` Quentin Lefebvre

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=20141202232227.GA17650@tansi.org \
    --to=arno@wagner.name \
    --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.