Re: Q. LUKS or ecryptfs-utils ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hello James,

As you already said, the decision on which method use depends on what
you want to accomplish so lets take a brief look at how these
encryption methods works:

- dm-crypt with LUKS: the encryption works at partition-level so the
only way to use it is to first create a partition, then encrypt it and
only then mount it and install your system or start filling with
stuff.
- eCryptFS: this method creates an encrypted file wherever you want in
your system so you can transparently mount it and start using it as if
it were just any other directory.

Cons:
dm-crypt/LUKS:
a) if your root directory is encrypted you will need to enter the
decryption passwd every time you boot the system.
b) You can't just encrypt files or directories, as I explain above you
need to first create an encrypted partition and then mount it.
c) Depending the filesystem setup you chose you might not be able to
resize your LUKS partition once it is created (mostly this applies to
Btrfs) so be sure about what you are doing; using an
LVM+pick_your_preferred_FS setup should be okay though.

eCryptFS:
a) Access times are AWFUL but this is absolutely understandable
because the way this encryption works: whenever you put stuff on this
'directory' (or remove stuff from it) it is written to/from a single
file... most problems arises when dealing with lot of I/O operations
or copying big files into it, which is plain painful; however I yet
have to see how it performs on newer SSD drives, so far I only tested
eCryptFS on traditional mechanical disks.
b) If you decide to remove the eCrypt file but you don't carefully
follow developers' instructions it will be HELL -- believe me, I was
there, my own fault of course.

Pros:
dm-crypt/LUKS:
a) The encryption/decryption is much, much, MUCH faster than with
eCryptFS and uses fewer resources, both CPU cycles and disk I/O
operations -- it's likely you won't notice the impact at all.
b) While you will need to enter a passphrase to decrypt your root
partition every time you boot - should you decide to encrypt it - that
isn't true for the rest of your dm-crypt/LUKS volumes: you can use a
password file to automatically decrypt your media thru /etc/crypttab,
which is parsed before /etc/fstab: crypttab first decrypt all the
volumes as instructed and then handles the mounting operation to
fstab.
b) Because of the above, you could easily create a new encrypted
partition and mount it automatically.

eCryptFS:
a) Creating new encrypted storages is as trivial as counting 1, 2, 3.


I'm sure more experienced admins can help you better understand these
encryptions methods, I just wanted to give you an overview of them.

HTH!
-Martin

On Wed, Oct 22, 2014 at 4:32 PM, James B. Byrne <byrnejb@xxxxxxxxxxxxx> wrote:
>
> I am now investigating encrypting our IMAP user spool files.  Does anyone have
> experience with handling encrypted data stores using either or both of the
> subject methods and would care tio share their observations?  Which is the
> preferred method (I know: it depends, but on what?)?   What administrative
> pain does each cause?
>
> Our IMAP host is a KVM guest so spinning up a duplicate and simply copying the
> data to an encrypted device or filesystem is not a very big deal.  We can live
> with manually mounting the file system and providing a pass-phrase at boot.
> we are also looking into a semi-auto USB based solution to that issue.
>
> --
> ***          E-Mail is NOT a SECURE channel          ***
> James B. Byrne                mailto:ByrneJB@xxxxxxxxxxxxx
> Harte & Lyne Limited          http://www.harte-lyne.ca
> 9 Brockley Drive              vox: +1 905 561 1241
> Hamilton, Ontario             fax: +1 905 561 0757
> Canada  L8E 3C3
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos



-- 
-Martin
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux