From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Pass+keyfile
Date: Tue, 2 Dec 2014 22:02:46 +0100 [thread overview]
Message-ID: <20141202210246.GA15782@tansi.org> (raw)
In-Reply-To: <4ff5f3299a34890282ae5a0cbf8e71f3@unseen.is>
On Tue, Dec 02, 2014 at 20:16:43 CET, 0x14@unseen.is wrote:
> Ok, if you don`t want to talk about "plausible deniability", let`s
> get back to security if you don`t mind :)
Ok.
> >Simpler solution: Use a very long passphrase, learn one part by
> >heart and the other part not and have that on paper. The part
> >on paper could, for example, be 50 random letters and digits.
> >At least I could not remember that. In case of emergency, destroy
> >the paper. (Make it edible for better convenience.) Use
> >severall/all keyslots to make the paper-part harder to remember.
>
> Why should I use papers for that? It is simpler in a way that you
> don`t need a computer to write down something. But as for security
> there are only disadvantages: paper wears (destruction is not or far
> less controllable as with digital storage),
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.
> 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? And why shoudl the attacker
have any advantage here?
> 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.
> >If you have a safe location, put all data there. You do not even
> >need to encrypt in this case.
>
> There is no such thing as perfect safe location, that`s why we use
> cryptography :-\
It is your scenario, not mine...
> Far safe location could give you or your partner some time to
> undertake countermeasures. More time in many cases means more
> security, am I right?
There is one "could" to many in here to say anything definite.
Also requires a far better overall scenario definition.
But we are not in IT security anymore here, the scenarios become
far more murky. If, for example, the first your partner knows
about you having gotten captured is a general announcement
featuring his picture as a "wanted terrorist", that "could avoid
the death penalty", but only if he does not destroy any data
and turns himself in, then more time is irrelevant.
It really depends on the details of the scenario.
> >>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.
> >>4. After encrypting, I give single copy of keyfile to another person
> >>(he is living in bunker in another country, of course). I know
> >>passphrase, he owns keyfile, we can get to the data only if we meet
> >>in person, for example.
> >>...
> >
> >Do the same thing, but just one part data one part passphrase.
> >The keyfile does not add anything.
>
> I agree here :)
Good :)
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 21:02 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 [this message]
2014-12-02 22:48 ` 0x14
2014-12-02 23:22 ` Arno Wagner
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=20141202210246.GA15782@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.