| 1 |
Richard Fish wrote: |
| 2 |
> On 8/19/06, Stefan G. Weichinger <lists@×××××.at> wrote: |
| 3 |
>> Would you recommend to use the initramfs from the HOWTO, or might there |
| 4 |
>> be another way of doing it, staying closer at the genkernel-way of |
| 5 |
>> doing it? |
| 6 |
> |
| 7 |
> Well genkernel also allows you to specify a custom linuxrc |
| 8 |
> (--linuxrc=). This is probably the route I would take with genkernel. |
| 9 |
> The default is in /usr/share/genkernel/generic/linuxrc, which you can |
| 10 |
> use for inspiration. Generally that script does everything that you |
| 11 |
> will want to do, just not in the order you want to do it in. |
| 12 |
> |
| 13 |
> You have a few options for this setup. If you don't mind typing your |
| 14 |
|
| 15 |
[...] Great infos, thank you. I will look through them in more detail as |
| 16 |
soon as I have recovered from getting my current setup done. |
| 17 |
|
| 18 |
My main concern in this context is the question: |
| 19 |
|
| 20 |
How to maintain the encrypted partitions over time? |
| 21 |
What do I have to do/remind when I want to use a newer kernel? |
| 22 |
|
| 23 |
The maintenance-steps should be clear, as I for sure don't want to go |
| 24 |
through all of this everytime a new kernel is released. Or even worse, |
| 25 |
lose data ... (backups are done regularly, *yes*) |
| 26 |
|
| 27 |
So this was the/one reason to ask for the genkernel-way. |
| 28 |
|
| 29 |
>> Are there any comparisons between the speed of using |
| 30 |
>> aes-cbc-essiv:sha256, 128bit and |
| 31 |
>> aes-cbc-essiv:sha256, 256bit ? |
| 32 |
> |
| 33 |
> I don't have any comparisons, but it should be easy enough for you to |
| 34 |
> create. Just setup a bare (not luks) mapping and do: |
| 35 |
> |
| 36 |
> dd if=/dev/mapper/crypt_foo of=/dev/null bs=64k count=49152 |
| 37 |
> |
| 38 |
> This will read 3G of 'encrypted' data from the drive. You can do this |
| 39 |
> without affecting any data on the disk, as long as you do *not* |
| 40 |
> luksFormat it. Remember to keep an eye on the CPU usage of this with |
| 41 |
> vmstat or top as well. |
| 42 |
|
| 43 |
Maybe I give this a try after writing this ... |
| 44 |
|
| 45 |
>> /dev/mapper/root is active: |
| 46 |
>> cipher: serpent-cbc-essiv:sha256 |
| 47 |
> |
| 48 |
> Generally I've found AES to be slightly faster... |
| 49 |
|
| 50 |
I found this link at the end of the used HOWTO: |
| 51 |
|
| 52 |
http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio |
| 53 |
|
| 54 |
It also shows that AES is faster than Serpent, and additionally that, |
| 55 |
contrary to the Serpent-Algo, AES with 128 bits is faster than AES with |
| 56 |
a 256bit key. |
| 57 |
|
| 58 |
I will think about this a bit more before I move my data into place. |
| 59 |
|
| 60 |
>> and the performance seems OK to me. But it could always be better ;) |
| 61 |
>> I will have a look through the docs to see the security-implications of |
| 62 |
>> using "only" 128bit. |
| 63 |
> |
| 64 |
> Just be sure to keep in mind the type of data you have and who you are |
| 65 |
> trying to defend against. Researching encryption on the net is a |
| 66 |
> quick way to get irrationally paranoid. The bottom line is that |
| 67 |
> everything can be broken given enough time and money. |
| 68 |
> |
| 69 |
> So if you work for the CIA and keep the secret identies of all spies |
| 70 |
> and informants on your laptop, well, then dm-crypt is not sufficient |
| 71 |
> to begin with. If you work for my investment brokerage and have all |
| 72 |
> your customers' financial records on your disk, I want you to use |
| 73 |
> 256-bit encryption. If it is just your bank records and personal |
| 74 |
> emails, use whatever you want. |
| 75 |
|
| 76 |
No CIA, no. IT-consultant, trying to keep customer-related data |
| 77 |
protected. As well as my own business-related data. |
| 78 |
|
| 79 |
Sounds like AES-256 then. |
| 80 |
|
| 81 |
Thanks a lot for your infos, |
| 82 |
greets, |
| 83 |
Stefan |
| 84 |
-- |
| 85 |
gentoo-user@g.o mailing list |
Archives