Re: [dm-crypt] Pass+keyfile

Re: [dm-crypt] Pass+keyfile

[0x14]

> This construction is redundant and does not provide any
> additional security as compared to passphrase alone,
> assuming that your passphrase is secure.

Additional security, as I see it, will be:

1. If you have knowledge about encrypted device, you need to not only 
know the passphrase, but also have the keyfile (have physical access to 
it). Some sort of 2-FA
2. Separate keyfile may be easier to physical destruction, it may be 
crucial when you are in hurry to do that - small microsd card with 
keyfile VS encrypted harddrive. If I get it right, bigger encrypted 
containers in plain mode are harder to destroy also.

Isn`t it somehow comparable to having LUKS header on separate device 
(--header option)?

Am I wrong?

Thanks for patience in advance :)

P.S. Writing form another mail, sorry for possible confusion.

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

On Mon, Dec 01, 2014 at 15:54:45 CET, 0x14@unseen.is wrote:
> >This construction is redundant and does not provide any
> >additional security as compared to passphrase alone,
> >assuming that your passphrase is secure.
> 
> Additional security, as I see it, will be:
> 
> 1. If you have knowledge about encrypted device, you need to not
> only know the passphrase, but also have the keyfile (have physical
> access to it). Some sort of 2-FA

And now do a scenario where an attacke has the passphrase, but
not root access and not the keyfile. There are not many
possibilities for that to happen and most are unrealistic.

The typical way somebody gets your passphrase is by hacking 
your box. Then they also get the master key, the keyfile
and anything else they want. Disk encryption does not protect
against getting hacked. 

> 2. Separate keyfile may be easier to physical destruction, it may be
> crucial when you are in hurry to do that - small microsd card with
> keyfile VS encrypted harddrive. If I get it right, bigger encrypted
> containers in plain mode are harder to destroy also.

No. The SD card is a lot _harder_ to destroy than the LUKS header.
The LUKS header is gone after a single overwrite of 2MiB of data.
The SD card needs very careful physical destruction.

Arno

> Isn`t it somehow comparable to having LUKS header on separate device
> (--header option)?
> 
> Am I wrong?
> 
> Thanks for patience in advance :)
> 
> P.S. Writing form another mail, sorry for possible confusion.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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

Re: [dm-crypt] Pass+keyfile

[Sven Eschenberg]

On Mon, December 1, 2014 17:39, Arno Wagner wrote:
> On Mon, Dec 01, 2014 at 15:54:45 CET, 0x14@unseen.is wrote:
>> >This construction is redundant and does not provide any
>> >additional security as compared to passphrase alone,
>> >assuming that your passphrase is secure.
>>
>> Additional security, as I see it, will be:
>>
>> 1. If you have knowledge about encrypted device, you need to not
>> only know the passphrase, but also have the keyfile (have physical
>> access to it). Some sort of 2-FA
>
> And now do a scenario where an attacke has the passphrase, but
> not root access and not the keyfile. There are not many
> possibilities for that to happen and most are unrealistic.

The only setup I can imagine is having a keyfile and have that encrypted
with a password and keep it separate (as in physical). This way the
password gives you the opportunity to decrypt the keyfile which you don't
have at your fingertips.

The OPs example makes only sense in respect to the fact that the first
container can be closed and is not readable anymore, yet with root privs
the actual mkey can be derived from mem anyway.

>
> The typical way somebody gets your passphrase is by hacking
> your box. Then they also get the master key, the keyfile
> and anything else they want. Disk encryption does not protect
> against getting hacked.
>
>> 2. Separate keyfile may be easier to physical destruction, it may be
>> crucial when you are in hurry to do that - small microsd card with
>> keyfile VS encrypted harddrive. If I get it right, bigger encrypted
>> containers in plain mode are harder to destroy also.
>
> No. The SD card is a lot _harder_ to destroy than the LUKS header.
> The LUKS header is gone after a single overwrite of 2MiB of data.
> The SD card needs very careful physical destruction.
>
> Arno
>
>> Isn`t it somehow comparable to having LUKS header on separate device
>> (--header option)?
>>
>> Am I wrong?
>>
>> Thanks for patience in advance :)
>>
>> P.S. Writing form another mail, sorry for possible confusion.
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Pass+keyfile

[0x14]

> And now do a scenario where an attacke has the passphrase, but
> not root access and not the keyfile. There are not many
> possibilities for that to happen and most are unrealistic.

1. I know about attacker and destroyed keyfile before attacker gets copy 
of it. That is the most important thing I can think of when using 
encrypted keyfile.
2. I have keyfile in a safe in far location (in bunker in another 
country, maybe), while me and my mixed (encrypted and unencrypted) data 
is always with me. Or vice-versa.
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)
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.
...

> No. The SD card is a lot _harder_ to destroy than the LUKS header.
> The LUKS header is gone after a single overwrite of 2MiB of data.
> The SD card needs very careful physical destruction.

I said microsd card. Scissors will definitely destroy data in a few 
secs, you can destroy it even with your teeth, with a lighter maybe. 
While destroying LUKS header demands working computer and knowing what 
you are doing (you might prepare a script for that though). Even if you 
have a drill or a hammer, destroying hard drive with it to unrecoverable 
state is harder than destroying sd or microsd card or even flash drive.

BTW, why do you say it is hard to destroy SD card? I always thought even 
small physical damage on crystal makes data on this crystal practically 
unrecoverable.

P.S. I could accidentally replied to Arno`s email and not this maillist, 
will be more careful next time.

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

On Mon, Dec 01, 2014 at 18:37:16 CET, 0x14@unseen.is wrote:
> >And now do a scenario where an attacke has the passphrase, but
> >not root access and not the keyfile. There are not many
> >possibilities for that to happen and most are unrealistic.
> 
> 1. I know about attacker and destroyed keyfile before attacker gets
> copy of it. That is the most important thing I can think of when
> using encrypted keyfile.

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.

> 2. I have keyfile in a safe in far location (in bunker in another
> country, maybe), while me and my mixed (encrypted and unencrypted)
> data is always with me. Or vice-versa.

If you have a safe location, put all data there. You do not even 
need to encrypt in this case.

> 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...

> 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.

> 
> >No. The SD card is a lot _harder_ to destroy than the LUKS header.
> >The LUKS header is gone after a single overwrite of 2MiB of data.
> >The SD card needs very careful physical destruction.
> 
> I said microsd card. Scissors will definitely destroy data in a few
> secs, you can destroy it even with your teeth, with a lighter maybe.
> While destroying LUKS header demands working computer and knowing
> what you are doing (you might prepare a script for that though).
> Even if you have a drill or a hammer, destroying hard drive with it
> to unrecoverable state is harder than destroying sd or microsd card
> or even flash drive.
> 
> BTW, why do you say it is hard to destroy SD card? I always thought
> even small physical damage on crystal makes data on this crystal
> practically unrecoverable.

No. It makes it still pretty easy to recover, but it is expensive.
Depending on your attacker model, that may or may not help.
Don't use your teeth though, the chips inside are harder than
your teeth are and your teeth are likely to break accomplishing 
nothing. 

Any reliable deletion for flash-type storage is either heating
them up very high or grinding them into fine dust. A lighter alone
will not do the trick and even if you have a pair of fireproof
thongs with you, it may take too long.

Gr"usse,
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

Re: [dm-crypt] Pass+keyfile

[0x14]

Ok then. You know, firstly I wrote long answer for you, but I then I 
thought it would be counterproductive. So I try to make things simpler.

cryptsetup has a --header option, right? So, my first question - why? :) 
 From man: "This options allows one to store ciphertext and LUKS header 
on different devices." Why would anyone want header to be on different 
device? From FAQ, about differences between plain and LUKS mode: "it is 
not readily apparent that there even is encrypted data on the device, as 
an overwrite with crypto-grade randomness (e.g. from /dev/urandom) looks 
exactly the same on disk." (and yes, I read the side-note below). So, I 
thought --header is for those, who want their LUKS containers look like 
just random data, having one device with random data and a file, where 
it is written "I am a LUKS header". And I wanted to have one device with 
random data and a file with random data - I thought it would be more 
secure in some ways. So, the second thing I really want to know - where 
is the bad logic in my reasonings? :)

Thanks!

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

On Tue, Dec 02, 2014 at 01:15:45 CET, 0x14@unseen.is wrote:
> Ok then. You know, firstly I wrote long answer for you, but I then I
> thought it would be counterproductive. So I try to make things
> simpler.
> 
> cryptsetup has a --header option, right? So, my first question -
> why? :) From man: "This options allows one to store ciphertext and
> LUKS header on different devices." Why would anyone want header to
> be on different device? From FAQ, about differences between plain
> and LUKS mode: "it is not readily apparent that there even is
> encrypted data on the device, as an overwrite with crypto-grade
> randomness (e.g. from /dev/urandom) looks exactly the same on disk."
> (and yes, I read the side-note below). So, I thought --header is for
> those, who want their LUKS containers look like just random data,
> having one device with random data and a file, where it is written
> "I am a LUKS header". And I wanted to have one device with random
> data and a file with random data - I thought it would be more secure
> in some ways. So, the second thing I really want to know - where is
> the bad logic in my reasonings? :)

No bad logic so far, I overlooked that you use plain devices
and that you seem to be after some form of plausible deniablility, 
not after increased security. Sorry.

So if that is your goal, that would work. But be aware that 
you always have to type the full (long) command in and that
you must make sure it does not end up on disk (shell history),
otherwise it becomes obvious the two things are not random.

But now a warning: Plausible deniability has been discussed
countless times on this list, and generally, it does not work.
It is one of these ideas that sound good on paper, but it
assumes the enemy is rational, an assumption that usually
fails in practice.

For example, there is the problem that in many countries law
enforcement can just assume that "random" data is encrypted 
and it is up to you to prove otherwise (which, of course is 
impossible, but when has law enforcement ever been rational
or even reasonably intelligent...)

See also FAQ Item 5.18 and note the tendency to label anybody 
not obedient to "authority" a "terrorist" these days 
which sometimes opens up the possibility of torture even in 
supposedly civilized countries. FAQ Items 5.19 and 5.21 are
also somewhat relevant.

Gr"usse,
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

Re: [dm-crypt] Pass+keyfile

[0x14]

> No bad logic so far, I overlooked that you use plain devices
> and that you seem to be after some form of plausible deniablility,
> not after increased security. Sorry.

Some form of increased security with help of plausible deniability :-p
I assumed it sounds and looks like another snake oil, so I came here for 
professional opinion :)

> So if that is your goal, that would work. But be aware that
> you always have to type the full (long) command in and that
> you must make sure it does not end up on disk (shell history),
> otherwise it becomes obvious the two things are not random.

Actually, I was writing a bash script to simplify things a bit before I 
realize I need to clarify things here :) And I know about HISTIGNORE and 
stuff.

What`s your opinion anyways? You do support some "plausible deniability" 
efforts with reservations, as I understood. Writing simple bash wrapper 
around common used cryptsetup commands is not hard, does it worth using 
it as I described after all? Will that "encrypted keyfile" decrease 
security in any way?

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

On Tue, Dec 02, 2014 at 03:43:53 CET, 0x14@unseen.is wrote:
> >No bad logic so far, I overlooked that you use plain devices
> >and that you seem to be after some form of plausible deniablility,
> >not after increased security. Sorry.
> 
> Some form of increased security with help of plausible deniability :-p
> I assumed it sounds and looks like another snake oil, so I came here
> for professional opinion :)
> 
> >So if that is your goal, that would work. But be aware that
> >you always have to type the full (long) command in and that
> >you must make sure it does not end up on disk (shell history),
> >otherwise it becomes obvious the two things are not random.
> 
> Actually, I was writing a bash script to simplify things a bit
> before I realize I need to clarify things here :) And I know about
> HISTIGNORE and stuff.
> 
> What`s your opinion anyways? You do support some "plausible
> deniability" efforts with reservations, as I understood. 

Actually the other way round. I think plausible deniability is
dangerous to the people using it in most situations. I am not 
going to help with it.

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

Re: [dm-crypt] Pass+keyfile

[0x14]

> Actually the other way round. I think plausible deniability is
> dangerous to the people using it in most situations. I am not
> going to help with it.

Ok. Though I think I didn`t ask for any help. Thanks anyway.

Re: [dm-crypt] Pass+keyfile

[0x14]

Ok, if you don`t want to talk about "plausible deniability", let`s get 
back to security if you don`t mind :)

> 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), it is not resistant to water, it 
could be easily copied by attacker and not by you (if you don`t trust 
electronics)...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 :)

> 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 :-\
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?

>> 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.

>> 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 :)

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

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

Re: [dm-crypt] Pass+keyfile

[0x14]

> 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. 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...

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?

>> 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.

>> 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".

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.

>> >>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

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

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

Re: [dm-crypt] Pass+keyfile

[0x14]

I think a simple "fuck off" would look more polite than your answer :-\

Good bye.

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

Just if anybody wonders, I replayed to this privately.

Arno

On Wed, Dec 03, 2014 at 00:40:48 CET, 0x14@unseen.is wrote:
> I think a simple "fuck off" would look more polite than your answer :-\
> 
> Good bye.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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

Re: [dm-crypt] Pass+keyfile

[Dragan Milivojević]

You have the patience of a saint :)

On Wed, Dec 3, 2014 at 5:15 PM, Arno Wagner <arno@wagner.name> wrote:
> Just if anybody wonders, I replayed to this privately.
>
> Arno
>
> On Wed, Dec 03, 2014 at 00:40:48 CET, 0x14@unseen.is wrote:
>> I think a simple "fuck off" would look more polite than your answer :-\
>>
>> Good bye.
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

[dm-crypt] Pass+keyfile

[0x14]

Hi there, is this construction secure? Assuming "keyfile" is a file and 
"/dev/device" is a block device, both made with /dev/urandom.

cryptsetup open --hash=sha512 --cipher=aes-xts-plain64 --type=plain 
keyfile keyfile_tmp && cat /dev/mapper/keyfile_tmp | \
cryptsetup open --hash=sha512 --cipher=aes-xts-plain64 --type=plain 
--key-file=- /dev/device cryptodevice && \
cryptsetup close keyfile_tmp && mount /dev/mapper/cryptodevice 
/media/cryptodevice

The goal is to use pass+keyfile to decrypt storage. I put it in a script 
and it works as it should at a glance. Are there alternatives or 
improvements? Stupid errors maybe?

Thanks.

Re: [dm-crypt] Pass+keyfile

[Arno Wagner]

This construction is redundant and does not provide any 
additional security as compared to passphrase alone, 
assuming that your passphrase is secure.

If your passphrase is insecure, you should fix that 
instead.

Arno




On Mon, Dec 01, 2014 at 03:54:19 CET, 0x14@openmailbox.org wrote:
> Hi there, is this construction secure? Assuming "keyfile" is a file
> and "/dev/device" is a block device, both made with /dev/urandom.
> 
> cryptsetup open --hash=sha512 --cipher=aes-xts-plain64 --type=plain
> keyfile keyfile_tmp && cat /dev/mapper/keyfile_tmp | \
> cryptsetup open --hash=sha512 --cipher=aes-xts-plain64 --type=plain
> --key-file=- /dev/device cryptodevice && \
> cryptsetup close keyfile_tmp && mount /dev/mapper/cryptodevice
> /media/cryptodevice
> 
> The goal is to use pass+keyfile to decrypt storage. I put it in a
> script and it works as it should at a glance. Are there alternatives
> or improvements? Stupid errors maybe?
> 
> Thanks.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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

Re: [dm-crypt] Pass+keyfile

[Quentin Lefebvre]

Hi,

I guess his point was to build something like a strong authentication with:
(1) something that I *own* (a key, maybe on a USB key),
(2) something that I *know* (a passphrase).

This doesn't look too bad to me.

But maybe 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.

Best regards,
Quentin

Le 01/12/2014 13:49, Arno Wagner a écrit :
>
> This construction is redundant and does not provide any
> additional security as compared to passphrase alone,
> assuming that your passphrase is secure.
>
> If your passphrase is insecure, you should fix that
> instead.
>
> Arno
>
>
>
>
> On Mon, Dec 01, 2014 at 03:54:19 CET, 0x14@openmailbox.org wrote:
>> Hi there, is this construction secure? Assuming "keyfile" is a file
>> and "/dev/device" is a block device, both made with /dev/urandom.
>>
>> cryptsetup open --hash=sha512 --cipher=aes-xts-plain64 --type=plain
>> keyfile keyfile_tmp && cat /dev/mapper/keyfile_tmp | \
>> cryptsetup open --hash=sha512 --cipher=aes-xts-plain64 --type=plain
>> --key-file=- /dev/device cryptodevice && \
>> cryptsetup close keyfile_tmp && mount /dev/mapper/cryptodevice
>> /media/cryptodevice
>>
>> The goal is to use pass+keyfile to decrypt storage. I put it in a
>> script and it works as it should at a glance. Are there alternatives
>> or improvements? Stupid errors maybe?
>>
>> Thanks.