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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox