[dm-crypt] Basics

[dm-crypt] Basics

[Mike Nagie]

Hi all,

I'm going to reinstall my ArchLinux and I thought I would try encrypting 
my home folder with dm-crypt.
I read this and ArchWiki several times, but I'm still so confused.
I'd like to keep my system as fast as just possible, sooo here is my 
benchmark results:

PBKDF2-sha1       644088 iterations per second
PBKDF2-sha256     391259 iterations per second
PBKDF2-sha512     321254 iterations per second
PBKDF2-ripemd160  410241 iterations per second
PBKDF2-whirlpool  151703 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   124.2 MiB/s   143.3 MiB/s
 serpent-cbc   128b    49.9 MiB/s   194.5 MiB/s
 twofish-cbc   128b   112.4 MiB/s   211.2 MiB/s
     aes-cbc   256b    96.4 MiB/s   107.1 MiB/s
 serpent-cbc   256b    49.9 MiB/s   194.2 MiB/s
 twofish-cbc   256b   112.4 MiB/s   210.9 MiB/s
     aes-xts   256b   141.5 MiB/s   143.3 MiB/s
 serpent-xts   256b   201.1 MiB/s   191.4 MiB/s
 twofish-xts   256b   207.9 MiB/s   209.1 MiB/s
     aes-xts   512b   108.5 MiB/s   106.2 MiB/s
 serpent-xts   512b   200.1 MiB/s   191.5 MiB/s
 twofish-xts   512b   207.8 MiB/s   209.3 MiB/s

So first thing; this is a 1TiB HDD. Do I need plain64? Or is there any 
drawbacks?

Second: Everybody talks about the aes. It seems the twofish is faster 
here. Does this really matters? I mean this is a HDD, I guess it never 
does anything at that pace. (207MiB/s)

Third: Since xts is supposed to be safer I think it's justified.

Fourth: Key size I'm totally lost. Why 512b (even though it's splitted 
to 256) faster than the others? I'm sure something is not right with my theory 
else who would use 256b?! Do encrypted files bigger with 512b or 
what is the point here?

Fifth: Hash: I'm thinking about sha256.

Sixth: iteration time. I misunderstood the benchmark. I thought 
sha256     391259 iterations per second
means 391259 iterations per second. However I set the iteration time to 
391259 and well... it needless to say, it didn't open the encrypted 
partition in a second, more like in 10 minutes. So I have no idea how 
should I interpret this one.

And lastly: --use-random or --use-urandom. I didn't get this one at all.

Thank you for your answer in advance

Mike
-- 
You are so lucky!

Re: [dm-crypt] Basics

[Mistave]

Generally I use the following line:

# cryptsetup -c aes-xts-plain64:sha512 -h sha512 -y -s 512 -i 5000
--use-random luksFormat /dev/sdX


But AES should be faster, if your CPU supports AES-IN instruction (most
modern CPU's should). Though you are free to choose whatever cipher you
prefer (aes, twofish, serpent). On my PC AES (software) is a bit faster
than serpent and a bit slower than twofish. AES (hardware is fastest).


On 25. 09. 2015 19:33, Mike Nagie wrote:
> Hi all,
> 
> I'm going to reinstall my ArchLinux and I thought I would try encrypting 
> my home folder with dm-crypt.
> I read this and ArchWiki several times, but I'm still so confused.
> I'd like to keep my system as fast as just possible, sooo here is my 
> benchmark results:
> 
> PBKDF2-sha1       644088 iterations per second
> PBKDF2-sha256     391259 iterations per second
> PBKDF2-sha512     321254 iterations per second
> PBKDF2-ripemd160  410241 iterations per second
> PBKDF2-whirlpool  151703 iterations per second
> #  Algorithm | Key |  Encryption |  Decryption
>      aes-cbc   128b   124.2 MiB/s   143.3 MiB/s
>  serpent-cbc   128b    49.9 MiB/s   194.5 MiB/s
>  twofish-cbc   128b   112.4 MiB/s   211.2 MiB/s
>      aes-cbc   256b    96.4 MiB/s   107.1 MiB/s
>  serpent-cbc   256b    49.9 MiB/s   194.2 MiB/s
>  twofish-cbc   256b   112.4 MiB/s   210.9 MiB/s
>      aes-xts   256b   141.5 MiB/s   143.3 MiB/s
>  serpent-xts   256b   201.1 MiB/s   191.4 MiB/s
>  twofish-xts   256b   207.9 MiB/s   209.1 MiB/s
>      aes-xts   512b   108.5 MiB/s   106.2 MiB/s
>  serpent-xts   512b   200.1 MiB/s   191.5 MiB/s
>  twofish-xts   512b   207.8 MiB/s   209.3 MiB/s
> 
> So first thing; this is a 1TiB HDD. Do I need plain64? Or is there any 
> drawbacks?
> 
> Second: Everybody talks about the aes. It seems the twofish is faster 
> here. Does this really matters? I mean this is a HDD, I guess it never 
> does anything at that pace. (207MiB/s)
> 
> Third: Since xts is supposed to be safer I think it's justified.
> 
> Fourth: Key size I'm totally lost. Why 512b (even though it's splitted 
> to 256) faster than the others? I'm sure something is not right with my theory 
> else who would use 256b?! Do encrypted files bigger with 512b or 
> what is the point here?
> 
> Fifth: Hash: I'm thinking about sha256.
> 
> Sixth: iteration time. I misunderstood the benchmark. I thought 
> sha256     391259 iterations per second
> means 391259 iterations per second. However I set the iteration time to 
> 391259 and well... it needless to say, it didn't open the encrypted 
> partition in a second, more like in 10 minutes. So I have no idea how 
> should I interpret this one.
> 
> And lastly: --use-random or --use-urandom. I didn't get this one at all.
> 
> Thank you for your answer in advance
> 
> Mike
> 

Re: [dm-crypt] Basics

[Michael Kjörling]

On 25 Sep 2015 19:33 +0200, from promike1987@gmail.com (Mike Nagie):
> So first thing; this is a 1TiB HDD. Do I need plain64? Or is there any 
> drawbacks?

For optimal security you _must_ use the "plain64" variant for any
container _larger than 2 TiB_. You _can_ use the "plain" variant for
containers smaller than 2 TiB with no ill effects, but using "plain64"
will not have any ill effects on a smaller container either.

I would recommend using "plain64" as a future-proofing measure.


> Second: Everybody talks about the aes. It seems the twofish is faster 
> here. Does this really matters? I mean this is a HDD, I guess it never 
> does anything at that pace. (207MiB/s)

You can expect a theoretical maximum of about 100 MiB/s (+/- 20% or
so) throughput from a 7200 rpm rotational HDD, which is most likely
what you have (unless it's a laptop; then it might be slower).

I/O patterns are _very_ rarely limited by the maximum achievable
sequential I/O throughput. In practice, you are much more likely to be
limited by other software or by factors not related to sequential I/O
throughput, such as the attainable I/O Operations Per Second (IOPS) of
the hard drive (which is, theoretically, 120 IOPS for a 7200 rpm
drive; in practice probably slightly less). IOPS is a function of the
average seek time of the drive.

In other words: _any_ choice that gives you about 100 MiB/s or more
will not be the part that bottlenecks your system when using a HDD to
hold the LUKS container.

AES is a very widely studied cipher which so far has stood up well to
analysis. If you don't have a _very specific_ reason to pick another,
I would recommend that you just go with the flow.


> Third: Since xts is supposed to be safer I think it's justified.

XTS should not be any less secure than CBC-ESSIV, and may be more
secure.

Summarizing for your first three questions: The default is
aes-xts-plain64 for a good reason.


> Fourth: Key size I'm totally lost. Why 512b (even though it's splitted 
> to 256) faster than the others? I'm sure something is not right with my theory 
> else who would use 256b?! Do encrypted files bigger with 512b or 
> what is the point here?

It might be that AES is hardware accellerated.

The key size has no impact on the size of the output of the cipher, so
storage capacity is not affected by the choice of key length.

For a given cipher, I suggest using the longest key length that has
sufficient performance for your scenario. Given that even 512-bit
aes-xts gives you about 110 MiB/s throughput on your particular
system, I see little reason to not go with that when using a
HDD-backed container. Even when using a SSD for storage I would
probably strongly consider it.


> Fifth: Hash: I'm thinking about sha256.

I may be wrong here, but I think the hash is only used during
passphrase to key derivation, and for the LUKS header (which is small
enough that the speed of the cipher should be a non-issue). LUKS
itself does not validate your "payload" data using a hash. SHA-256
should be fine, SHA-512 might well be better, but neither is a poor
choice IMO given what we know at this time. (Cryptography is an
evolving field, but, pardon the pun, quantum leaps are rare.)


> Sixth: iteration time. I misunderstood the benchmark. I thought 
> sha256     391259 iterations per second
> means 391259 iterations per second. However I set the iteration time to 
> 391259 and well... it needless to say, it didn't open the encrypted 
> partition in a second, more like in 10 minutes. So I have no idea how 
> should I interpret this one.

No, the iteration time parameter to cryptsetup takes the _time in
milliseconds_ to iterate the hash function. 391259 ms = 391 seconds or
about 6.5 minutes. The exact time necessary each time you open the
container may vary slightly depending on system load at the time.

If you want the luksOpen to take about a second, set the iteration
time to 1000. If you check the resultant container using luksDump,
that should show an iteration count in the neighborhood of 400,000
iterations.


> And lastly: --use-random or --use-urandom. I didn't get this one at all.

Use --use-random. It's really as simple as that.

The reasons why you might use --use-urandom do not apply to a regular
desktop system.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Michael Kjörling]

On 25 Sep 2015 19:44 +0000, from michael@kjorling.se (Michael Kjörling):
>> Fifth: Hash: I'm thinking about sha256.
> 
> I may be wrong here, but I think the hash is only used during
> passphrase to key derivation, and for the LUKS header (which is small
> enough that the speed of the cipher should be a non-issue).

Brain lapse. This should obviously had read "the speed of the hash"
and not "the speed of the cipher". My apologies.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Mike Nagie]

Thank you very much for your detailed explanation. The whole thing is 
much clearer.

You and Arno convinced me. I might have taken it too seriously, but I 
really wanted to understand.

I'll probably use this command:
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 (or 
an other one I haven't decided yet) --iter-time (about) 2000 (I'm 
generous, about 2 secs seems fine) --use-random

Thank you again
Mike

On 15-09-25 19:44:46, Michael Kjörling wrote:
> On 25 Sep 2015 19:33 +0200, from promike1987@gmail.com (Mike Nagie):
> > So first thing; this is a 1TiB HDD. Do I need plain64? Or is there any 
> > drawbacks?
> 
> For optimal security you _must_ use the "plain64" variant for any
> container _larger than 2 TiB_. You _can_ use the "plain" variant for
> containers smaller than 2 TiB with no ill effects, but using "plain64"
> will not have any ill effects on a smaller container either.
> 
> I would recommend using "plain64" as a future-proofing measure.
> 
> 
> > Second: Everybody talks about the aes. It seems the twofish is faster 
> > here. Does this really matters? I mean this is a HDD, I guess it never 
> > does anything at that pace. (207MiB/s)
> 
> You can expect a theoretical maximum of about 100 MiB/s (+/- 20% or
> so) throughput from a 7200 rpm rotational HDD, which is most likely
> what you have (unless it's a laptop; then it might be slower).
> 
> I/O patterns are _very_ rarely limited by the maximum achievable
> sequential I/O throughput. In practice, you are much more likely to be
> limited by other software or by factors not related to sequential I/O
> throughput, such as the attainable I/O Operations Per Second (IOPS) of
> the hard drive (which is, theoretically, 120 IOPS for a 7200 rpm
> drive; in practice probably slightly less). IOPS is a function of the
> average seek time of the drive.
> 
> In other words: _any_ choice that gives you about 100 MiB/s or more
> will not be the part that bottlenecks your system when using a HDD to
> hold the LUKS container.
> 
> AES is a very widely studied cipher which so far has stood up well to
> analysis. If you don't have a _very specific_ reason to pick another,
> I would recommend that you just go with the flow.
> 
> 
> > Third: Since xts is supposed to be safer I think it's justified.
> 
> XTS should not be any less secure than CBC-ESSIV, and may be more
> secure.
> 
> Summarizing for your first three questions: The default is
> aes-xts-plain64 for a good reason.
> 
> 
> > Fourth: Key size I'm totally lost. Why 512b (even though it's splitted 
> > to 256) faster than the others? I'm sure something is not right with my theory 
> > else who would use 256b?! Do encrypted files bigger with 512b or 
> > what is the point here?
> 
> It might be that AES is hardware accellerated.
> 
> The key size has no impact on the size of the output of the cipher, so
> storage capacity is not affected by the choice of key length.
> 
> For a given cipher, I suggest using the longest key length that has
> sufficient performance for your scenario. Given that even 512-bit
> aes-xts gives you about 110 MiB/s throughput on your particular
> system, I see little reason to not go with that when using a
> HDD-backed container. Even when using a SSD for storage I would
> probably strongly consider it.
> 
> 
> > Fifth: Hash: I'm thinking about sha256.
> 
> I may be wrong here, but I think the hash is only used during
> passphrase to key derivation, and for the LUKS header (which is small
> enough that the speed of the cipher should be a non-issue). LUKS
> itself does not validate your "payload" data using a hash. SHA-256
> should be fine, SHA-512 might well be better, but neither is a poor
> choice IMO given what we know at this time. (Cryptography is an
> evolving field, but, pardon the pun, quantum leaps are rare.)
> 
> 
> > Sixth: iteration time. I misunderstood the benchmark. I thought 
> > sha256     391259 iterations per second
> > means 391259 iterations per second. However I set the iteration time to 
> > 391259 and well... it needless to say, it didn't open the encrypted 
> > partition in a second, more like in 10 minutes. So I have no idea how 
> > should I interpret this one.
> 
> No, the iteration time parameter to cryptsetup takes the _time in
> milliseconds_ to iterate the hash function. 391259 ms = 391 seconds or
> about 6.5 minutes. The exact time necessary each time you open the
> container may vary slightly depending on system load at the time.
> 
> If you want the luksOpen to take about a second, set the iteration
> time to 1000. If you check the resultant container using luksDump,
> that should show an iteration count in the neighborhood of 400,000
> iterations.
> 
> 
> > And lastly: --use-random or --use-urandom. I didn't get this one at all.
> 
> Use --use-random. It's really as simple as that.
> 
> The reasons why you might use --use-urandom do not apply to a regular
> desktop system.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
> OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Michael Kjörling]

On 25 Sep 2015 23:48 +0200, from promike1987@gmail.com (Mike Nagie):
> I'll probably use this command:
> cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 (or 
> an other one I haven't decided yet) --iter-time (about) 2000 (I'm 
> generous, about 2 secs seems fine) --use-random

Looks reasonable, except you forgot to pass "luksFormat" and a device
to cryptsetup, so it won't know what to do with the rest. :-) (Oh, and
note that as discussed here previously, the problems with SHA-1
leading to its current sunsetting don't affect its usage in LUKS. In
fact, I'd expect that for LUKS' purposes, even MD5 would still be a
secure choice, if perhaps somewhat... unusual.)

If you want additional security against forensic analysis, a good
strategy might be to set up a LUKS container with a throwaway
passphrase and key, and then "dd" or "ddrescue" zeroes into it, then
create your real LUKS container in place of the throwaway one. That
will ensure that any remnants of old data are gone, and will prevent
forensic analysis based around which parts of the container appear to
hold encrypted data. In other words:

cryptsetup luksFormat /dev/something
cryptsetup luksOpen /dev/something dummy
dd if=/dev/zero of=/dev/mapper/dummy bs=1M
cryptsetup luksClose dummy
cryptsetup luksFormat ... the real deal goes here ...
cryptsetup luksOpen /dev/something the_real_deal
... now make a file system on /dev/mapper/the_real_deal and start using it ...

Note that the "dd" will take many hours to complete on large drives.
Given that you have a 1 TiB drive and assuming it's a 7200 rpm drive,
I would expect that to take about 3-4 hours if you give LUKS the whole
drive and assuming that there are no other disk accesses going on
concurrently. Using GNU ddrescue instead will provide you with a nice,
continually updated progress report, but effectively does the same
thing. The all-zeroes will be encrypted and on the next luksFormat the
key will be overwritten, resulting in unused portions of the drive
looking like random garbage to anyone looking.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Arno Wagner]

On Sat, Sep 26, 2015 at 00:24:10 CEST, Michael Kjörling wrote:
> On 25 Sep 2015 23:48 +0200, from promike1987@gmail.com (Mike Nagie):
> > I'll probably use this command:
> > cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 (or 
> > an other one I haven't decided yet) --iter-time (about) 2000 (I'm 
> > generous, about 2 secs seems fine) --use-random
> 
> Looks reasonable, except you forgot to pass "luksFormat" and a device
> to cryptsetup, so it won't know what to do with the rest. :-) (Oh, and
> note that as discussed here previously, the problems with SHA-1
> leading to its current sunsetting don't affect its usage in LUKS. In
> fact, I'd expect that for LUKS' purposes, even MD5 would still be a
> secure choice, if perhaps somewhat... unusual.)

It would be. And it will likely remain so for a long, long time.
Remember that the problems with SHA-1 and MD5 are collisions,
not has-reversing. Well, a collision for the use in LUKS
means that if you already have a valid passphrase, you can make 
another one. That does not break LUKS security at all.

Also keep in mind, that only non-iterated SHA-1 and MD5 are
vulnerable to this attack. While I am not aware of anybody
having investigates it, I think it is possible that SHA-1
and MD5 even iterated 2x is secure again against collisions,
as collision attacks are usually tried first against reduced
round version of a hash.

LUKS uses around 10'000 iterations for checking the master key and 
around 400'000 iteratiosn for the passphrase.

Of course, using SHA512 should not make sings weaker, but it
also does not make things any more secure.

As a side-note: It is not a good idea to tinker with crypto-
parameters unless you are an expert. A lot of things are non-obvious
and sometimes you will end up breaking things when you think you make
them more secure.
 
> If you want additional security against forensic analysis, a good
> strategy might be to set up a LUKS container with a throwaway
> passphrase and key, and then "dd" or "ddrescue" zeroes into it, then
> create your real LUKS container in place of the throwaway one. That
> will ensure that any remnants of old data are gone, and will prevent
> forensic analysis based around which parts of the container appear to
> hold encrypted data. In other words:

That is excessive effort. Just do what FAQ Item 2.19 says.

Regards,
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] Basics

[Mike Nagie]

Oh, yeah, you are right. That part was clear and therefore I forgot to 
write it down. I meant:
cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512
--iter-time 2000 --use-random (--verify-passphrase) luksFormat /dev/sdXY

I don't know 'verify passphrase' is justified or not. I guess I'll use 
one of the password generators.

I did not mention, this is a laptop, so it spins 5400 revolutions per 
minute. My data is not encrypted now, and I should securely erase it as 
you suggested too (against forensic analysis). Is

cryptsetup open --type plain /dev/sdXY dummy --key-file /dev/random
dd if=/dev/zero of=/dev/mapper/dummy
rm /dev/mapper/dummy

sufficient,  or I should use shred or srm beforehand?
(Time is not that important as security, but since this is a
5400 1 TiB HDD, I bet srm would overwrite this for days)

According to the ArchWiki, the dd block size could be larger than 
default. It comes from this that the upper command may exit before 
wiping the last blocks if a larger block size is used. How could
I prevent this or make sure everything is overwritten?

Thank you!
Mike


On 15-09-25 22:24:10, Michael Kjörling wrote:
> On 25 Sep 2015 23:48 +0200, from promike1987@gmail.com (Mike Nagie):
> > I'll probably use this command:
> > cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 (or 
> > an other one I haven't decided yet) --iter-time (about) 2000 (I'm 
> > generous, about 2 secs seems fine) --use-random
> 
> Looks reasonable, except you forgot to pass "luksFormat" and a device
> to cryptsetup, so it won't know what to do with the rest. :-) (Oh, and
> note that as discussed here previously, the problems with SHA-1
> leading to its current sunsetting don't affect its usage in LUKS. In
> fact, I'd expect that for LUKS' purposes, even MD5 would still be a
> secure choice, if perhaps somewhat... unusual.)
> 
> If you want additional security against forensic analysis, a good
> strategy might be to set up a LUKS container with a throwaway
> passphrase and key, and then "dd" or "ddrescue" zeroes into it, then
> create your real LUKS container in place of the throwaway one. That
> will ensure that any remnants of old data are gone, and will prevent
> forensic analysis based around which parts of the container appear to
> hold encrypted data. In other words:
> 
> cryptsetup luksFormat /dev/something
> cryptsetup luksOpen /dev/something dummy
> dd if=/dev/zero of=/dev/mapper/dummy bs=1M
> cryptsetup luksClose dummy
> cryptsetup luksFormat ... the real deal goes here ...
> cryptsetup luksOpen /dev/something the_real_deal
> ... now make a file system on /dev/mapper/the_real_deal and start using it ...
> 
> Note that the "dd" will take many hours to complete on large drives.
> Given that you have a 1 TiB drive and assuming it's a 7200 rpm drive,
> I would expect that to take about 3-4 hours if you give LUKS the whole
> drive and assuming that there are no other disk accesses going on
> concurrently. Using GNU ddrescue instead will provide you with a nice,
> continually updated progress report, but effectively does the same
> thing. The all-zeroes will be encrypted and on the next luksFormat the
> key will be overwritten, resulting in unused portions of the drive
> looking like random garbage to anyone looking.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
> OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Mistave]

On 26. 09. 2015 09:14, Mike Nagie wrote:
> rm /dev/mapper/dummy

Shouldn't that be: cryptsetup luksClose dummy

Re: [dm-crypt] Basics

[Mike Nagie]

Thanks Mistave, but the command was without luks.
cryptsetup open --type plain /dev/sdXY dummy --key-file /dev/random

On 15-09-26 09:32:25, Mistave wrote:
> 
> On 26. 09. 2015 09:14, Mike Nagie wrote:
> > rm /dev/mapper/dummy
> 
> Shouldn't that be: cryptsetup luksClose dummy
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Mistave]

Yeah, sorry I messed up there. Should be:
cryptsetup close dummy

On 26. 09. 2015 10:27, Mike Nagie wrote:
> 
> Thanks Mistave, but the command was without luks.
> cryptsetup open --type plain /dev/sdXY dummy --key-file /dev/random
> 
> On 15-09-26 09:32:25, Mistave wrote:
>> 
>> On 26. 09. 2015 09:14, Mike Nagie wrote:
>> > rm /dev/mapper/dummy
>> 
>> Shouldn't that be: cryptsetup luksClose dummy
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 

Re: [dm-crypt] Basics

[Robert Nichols]

On 09/26/2015 02:14 AM, Mike Nagie wrote:
> According to the ArchWiki, the dd block size could be larger than
> default. It comes from this that the upper command may exit before
> wiping the last blocks if a larger block size is used. How could
> I prevent this or make sure everything is overwritten?

You don't need to worry about that. dd will write the final, partial
block, and the final report will say "xxxx+1 records out", indicating
that 1 partial block was written.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] Basics

[Michael Kjörling]

On 26 Sep 2015 09:14 +0200, from promike1987@gmail.com (Mike Nagie):
> I guess I'll use one of the password generators.

If you want a passphrase that you can actually remember, consider
(_manually_) creating a Diceware passphrase of sufficient length. See
www.diceware.com. Remember that you can increase the iteration time to
effectively strengthen the passphrase without needing to make it
absurdly long. Even going from a 1000 to 2000 ms iteration time makes
a huge difference in the ability of an attacker to attack the
passphrase directly (and even 1000 ms on common hardware is quite
sufficient in almost any use case).


> I did not mention, this is a laptop, so it spins 5400 revolutions per 
> minute.

In that case, you should expect maximum I/O throughput to be
correspondingly lower, at which point I'd expect a full 1 TB
purely sequential overwrite to take up to some 6-7 hours.


> My data is not encrypted now, and I should securely erase it as 
> you suggested too (against forensic analysis). Is
> 
> cryptsetup open --type plain /dev/sdXY dummy --key-file /dev/random
> dd if=/dev/zero of=/dev/mapper/dummy
> rm /dev/mapper/dummy
> 
> sufficient,  or I should use shred or srm beforehand?
> (Time is not that important as security, but since this is a
> 5400 1 TiB HDD, I bet srm would overwrite this for days)

After replacing the "rm" with a "cryptsetup close" as mentioned by
Mistave, I believe that will do fine.

You _do_ want to specify a larger blocksize though; otherwise, that
"dd" is going to be painfully slow. Just tack "bs=1M" (or an even
larger block size) at the end of the dd command line. I think the
default is a block size of 512 bytes, which _dramatically_ reduces
attainable I/O speeds.

With modern rotational drives (mid-1990s or so and newer HDDs), common
wisdom is that a single-pass overwrite is sufficient for total erasure
of data. It is _theoretically possible_ that remnants of old data may
be left behind, but this will not be distinguishable from noise and
thus of no practical use to an attacker. Also, unless you are a very
high value target, chances are that an adversary would use only
software-based methods of access to stored data anyway; anything more
is simply too expensive to employ in anything but extraordinary cases.
It is far more likely that a determined adversary would either install
a keylogger, or force you to reveal the passphrase. Compare
<https://xkcd.com/538>.

The purpose of this overwrite step is to overwrite everything on the
drive (or partition) with random garbage before you start using it as
a LUKS container. That way, an adversary won't have the advantage of
being able to focus on areas that actually contain data; the entire
drive or partition will look the same to an external observer without
access to the passphrase. To someone with access to the passphrase
(and thus the data encryption key), there remains the possibility of
telling which portions of the container are in use, but at that point,
_you have already lost anyway_: they have the ciphertext and they have
the key.

As a consequence, **there is no need to do any other overwrite step
before (or after) you do this through-LUKS overwrite**, regardless of
which variant you use. The important part is that you throw away the
key that you use for this overwrite and use a new one going forward.

And lest we forget: make sure to have proper backups in place (ideally
themselves properly protected, possibly through encryption). If the
LUKS header gets damaged, or if you forget the passphrase, you will
not be able to access the contents of your encrypted container.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Mike Nagie]

Thank you for your answer!
Let me summarize what I have learned so far.

The cipher key size doesn't impact on disk space. Maybe it might impact 
on speed; aes-xts 256b was 141.5MiB/s while aes-xts 512b was 108.5MiB/s. 
Twofish is a riddle why it's so fast.
I don't know how reliable this is, but
dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync gave me this 
result:
536870912 bytes (537 MB) copied, 18.2785 s, 29.4 MB/s
(Without fdatasync I got 572 MB/s, which obviously is not true)
So according to the dd result, I could choose any cipher, even serpent 
would not slow my system down.

Since iteration time means millisecond here, it doesn't matter which 
hash I choose.
cryptsetup -h sha1   -i 1000 ... 
cryptsetup -h sha512 -i 1000 ... 
both should take 1 second, just sha1 has 644088 iterations per second 
(on my computer) while sha512 only 321254.
Isn't sha1 safer in this case? I thought the more iterations, the 
better/safer.
I still don't understand if -i just the number of milliseconds, why does 
it differ if I change the CPU. Isn't 1000 milliseconds, 1000 milliseconds 
everywhere?

Thank you for the hint about passwords/passphrases.
Whether is 'cleft cam synod lacy yr wok' more secure than 'nXRUzbL6' (a 
random 'pwgen' generated password)?
I thought I was going to use the same password as my login password, so 
I wouldn't have to enter 2 passwords during every boot.


On 15-09-26 15:38:23, Michael Kjörling wrote:
> On 26 Sep 2015 09:14 +0200, from promike1987@gmail.com (Mike Nagie):
> > I guess I'll use one of the password generators.
> 
> If you want a passphrase that you can actually remember, consider
> (_manually_) creating a Diceware passphrase of sufficient length. See
> www.diceware.com. Remember that you can increase the iteration time to
> effectively strengthen the passphrase without needing to make it
> absurdly long. Even going from a 1000 to 2000 ms iteration time makes
> a huge difference in the ability of an attacker to attack the
> passphrase directly (and even 1000 ms on common hardware is quite
> sufficient in almost any use case).
> 
> 
> > I did not mention, this is a laptop, so it spins 5400 revolutions per 
> > minute.
> 
> In that case, you should expect maximum I/O throughput to be
> correspondingly lower, at which point I'd expect a full 1 TB
> purely sequential overwrite to take up to some 6-7 hours.
> 
> 
> > My data is not encrypted now, and I should securely erase it as 
> > you suggested too (against forensic analysis). Is
> > 
> > cryptsetup open --type plain /dev/sdXY dummy --key-file /dev/random
> > dd if=/dev/zero of=/dev/mapper/dummy
> > rm /dev/mapper/dummy
> > 
> > sufficient,  or I should use shred or srm beforehand?
> > (Time is not that important as security, but since this is a
> > 5400 1 TiB HDD, I bet srm would overwrite this for days)
> 
> After replacing the "rm" with a "cryptsetup close" as mentioned by
> Mistave, I believe that will do fine.
> 
> You _do_ want to specify a larger blocksize though; otherwise, that
> "dd" is going to be painfully slow. Just tack "bs=1M" (or an even
> larger block size) at the end of the dd command line. I think the
> default is a block size of 512 bytes, which _dramatically_ reduces
> attainable I/O speeds.
> 
> With modern rotational drives (mid-1990s or so and newer HDDs), common
> wisdom is that a single-pass overwrite is sufficient for total erasure
> of data. It is _theoretically possible_ that remnants of old data may
> be left behind, but this will not be distinguishable from noise and
> thus of no practical use to an attacker. Also, unless you are a very
> high value target, chances are that an adversary would use only
> software-based methods of access to stored data anyway; anything more
> is simply too expensive to employ in anything but extraordinary cases.
> It is far more likely that a determined adversary would either install
> a keylogger, or force you to reveal the passphrase. Compare
> <https://xkcd.com/538>.
> 
> The purpose of this overwrite step is to overwrite everything on the
> drive (or partition) with random garbage before you start using it as
> a LUKS container. That way, an adversary won't have the advantage of
> being able to focus on areas that actually contain data; the entire
> drive or partition will look the same to an external observer without
> access to the passphrase. To someone with access to the passphrase
> (and thus the data encryption key), there remains the possibility of
> telling which portions of the container are in use, but at that point,
> _you have already lost anyway_: they have the ciphertext and they have
> the key.
> 
> As a consequence, **there is no need to do any other overwrite step
> before (or after) you do this through-LUKS overwrite**, regardless of
> which variant you use. The important part is that you throw away the
> key that you use for this overwrite and use a new one going forward.
> 
> And lest we forget: make sure to have proper backups in place (ideally
> themselves properly protected, possibly through encryption). If the
> LUKS header gets damaged, or if you forget the passphrase, you will
> not be able to access the contents of your encrypted container.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
> OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Michael Kjörling]

On 27 Sep 2015 13:08 +0200, from promike1987@gmail.com (Mike Nagie):
> The cipher key size doesn't impact on disk space. Maybe it might impact 
> on speed; aes-xts 256b was 141.5MiB/s while aes-xts 512b was 108.5MiB/s. 

Given that XTS doubles the key length, and the fact that 128-bit AES
is 10 rounds whereas 256-bit AES is 14 rounds, using AES-XTS with 512
bits of key should be 40% slower than AES-XTS with 256 bits of key.
Your numbers show AES-XTS-512 being about 30% slower than AES-XTS-256,
which I would consider to be within tolerance.

> Twofish is a riddle why it's so fast.

It's a completely different cipher with different properties.


> I don't know how reliable this is, but
> dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync gave me this 
> result:
> 536870912 bytes (537 MB) copied, 18.2785 s, 29.4 MB/s
> (Without fdatasync I got 572 MB/s, which obviously is not true)
> So according to the dd result, I could choose any cipher, even serpent 
> would not slow my system down.

Right; if you're only seeing some 30 MB/s mostly sequential
throughput, any cipher that can do more than that will not be a
bottleneck.

The 572 MB/s number may very well be true, if you consider caching.
The data is initially stored in RAM, then at some later time written
out to disk asynchronously. That's how _most_ I/O is done.


> Since iteration time means millisecond here, it doesn't matter which 
> hash I choose.
> cryptsetup -h sha1   -i 1000 ... 
> cryptsetup -h sha512 -i 1000 ... 
> both should take 1 second, just sha1 has 644088 iterations per second 
> (on my computer) while sha512 only 321254.
> Isn't sha1 safer in this case? I thought the more iterations, the 
> better/safer.

I suppose an argument could be made either way. As has been discussed
here previously, for how it is used by LUKS, practically _any_
cryptographic hash algorithm should be a safe choice, as long as it is
iterated a reasonable number of times.


> I still don't understand if -i just the number of milliseconds, why does 
> it differ if I change the CPU. Isn't 1000 milliseconds, 1000 milliseconds 
> everywhere?

The important part is how many hash iterations are done. Think of it
like this (_highly_ simplified):

1. You enter the passphrase "hello world".
2. "hello world" is fed to the hash, which outputs "123456".
3. "123456" is fed to the hash, which outputs "gjeiqp".
4. "gjeiqp" is fed to the hash, which outputs "mvie8m".
5. "mvie8m" is fed to the hash, which outputs "ba1nwq".
6. The hash that actually gets used is "ba1nwq".

Now, obviously, to arrive at the same result you need to know how many
times to repeat one of the steps 2-5.

If you simply iterate for a given amount of time, a small difference
in system load may cause the process to terminate either early or
late. For example, if system load is slightly higher then the process
may terminate after step 4, causing the hash used to be "mvie8m"
rather than "ba1nwq". The two are obviously not the same, so you get
an error.

Accurate timing is a difficult problem to solve, so LUKS' approach is
to simply allow you to set a ballpark figure (using "-i" to
cryptsetup) but then actually _store_ the number of iterations
actually used. That way, the process instead becomes:

1. You enter the passphrase "hello world".
2. LUKS reads the header and determines that four hash iterations are used.
3. "hello world" is fed to the hash, which outputs "123456".
4. "123456" is fed to the hash, which outputs "gjeiqp".
5. "gjeiqp" is fed to the hash, which outputs "mvie8m".
6. "mvie8m" is fed to the hash, which outputs "ba1nwq".
7. LUKS concludes that the hash has been iterated four times.
8. The hash that actually gets used is "ba1nwq".

At this point, while the wallclock time may differ slightly from one
time opening the container to the next, you are guaranteed to always
be able to open the container given that you have the correct
passphrase, because you are guaranteed to iterate the hash the same
number of times resulting in the same final output value.


> Thank you for the hint about passwords/passphrases.
> Whether is 'cleft cam synod lacy yr wok' more secure than 'nXRUzbL6' (a 
> random 'pwgen' generated password)?

It is relatively straightforward mathematics. Note that I use some
weird-base logarithms here; logN(x) can be calculated as log(x)÷log(N)
where log(x) is the base-10 logarithm of x, such that 10^log(x) = x.
Generally, N^logN(x) = x.

The Diceware word list consists of 7776 (6^5) words, resulting in an
entropy of log2(7776) ~ 12.9 bits per word. Hence, if an adversary
knows that you are using a Diceware passphrase and that it is exactly
six words out of exactly the standard English word list and the words
are separated by exactly one space character (this is already quite a
bit of knowledge), then the search space corresponds to 77.5 bits,
because 6 × log2(7776) ~ 77.5. Each word you add or remove corresponds
to 12.9 bits of search space. (Passphrase hash iteration is meant to
make each attempt somewhat painful to an adversary without
significantly impacting normal use, but doesn't impact the _search
space_ itself.)

Properly generated Diceware passphrases are generated using true
randomness in a physical process. pwgen uses a software pseudo-random
number generator, and making a deterministic process generate quality
randomness is one of the hard problems in cryptography. Low-quality
dice may be slightly biased; this can easily be tested and compensated
for by adding one or two words to the passphrase, or if it is a major
concern then perfectly fair high-quality "casino" dice can be bought.

pwgen, at least by default, uses a 62-character alphabet and eight
characters in a password. That gives 62^8 possible outputs which, if
they are generated completely randomly (which is not the case) results
in a search space corresponding to log2(62^8) ~ 47.6 bits, _if_ the
random number generator used was perfect. For our purposes here we can
likely disregard the biases in the random number generator it uses.

Remember Edward Snowden's advice: "Assume your adversary is capable of
one trillion guesses per second." One (US) trillion is 10^12 and
log2(10^12) ~ 39.9 bits. A 47.6 bit search space thus takes
approximately 2^(47.6-39.9) ~ 208 seconds; on average, half that.
That's two minutes' work by a determined adversary. We don't know if
this refers to guesses with or without hash iteration, but given that
the advice was provided in the context of PGP secret keys, it's
probably safe to assume that it at least is more than raw hash
operations.

The difference between 47.6 bits and 77.5 bits is almost exactly nine
orders of magnitude. In other words, breaking a properly generated
six-word Diceware passphrase _knowing how it was generated_ is about
_a billion times more difficult_ than breaking an eight-character
pwgen password. (A more exact figure is 1,001,836,546 times. This is
2^(77.5-47.6). log10(2^29.9) ~ 9.00.) This turns the 208 seconds into
about 6600 _years_.

_That_ is the security difference between the eight-character pwgen
password and the six-word Diceware passphrase.

To get the same security as the six-word Diceware passphrase using the
pwgen alphabet ([a-zA-Z0-9]), assuming the characters are selected
truly randomly, you need log62(2^77.5) ~ 13 characters. log2(62^13) ~
77.4 bits of search space, which for all intents and purposes is the
same.

Because Diceware passphrases use real words and real-word-lookalikes,
at a given bit strength level they tend to be easier to memorize than
truly random pwgen-style passwords. "cleft cam synod lacy yr wok" is
probably easier to memorize than "Hai0theePuXai".

Of course, because "cleft cam synod lacy yr wok" is published as an
example, its entropy in practice is significantly lower than 77.5
bits. You should never use a passphrase that anyone has published as
an example. (You probably realize this already, but just in case
someone comes across this later and doesn't realize it's a published
example.)

> I thought I was going to use the same password as my login password, so 
> I wouldn't have to enter 2 passwords during every boot.

That's up to you. (And there is no reason why you can't use a Diceware
passphrase for both, either.) I would keep in mind that you type the
login password significantly more often (for example, to unlock the
screen saver) which presents additional opportunities for an adversary
to learn your passphrase. This may or may not be a concern to you.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Arno Wagner]

On Sun, Sep 27, 2015 at 13:08:59 CEST, Mike Nagie wrote:
> Thank you for your answer!
> Let me summarize what I have learned so far.
> 
> The cipher key size doesn't impact on disk space. Maybe it might impact 
> on speed; aes-xts 256b was 141.5MiB/s while aes-xts 512b was 108.5MiB/s. 
> Twofish is a riddle why it's so fast.

It is also less secure because less studied than AES. It is still
a good cipher, as are all that made it into the AES content finals.
And that "less secure" will only be against the NSA and its ilk
that have the skill to break ciphers on their own.

On modern hardware, you will often have AES acceleration though
and then AES will be faster.

> I don't know how reliable this is, but
> dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync gave me this 
> result:
> 536870912 bytes (537 MB) copied, 18.2785 s, 29.4 MB/s
> (Without fdatasync I got 572 MB/s, which obviously is not true)
> So according to the dd result, I could choose any cipher, even serpent 
> would not slow my system down.

Not a surprise. You do never get raw disk-speed when you have
a filesystem in there. 
 
> Since iteration time means millisecond here, it doesn't matter which 
> hash I choose.

Basically, yes.

> cryptsetup -h sha1   -i 1000 ... 
> cryptsetup -h sha512 -i 1000 ... 
> both should take 1 second, just sha1 has 644088 iterations per second 
> (on my computer) while sha512 only 321254.
> Isn't sha1 safer in this case? I thought the more iterations, the 
> better/safer.

It might be. It might also be because it is older and its implementation
will be better optimized. That is one reason to use the cryptsetup
defaults.

> I still don't understand if -i just the number of milliseconds, why does 
> it differ if I change the CPU. Isn't 1000 milliseconds, 1000 milliseconds 
> everywhere?

Yes, but the speed of the hash is different for a different CPU.

> Thank you for the hint about passwords/passphrases.
> Whether is 'cleft cam synod lacy yr wok' more secure than 'nXRUzbL6' (a 
> random 'pwgen' generated password)?

Also refer to FAQ Item 5.1. The first pasphrase will have something
like 13...29 bits of entropy, which is entirely breakable when
attacking crypto (it is not when attacking a log-in, as they 
allow far less trial-attacks per second). The second one has
abouy 48 bits of entropy and is much stronger. It is still a
bit on the weak side for encryption, even with LUKS.

> I thought I was going to use the same password as my login password, so 
> I wouldn't have to enter 2 passwords during every boot.

Do _not_ do that. Your login is a conceptually entirely different
protection with different characteristics. It can be much weaker
than a crypto passphrase, but it can also be attacked in entirely
different ways.

Regards,
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] Basics

[Michael Kjörling]

On 27 Sep 2015 16:08 +0200, from arno@wagner.name (Arno Wagner):
>> Whether is 'cleft cam synod lacy yr wok' more secure than 'nXRUzbL6' (a 
>> random 'pwgen' generated password)?
> 
> Also refer to FAQ Item 5.1. The first pasphrase will have something
> like 13...29 bits of entropy,

Now I'm curious. Given that 6 × log2(6^5) ~ 77.6, and Diceware uses a
6^5 word dictionary, how did you arrive at the range 13 through 29
bits of entropy?

Note that even when using the English Diceware word list, you cannot
assume the same entropy per character or word as in English prose
precisely because the advice for generating Diceware passphrases
specifically suggest _repeating the process_ if one ends up with a
passphrase that actually makes sense.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Arno Wagner]

On Sun, Sep 27, 2015 at 16:15:34 CEST, Michael Kjörling wrote:
> On 27 Sep 2015 16:08 +0200, from arno@wagner.name (Arno Wagner):
> >> Whether is 'cleft cam synod lacy yr wok' more secure than 'nXRUzbL6' (a 
> >> random 'pwgen' generated password)?
> > 
> > Also refer to FAQ Item 5.1. The first pasphrase will have something
> > like 13...29 bits of entropy,
> 
> Now I'm curious. Given that 6 × log2(6^5) ~ 77.6, and Diceware uses a
> 6^5 word dictionary, how did you arrive at the range 13 through 29
> bits of entropy?
> 
> Note that even when using the English Diceware word list, you cannot
> assume the same entropy per character or word as in English prose
> precisely because the advice for generating Diceware passphrases
> specifically suggest _repeating the process_ if one ends up with a
> passphrase that actually makes sense.

I have no idea what Diceware does, and there was no reference to
this being a Diceware-generated passphrase. If it is, the 
calculation is different.

Ok, judging from their website: 8000 words gives them 13 bit 
per word. Ok, with that they are at 77 bits for said passphrase,
which is much better and likely secure.

The difference to ordinary words is most likely due to them 
having chosen words far shorter than is average in english. 

Regards,
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] Basics

[Mike Nagie]

Thank you guys for your awesome explanation.

As we just have concluded that a Diceware passphrase is much more 
secure, then I'd like to ask you: should I need more than one LUKS key? 
-I'm the only user-
The original idea was, creating an encrypted partition for the /home 
then I'm going to set a very strong master passphrase (I assume that 
slot 0 is the master) after that I add another LUKS key which is the 
same password as my account's.

Does more than one LUKS key reduce the security?
If Key Slot 0's passphrase was 'cleft cam synod lacy yr wok'
and Key Slot 1 would be 'a'.

Does the whole thing worth anything? Does it matter if I have a really 
strong passphrase and a not that strong second phrase? 

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Michael Kjörling]

On 27 Sep 2015 18:12 +0200, from promike1987@gmail.com (Mike Nagie):
> I'm going to set a very strong master passphrase /.../ after that I
> add another LUKS key which is the same password as my account's.

Why? What do you hope to achieve by doing that?

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Mike Nagie]

Ok, so it just probably weakens the security, as I can add less secure 
passphrases, and this case the other slot would be the weakest link.
On the other hand I will have two passphrases and it's less likely to 
forget/lose 2 passphrases at once.

The source that that's a good idea:
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Key_management

Or do you suggest a key file rather than a Diceware passphrase which 
would be written down on paper? Or just one passphrase, because you 
don't agree with this practice.


On 15-09-27 16:51:12, Michael Kjörling wrote:
> On 27 Sep 2015 18:12 +0200, from promike1987@gmail.com (Mike Nagie):
> > I'm going to set a very strong master passphrase /.../ after that I
> > add another LUKS key which is the same password as my account's.
> 
> Why? What do you hope to achieve by doing that?
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
> OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Heinz Diehl]

On 27.09.2015, Mike Nagie wrote: 

> As we just have concluded that a Diceware passphrase is much more 
> secure, then I'd like to ask you: should I need more than one LUKS key? 

What's your thread model, actually? Whom do you want to protect your
data from?

> The original idea was, creating an encrypted partition for the /home 
> then I'm going to set a very strong master passphrase (I assume that 
> slot 0 is the master) after that I add another LUKS key which is the 
> same password as my account's.

That would reduce your password strength to the strength of the
weakest of these two.

> Does more than one LUKS key reduce the security?

A chain is only as strong as its weakest link. This law applies
perfectly also to this particular scenario.

> Does it matter if I have a really strong passphrase and a not that strong second phrase? 

Think about it. It's quite obvious.

Re: [dm-crypt] Basics

[Heinz Diehl]

On 27.09.2015, Heinz Diehl wrote: 

> What's your thread model

Threat, of course. Sorry!

Re: [dm-crypt] Basics

[Mike Nagie]

There is really no threat or adversary. I really hope the threat is much 
lower than 1%.

I had never dealt with encryption before, and I find it very 
interesting.
I'd like to defend my data in case it's lost or stolen.
(In this (windows) world I think an unencrypted reiserfs could be 
sufficient too.)

So my plan is to establish an indiscernible encrypted home partition.
I wouldn't like to feel any side effects, like more passwords, bigger 
disk usage or slower I/O throughput.

I already use EncFS which is rather slow. I made some 1080i videos with 
my camcorder, and vlc struggles with it.


On 15-09-27 20:55:54, Heinz Diehl wrote:
> On 27.09.2015, Mike Nagie wrote: 
> 
> > As we just have concluded that a Diceware passphrase is much more 
> > secure, then I'd like to ask you: should I need more than one LUKS key? 
> 
> What's your thread model, actually? Whom do you want to protect your
> data from?
> 
> > The original idea was, creating an encrypted partition for the /home 
> > then I'm going to set a very strong master passphrase (I assume that 
> > slot 0 is the master) after that I add another LUKS key which is the 
> > same password as my account's.
> 
> That would reduce your password strength to the strength of the
> weakest of these two.
> 
> > Does more than one LUKS key reduce the security?
> 
> A chain is only as strong as its weakest link. This law applies
> perfectly also to this particular scenario.
> 
> > Does it matter if I have a really strong passphrase and a not that strong second phrase? 
> 
> Think about it. It's quite obvious.
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Michael Kjörling]

On 27 Sep 2015 23:50 +0200, from promike1987@gmail.com (Mike Nagie):
> On 15-09-27 20:55:54, Heinz Diehl wrote:
>> What's your thread model, actually? Whom do you want to protect your
>> data from?
> 
> There is really no threat or adversary. I really hope the threat is much 
> lower than 1%.
> 
> I had never dealt with encryption before, and I find it very 
> interesting.
> I'd like to defend my data in case it's lost or stolen.

_That's a threat model._

"Threat model" is just a fancy way of saying "what are you trying to
protect, and against what?". It's a very basic concept in anything
relating to any kind of security, because all security is a trade-off,
and you have to know what you aim to protect against in order to judge
whether a given trade-off is reasonable.

Consider your home: you probably lock the door while you are away, and
possibly while you are at home, but you don't live behind a 30 cm
steel door bolted to the opening of a mountain cave. Maybe you take
some valuables with you when you leave your home, like car keys or
your wallet. Maybe you have a home alarm system of some kind. This is
because, at some level, you have a (perhaps not explicit) threat model
and have determined that these actions are a good way to mitigate the
particular threat, whereas the 30 cm steel door probably wouldn't be.

Technically, what you are saying above is that you aim to protect your
data from disclosure in case of unauthorized access to the physical
storage device. That's something full disk encryption (such as LUKS on
Linux, or Bitlocker on Windows) can help you with. (As a
counterexample, full disk encryption _cannot_ readily help you if you
are trying to protect against remote exploitation of a running system
where the FDE container is already unlocked.)

If, for example, you want to protect your data against "petty
thieves", the choices you make in protecting the data are likely to be
quite different compared to if you were concerned about protecting
your data from government agencies.

For more on threat models and threat modeling, you can start at
<https://ssd.eff.org/en/module/introduction-threat-modeling> and
<https://en.wikipedia.org/wiki/Threat_model>.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Basics

[Heinz Diehl]

On 27.09.2015, Mike Nagie wrote: 

> I'd like to defend my data in case it's lost or stolen.

So all you need is encryption in any way (any cipher/hash/keysize combination will do) and a strong enough
password or a keyfile on USB memory. No withening of available disk space is necessary.

Practically, all you'll have to do is to stick with the defaults and
do the encryption. If there's unencrypted data on your free disk
space, you'll however have to overwrite it. Just do the encryption,
log into your machine and do something like "dd if=/dev/zero
of=deleteme".

Re: [dm-crypt] Basics

[Mike Nagie]

Thank you guys for your help!
I take into account what you suggested.
As I wouldn't need 30 cm steel door if I lived in an uninhabited island.
And probably the weakest encryption would be a challenge for a 'petty 
thief', like: cryptsetup -v --cipher blowfish-cbc-plain --key-size
128 --hash sha1 --iter-time 500 --use-random luksFormat <device>

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Mike Nagie]

Why is this happening? I'm trying to create encrypted luks partition 
with a keyfile.

cryptsetup luksFormat /dev/sda2 /dev/sdb1

WARNING!
This will overwrite data on /dev/sda2 irrevocably.

Are you sure? (Type uppercase yes): YES
Maximum keyfile size exceeded.
cryptsetup luksFormat /dev/sda2 /dev/sdb1 10.54s user 4.55s system 83% 
cpu 18.1

(and sometimes: command failed with code 22 invalid argument)

cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1
Maximum keyfile size exceeded.
cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1  10.43s user 
4.64s system 99% cpu 15.103 total
-- 
You are so lucky!

Re: [dm-crypt] Basics

[Arno Wagner]

You are using /dev/sdb1 as your keyfile. cryptsetup
has a compiled-in size limit on keyfiles, which is
per default 8kB. If /dev/sdb1 is larger, you get the
error you observe.

Regards,
Arno


On Wed, Sep 30, 2015 at 14:16:26 CEST, Mike Nagie wrote:
> Why is this happening? I'm trying to create encrypted luks partition 
> with a keyfile.
> 
> cryptsetup luksFormat /dev/sda2 /dev/sdb1
> 
> WARNING!
> This will overwrite data on /dev/sda2 irrevocably.
> 
> Are you sure? (Type uppercase yes): YES
> Maximum keyfile size exceeded.
> cryptsetup luksFormat /dev/sda2 /dev/sdb1 10.54s user 4.55s system 83% 
> cpu 18.1
> 
> (and sometimes: command failed with code 22 invalid argument)
> 
> cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1
> Maximum keyfile size exceeded.
> cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1  10.43s user 
> 4.64s system 99% cpu 15.103 total
> -- 
> You are so lucky!
> _______________________________________________
> 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] Basics

[Mike Nagie]

Thanks Arno!

I thought it was just a bug, but now, it works  :)
I didn't really understand it. I thought it would generate 
a secure keyfile.
Now it's clean, thank you!

On 15-09-30 17:00:03, Arno Wagner wrote:
> You are using /dev/sdb1 as your keyfile. cryptsetup
> has a compiled-in size limit on keyfiles, which is
> per default 8kB. If /dev/sdb1 is larger, you get the
> error you observe.
> 
> Regards,
> Arno
> 
> 
> On Wed, Sep 30, 2015 at 14:16:26 CEST, Mike Nagie wrote:
> > Why is this happening? I'm trying to create encrypted luks partition 
> > with a keyfile.
> > 
> > cryptsetup luksFormat /dev/sda2 /dev/sdb1
> > 
> > WARNING!
> > This will overwrite data on /dev/sda2 irrevocably.
> > 
> > Are you sure? (Type uppercase yes): YES
> > Maximum keyfile size exceeded.
> > cryptsetup luksFormat /dev/sda2 /dev/sdb1 10.54s user 4.55s system 83% 
> > cpu 18.1
> > 
> > (and sometimes: command failed with code 22 invalid argument)
> > 
> > cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1
> > Maximum keyfile size exceeded.
> > cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1  10.43s user 
> > 4.64s system 99% cpu 15.103 total
> > -- 
> > You are so lucky!
> > _______________________________________________
> > 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

-- 
You are so lucky!

Re: [dm-crypt] Basics

[Arno Wagner]

You are welcome. 

Arno

On Wed, Sep 30, 2015 at 19:49:21 CEST, Mike Nagie wrote:
> Thanks Arno!
> 
> I thought it was just a bug, but now, it works  :)
> I didn't really understand it. I thought it would generate 
> a secure keyfile.
> Now it's clean, thank you!
> 
> On 15-09-30 17:00:03, Arno Wagner wrote:
> > You are using /dev/sdb1 as your keyfile. cryptsetup
> > has a compiled-in size limit on keyfiles, which is
> > per default 8kB. If /dev/sdb1 is larger, you get the
> > error you observe.
> > 
> > Regards,
> > Arno
> > 
> > 
> > On Wed, Sep 30, 2015 at 14:16:26 CEST, Mike Nagie wrote:
> > > Why is this happening? I'm trying to create encrypted luks partition 
> > > with a keyfile.
> > > 
> > > cryptsetup luksFormat /dev/sda2 /dev/sdb1
> > > 
> > > WARNING!
> > > This will overwrite data on /dev/sda2 irrevocably.
> > > 
> > > Are you sure? (Type uppercase yes): YES
> > > Maximum keyfile size exceeded.
> > > cryptsetup luksFormat /dev/sda2 /dev/sdb1 10.54s user 4.55s system 83% 
> > > cpu 18.1
> > > 
> > > (and sometimes: command failed with code 22 invalid argument)
> > > 
> > > cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1
> > > Maximum keyfile size exceeded.
> > > cryptsetup open --type luks /dev/sda2 home -d /dev/sdb1  10.43s user 
> > > 4.64s system 99% cpu 15.103 total
> > > -- 
> > > You are so lucky!
> > > _______________________________________________
> > > 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
> 
> -- 
> You are so lucky!
> _______________________________________________
> 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] Basics

[Heinz Diehl]

On 30.09.2015, Mike Nagie wrote: 

> Why is this happening?

> Maximum keyfile size exceeded.

Because your keyfile exceeds the maximum keyfile size?
Take a look at cryptsetup --help | grep "keyfile size".

Re: [dm-crypt] Basics

[Arno Wagner]

Hi Mike,

unless you are a crypto-expert, go with the cryptsetup
defaults. For not too old versions, these are
aes-xts-plain64 for LUKS and PBKDF2-sha1 for the
key protection (no, SHA-1 is not insecure when
used like here...).

Regards,
Arno

On Fri, Sep 25, 2015 at 19:33:16 CEST, Mike Nagie wrote:
> Hi all,
> 
> I'm going to reinstall my ArchLinux and I thought I would try encrypting 
> my home folder with dm-crypt.
> I read this and ArchWiki several times, but I'm still so confused.
> I'd like to keep my system as fast as just possible, sooo here is my 
> benchmark results:
> 
> PBKDF2-sha1       644088 iterations per second
> PBKDF2-sha256     391259 iterations per second
> PBKDF2-sha512     321254 iterations per second
> PBKDF2-ripemd160  410241 iterations per second
> PBKDF2-whirlpool  151703 iterations per second
> #  Algorithm | Key |  Encryption |  Decryption
>      aes-cbc   128b   124.2 MiB/s   143.3 MiB/s
>  serpent-cbc   128b    49.9 MiB/s   194.5 MiB/s
>  twofish-cbc   128b   112.4 MiB/s   211.2 MiB/s
>      aes-cbc   256b    96.4 MiB/s   107.1 MiB/s
>  serpent-cbc   256b    49.9 MiB/s   194.2 MiB/s
>  twofish-cbc   256b   112.4 MiB/s   210.9 MiB/s
>      aes-xts   256b   141.5 MiB/s   143.3 MiB/s
>  serpent-xts   256b   201.1 MiB/s   191.4 MiB/s
>  twofish-xts   256b   207.9 MiB/s   209.1 MiB/s
>      aes-xts   512b   108.5 MiB/s   106.2 MiB/s
>  serpent-xts   512b   200.1 MiB/s   191.5 MiB/s
>  twofish-xts   512b   207.8 MiB/s   209.3 MiB/s
> 
> So first thing; this is a 1TiB HDD. Do I need plain64? Or is there any 
> drawbacks?
> 
> Second: Everybody talks about the aes. It seems the twofish is faster 
> here. Does this really matters? I mean this is a HDD, I guess it never 
> does anything at that pace. (207MiB/s)
> 
> Third: Since xts is supposed to be safer I think it's justified.
> 
> Fourth: Key size I'm totally lost. Why 512b (even though it's splitted 
> to 256) faster than the others? I'm sure something is not right with my theory 
> else who would use 256b?! Do encrypted files bigger with 512b or 
> what is the point here?
> 
> Fifth: Hash: I'm thinking about sha256.
> 
> Sixth: iteration time. I misunderstood the benchmark. I thought 
> sha256     391259 iterations per second
> means 391259 iterations per second. However I set the iteration time to 
> 391259 and well... it needless to say, it didn't open the encrypted 
> partition in a second, more like in 10 minutes. So I have no idea how 
> should I interpret this one.
> 
> And lastly: --use-random or --use-urandom. I didn't get this one at all.
> 
> Thank you for your answer in advance
> 
> Mike
> -- 
> You are so lucky!
> _______________________________________________
> 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