[gentoo-user] LUKS

[gentoo-user] LUKS

[Cláudio Henrique]

has anybody here used LUKS?
If I used on any of my HDs, will I be able to update them? What if the
data of some file gets corrupted, will I loose the whole HD?

thanks in advance,
claudio.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LUKS

[Richard Fish]

On 1/9/06, Cláudio Henrique <rapaduraatomica@gmail.com> wrote:
> has anybody here used LUKS?

I'm using it on my AMD system.

> If I used on any of my HDs, will I be able to update them?

What do you mean?  If you mean changing the password, yes.

> What if the
> data of some file gets corrupted, will I loose the whole HD?

Encryption is done in (4k?) blocks, so you should only lose the
corrupted block.  As to whether you lose a single file or the whole
filesystem, that depends on the nature of the corruption and the
filesystem.  This is no different than having a corrupted hard drive.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LUKS

[Boyd Stephen Smith Jr.]

On Monday 09 January 2006 10:57, Cláudio Henrique 
<rapaduraatomica@gmail.com> wrote about '[gentoo-user] LUKS':

> has anybody here used LUKS?

I haven't, but when I next create an encrypted pv/lv, I will be.

> If I used on any of my HDs, will I be able to update them?

What do you mean by update?  LUKS does allow you to change the key.

> What if the 
> data of some file gets corrupted, will I loose the whole HD?

Depends on how the corruption occurs.  There are a least to ways for this 
to happen:
1) Hardware.  For one reason or another, a bit gets swapped on the HD.  In 
this case what you lose will depend on your cypher, key size, and key 
schedule.  It may be as small as 8 bytes on disk or as large as a full 512 
byte sector.  Of course, if this happens in the fs superblock (or other 
critial area, like the LUKS header) this could be enough to render the 
disk inaccessible, but even a single bit being swapped in the superblock 
can do that.
2) Software.  In particular misbehaving software that accesses the HD via 
LUKS.  In this case the read data will be exactly what is written; LUKS 
can't magically fix errors, but it's not going (supposed) to introduce 
them either.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LUKS

[Cláudio Henrique]

On 1/9/06, Richard Fish <bigfish@asmallpond.org> wrote:
>
> > If I used on any of my HDs, will I be able to update them?
>
> What do you mean?  If you mean changing the password, yes.
>

I mean updating my system (emerge -u world) once I put it on a
cyphered partition.

> > What if the
> > data of some file gets corrupted, will I loose the whole HD?
>
> Encryption is done in (4k?) blocks, so you should only lose the
> corrupted block.  As to whether you lose a single file or the whole
> filesystem, that depends on the nature of the corruption and the
> filesystem.  This is no different than having a corrupted hard drive.
>
> -Richard
>

Interesting. I was worried if the algorithm would make all the blocks
dependents on each other. So, if I loose onde block, I'd be loosing
all the others.

What about the performance, is it too different from plain partition usage?

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LUKS

[Boyd Stephen Smith Jr.]

On Tuesday 10 January 2006 07:13, Cláudio Henrique 
<rapaduraatomica@gmail.com> wrote about 'Re: [gentoo-user] LUKS':
> On 1/9/06, Richard Fish <bigfish@asmallpond.org> wrote:
> > > If I used on any of my HDs, will I be able to update them?
> >
> > What do you mean?
>
> I mean updating my system (emerge -u world) once I put it on a
> cyphered partition.

Encrypted block devices are accessed just like normal block devices, once 
the encryption keys are in memory.  You are only asked for your passphrase 
once, each time the block device is created [1].  Generally, this will 
only be during boot.

> I was worried if the algorithm would make all the blocks 
> dependents on each other. So, if I loose onde block, I'd be loosing
> all the others.

That's not necessary, since each sector has a separate initialization 
vector.  PlumbIV and CBC (along with the patent-encumbered CMC and EME) do 
make the blocks within a sector dependent on one another, which is good 
for resisting certain types of attacks.

> What about the performance, is it too different from plain partition
> usage?

I never noticed the difference when I was using aes-loop on a 2GHz laptop.  
That said, it will depend on the algorithm you choose and the CPU you have 
available.  Also, I /think/ aes-loop was supposed to be faster than 
dm-crypt, but I believe the kernel's implementation of aes (and maybe 
other ciphers) has gotten faster since the last benchmarks I saw.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
ICQ: 514984 YM/AIM: DaTwinkDaddy

[1] This choice of wording might be confusing.  I am referring to when the 
block device is assigned a minor number and the dm mapping loaded into the 
kernel: creation of the block device.  I am not referring to the 
initialization of the LUKS "superblock", when the passphrase and algorithm 
are chosen.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] LUKS

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Am Dienstag, 10. Januar 2006 14:13 schrieb ext Cláudio Henrique:
> On 1/9/06, Richard Fish <bigfish@asmallpond.org> wrote:
> > > If I used on any of my HDs, will I be able to update them?
> >
> > What do you mean?  If you mean changing the password, yes.
>
> I mean updating my system (emerge -u world) once I put it on a
> cyphered partition.

Yes. You use it like an ordinary filesystem.

HTH...

	Dirk
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Hambornerstraße 55      | Web:  http://www.capgemini.com
D-40472 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-user] LUKS

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Am Dienstag, 10. Januar 2006 14:31 schrieb ext Boyd Stephen Smith Jr.:
> > What about the performance, is it too different from plain partition
> > usage?
>
> I never noticed the difference when I was using aes-loop on a 2GHz
> laptop. That said, it will depend on the algorithm you choose and the CPU
> you have available.  Also, I /think/ aes-loop was supposed to be faster
> than dm-crypt, but I believe the kernel's implementation of aes (and
> maybe other ciphers) has gotten faster since the last benchmarks I saw.

That's especially true on x86 where aes is implemented in assembly. Due to 
this it is even faster than blowfish. On non-x86 systems (where aes is 
coded in C), blowfish is said to be faster.

Bye...

	Dirk
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Hambornerstraße 55      | Web:  http://www.capgemini.com
D-40472 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-user] LUKS

[Richard Fish]

On 1/10/06, Boyd Stephen Smith Jr. <bss03@volumehost.com> wrote:
> On Tuesday 10 January 2006 07:13, Cláudio Henrique
> <rapaduraatomica@gmail.com> wrote about 'Re: [gentoo-user] LUKS':
> > What about the performance, is it too different from plain partition
> > usage?
>
> I never noticed the difference when I was using aes-loop on a 2GHz laptop.
> That said, it will depend on the algorithm you choose and the CPU you have
> available.  Also, I /think/ aes-loop was supposed to be faster than
> dm-crypt, but I believe the kernel's implementation of aes (and maybe
> other ciphers) has gotten faster since the last benchmarks I saw.

I tested this recently on my new AMD64 X2 system.  The dm-crypt and
loop-aes are very very close in performance.  I can't really say which
is faster, because for some configurations, dm-crypt was faster, while
for others, loop-AES was faster.  By configurations I mean using 2
disks, software raid, LVM, and dm-crypt/loop-aes, and playing with the
order of the "layers" (do I make a raid of 2 encrypted disks, or
encrypt a raid array of 2 disks, or ...), the block sizes, etc.  And
in some cases, loop-aes would be faster at writing, but dm-crypt would
be faster at reading, or vice-versa.

The one thing I think loop-aes does better is that it creates a
separate thread for each encrypted device, so it can take advantage of
SMP systems.  Still, I ended up using dm-crypt+luks on that system.

For performance, on the AMD64 box, the two disks could deliver a
combined read throughput of around 130MB/sec.  The highest throughput
I got with dm-crypt or loop-aes was 115-118MB/sec read, 95MB/sec
write.

On my 2.13Ghz laptop, using loop-AES, the disk can only deliver a
maximum of 50MB/sec, and loop-aes tops out at about 45MB/sec at 42%
CPU utilization.  The only time it becomes a real impact is when I am
doing a backup, when I have decrypt the data from one disk, archive
it, compress it, and then encrypt the archive when it is written to
another disk.

I do _not_ notice an impact when compiling, becase the amount of disk
activity for a typical compile is insignificant compared to the CPU
usage of the compiler.

-Richard

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] LUKS

[Jorge Almeida]

I've been giving LUKS a try. I setup an encrypted partition on an
external HD.
Running
 	cryptsetup luksOpen /dev/external_hd1 external_hd1
a device file /dev/mapper/external_hd1 is created. I can mount it on
/mnt/external_hd1 and it works as expected.
Now, guess what happens if I run "cryptsetup luksOpen /dev/external_hd1 external_hd1"
again? The file /dev/mapper/external_hd1 disappears (as if 
"cryptsetup luksClose external_hd1" were run).
If /dev/mapper/external_hd1 was mounted on /mnt/external_hd1, it stays
mounted. Otherwise, it seems like cryptsetup luksClose external_hd1...
Confusing?
-- 
Jorge Almeida
-- 
gentoo-user@gentoo.org mailing list