1 |
On Wed, Dec 12, 2012 at 09:16:58AM +0100, Florian Philipp wrote: |
2 |
|
3 |
> >>> * The last thing I’m going to set up is filesystem encryption, at least for ~. |
4 |
> >>> I already know/think that AES would be the best choice due to limited CPU |
5 |
> >>> power, but what else is there to heed besides key size? |
6 |
> >> |
7 |
> >> Nothing, you're good. Hash and key chaining method have negligible |
8 |
> >> impact. If you stick with an x86_32 userspace I suggest at least using |
9 |
> >> an x64 kernel so you can use of CRYPTO_AES_X86_64. |
10 |
> > |
11 |
> > That's an interesting idea. |
12 |
> >> [...] |
13 |
> > I haven't done any comparisons of 32/64 crypto yet, I'm just reading |
14 |
> > docs on Luks (never used it before). |
15 |
|
16 |
Well now, I did a few comparisons yesterday. Not much---just permutated a few |
17 |
of the most probable crypto combinations (aes/twofish, cbc/xts, essiv/plain). |
18 |
I created the LUKS container, opened it and gave it a spin with hdparm -t. |
19 |
|
20 |
The result was shocking and outrageous; reported throughput w/o encryption was |
21 |
75 MB/s, which is your typical 5400 rev laptop HDD. First I was disappointed |
22 |
when I saw what aes-cbc-essiv gave me on 32 bit: a mere 19 and a bit. But on |
23 |
64 bit, it yielded a whopping 34 MB/s. I had a hunch and booted the 32 bit |
24 |
system with the 64 bit kernel---and throughput stayed high as expected. |
25 |
|
26 |
So for the sake of simplicity (and to give it a rest after two weeks of ricing |
27 |
to the day), I will use the 32 bit userland with a 64 bit kernel. I will only |
28 |
need to set up some magic (a multilib crossdev gcc and separate build dirs) so |
29 |
I can build both kernels with their separate configs from the same source dir. |
30 |
|
31 |
> I personally see no reason for encrypting root as there is nothing of |
32 |
> interest in there. |
33 |
|
34 |
Hm ideed, the only password I have in a plaintext config file are WiFi |
35 |
passwords vor wpa and vpnc. For those the symlink solution could be used. |
36 |
Not needing an initrd is a big incentive. :) |
37 |
|
38 |
> > On a sidenote, While I was cleaning up unread mails in the ML, I just |
39 |
> > found your interesting frontswap/zcache trick. |
40 |
|
41 |
I tried that, too, but for now will keep it disabled---simple copying of big |
42 |
files was slowed down to 33 MB/s, obviously b/c the cache is constantly being |
43 |
changed. It's just not suitable for little Atoms. |
44 |
-- |
45 |
Gruß | Greetings | Qapla’ |
46 |
Please do not share anything from, with or about me with any Facebook service. |
47 |
|
48 |
The duration of a minute is relative. |
49 |
It depends on the side of the toilet door you are standing on. |