Re: [dm-crypt] Basics

[Arno Wagner <arno@wagner.name>]

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