Searching options for drive encryption

I run openSUSE 13.1 and will install 13.2 shortly, but I would like to search for options for “cascading” encryption, such as Truecrypt offered. I currently use an encrypted LVM, but would like to go back to normal partitions. I have large amounts of data on Windows drives that were encrypted by Truecrypt. I run Truecrypt for Linux for access to those drives, but since Truecrypt has ended it’s run, I would like to re-format those drives to Linux filesystems. I have also had problems with very long shut-down times, which I think are caused by Truecrypt refusing to release something in the root filesystem, even after I manually dismounted the drives and quit Truecrypt.

My Windows drives are encrypted with a “cascade” of AES, TwoFish, and Serpent. Is there any way to do something similar with Linux filesystems?

Why dont you just use Bitlocker on the Windows drives? Or Symantec Encryption Desktop? Those are the 2 most popular technologies nowadays

Hi!

Even while runnung the installer from the openSUSE DVD, and choosing ‘expert partition setup’, you are able to select encryption for any partition - which probably only will make sense for your home partition(s) where your private data is stored.

This encryption is free, i.e. it comes with openSUSE - no additional software needed here.

However, there may be difficulties to access the encrypted data on these partions from windows.

Good luck
Mike

On Thu, 25 Dec 2014 23:56:01 +0000, fc321 wrote:

> purevw;2685180 Wrote:
>> I run openSUSE 13.1 and will install 13.2 shortly, but I would like to
>> search for options for “cascading” encryption, such as Truecrypt
>> offered. I currently use an encrypted LVM, but would like to go back to
>> normal partitions. I have large amounts of data on Windows drives that
>> were encrypted by Truecrypt. I run Truecrypt for Linux for access to
>> those drives, but since Truecrypt has ended it’s run, I would like to
>> re-format those drives to Linux filesystems. I have also had problems
>> with very long shut-down times, which I think are caused by Truecrypt
>> refusing to release something in the root filesystem, even after I
>> manually dismounted the drives and quit Truecrypt.
>>
>> My Windows drives are encrypted with a “cascade” of AES, TwoFish, and
>> Serpent. Is there any way to do something similar with Linux
>> filesystems?
>
> Why dont you just use Bitlocker on the Windows drives? Or Symantec
> Encryption Desktop? Those are the 2 most popular technologies nowadays

Bitlocker isn’t cross-platform, probably one significant reason not to
use it if you run multiple operating systems.

Not everyone wants a commercial solution, either - which would be a
reason not to use the Symantec product. Also, that appears to not be
cross-platform, so again, probably a good reason to not use it, since
it’s not really useful for Linux users.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

I am interested in getting away from NTFS altogether. I almost never use Windows any more. I also question the security of “commercial” applications.

Even while runnung the installer from the openSUSE DVD, and choosing ‘expert partition setup’, you are able to select encryption for any partition - which probably only will make sense for your home partition(s) where your private data is stored.

This encryption is free, i.e. it comes with openSUSE - no additional software needed here.

I have used the native openSUSE encryption for a good while. I found the LUKS setup useful because I can access all the volumes (root, home, and swap) with a single password. I also keep the root partition encrypted because of random temp files. But what I am trying to do is encrypt with AES “on top of” TwoFish “on top of” Sword, or something similar. Truecrypt called it “cascading” encryption. I have never found options for the encryption settings when installing. There is only the single checkbox for setting encryption.

I don’t use Windows much. At present, I have a LUKS encrypted partition on linux, which I share with Samba. I use that in Windows for sensitive data (as with filing income tax returns using Windows software).

I have never found options for the encryption settings when installing. There is only the single checkbox for setting encryption.

There are options in “cryptsetup”, though perhaps not the options you want. You can create the LUKS encrypted partition or LVM before you start installing. Then, during install, go to “expert partitioner” mode to use existing partitions.

I’m currently using an encrypted LVM, with everything encrypted except “/boot”.

Personally, I feel that LUKS is great, easy to setup and deploy using the openSUSE packages.

If you’re interested in Truecrypt, there is an effort to address those security issues, YMMV
https://veracrypt.codeplex.com/
http://sourceforge.net/projects/veracrypt/

I’ve only heard of it, haven’t tried it myself.
Online reviews from various seem to be good.

TSU

On 2014-12-26 00:36, purevw wrote:

> My Windows drives are encrypted with a “cascade” of AES, TwoFish, and
> Serpent. Is there any way to do something similar with Linux
> filesystems?

Possibly… if I correctly understand what you mean. But forget YaST.

You would have to encrypt a partition with one method, and it would
appear as device “/dev/mapper/”, which you could encrypt again with
another system. Perhaps. I have never tried this, and it would confuse
the toolset used to mount the devices. You would have to handle it all
yourself.

Unless there is another simpler methodology, but I haven’t investigated.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Thanks for the information. It seems that what I want to do may not be possible with current tools. I see nothing wrong with the default encryption. It’s just that having to crack three 256 bit encryptions in sequence is much more difficult that cracking a single key. The added security is likely not needed and read / write speed on a cascaded drive is considerably slower than a normal drive and taxes the system a bit. I’ll keep an eye on future releases of encryption software. Thanks again everyone.

On 2014-12-28 02:16, purevw wrote:

> Thanks for the information. It seems that what I want to do may not be
> possible with current tools.

As far as I know it may be possible, but not automatically.

/dev/sdXY -> apply crypt one -> get /dev/mapper/cr_1st ->
apply crypt two -> get /dev/mapper/cr_2nd

etc, as many times as you want. But you have to handle the sequence
yourself.

> I see nothing wrong with the default
> encryption. It’s just that having to crack three 256 bit encryptions in
> sequence is much more difficult that cracking a single key. The added
> security is likely not needed and read / write speed on a cascaded drive
> is considerably slower than a normal drive and taxes the system a bit.

Yes, I understand that.

> I’ll keep an eye on future releases of encryption software. Thanks again
> everyone.

Mmm… well, you’d have to suggest the idea to the people that can code
the tools to make it “automatic”. Otherwise it will never happen. If
they are interested, that is. :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

As far as I know, you could:

(1) have an encrypted “/home” or have “/home” in an encrypted LVM;
(2) have a loop mounted encrypted container as home directory.

And that combo is supported, so should work automatically. For an extra step, you could then setup an “ecryptfs” private directory. However, I’m not sure if pam modules would work together for both the loop mounted encrypted container as encrypted home directory and the ecryptfs private directory. So it might need a manual step at each login.

On 2014-12-28 03:56, nrickert wrote:
>
> As far as I know, you could:
>
> (1) have an encrypted “/home” or have “/home” in an encrypted LVM;
> (2) have a loop mounted encrypted container as home directory.

Yes, that would work.

> And that combo is supported, so should work automatically.

It is similar to what I proposed, but mine skips mounting :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-12-28 03:03, Carlos E. R. wrote:
> On 2014-12-28 02:16, purevw wrote:
>
>> Thanks for the information. It seems that what I want to do may not be
>> possible with current tools.
>
> As far as I know it may be possible, but not automatically.
>
> /dev/sdXY -> apply crypt one -> get /dev/mapper/cr_1st ->
> apply crypt two -> get /dev/mapper/cr_2nd
>
> etc, as many times as you want. But you have to handle the sequence
> yourself.

Testing the procedure:



create empty 1 GB file:

Telcontar:/data/storage_c/tmp_borrar # dd if=/dev/zero of=crypta bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.11283 s, 205 MB/s
Telcontar:/data/storage_c/tmp_borrar #

create a loop device for testing, using that file:

Telcontar:/data/storage_c/tmp_borrar # losetup /dev/loop7 crypta
losetup: /dev/loop7: failed to set up loop device: No such file or directory
Telcontar:/data/storage_c/tmp_borrar # modprobe loop
Telcontar:/data/storage_c/tmp_borrar # losetup /dev/loop7 crypta
Telcontar:/data/storage_c/tmp_borrar # losetup -d /dev/loop7
Telcontar:/data/storage_c/tmp_borrar # losetup /dev/loop7 crypta
Telcontar:/data/storage_c/tmp_borrar #


Create encrypted device using that loop device:

Telcontar:/data/storage_c/tmp_borrar # cryptsetup -v --key-size 256 luksFormat /dev/loop7

WARNING!
========
This will overwrite data on /dev/loop7 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
Command successful.
Telcontar:/data/storage_c/tmp_borrar #

Check it:

Telcontar:/data/storage_c/tmp_borrar # losetup -a
/dev/loop7: [66304]:3221269075 (/data/storage_c/tmp_borrar/crypta)
Telcontar:/data/storage_c/tmp_borrar #

Telcontar:/data/storage_c/tmp_borrar # cryptsetup luksDump  /dev/loop7
LUKS header information for /dev/loop7

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      94 e4 e4 66 cb 2f b8 5d 50 73 0d ae 93 b6 d9 0c c5 37 cf c2
MK salt:        57 23 e9 13 25 20 2b f1 7d 9d b4 92 5d 29 0f 60
fa 4d ba 16 a1 26 3c f4 1b 7d 27 23 5b d7 ae c0
MK iterations:  46500
UUID:           6d9f6e56-c079-41dc-8de9-d18632a514bb

Key Slot 0: ENABLED
Iterations:             182335
Salt:                   22 a5 ad 05 97 18 c6 4e d1 5b 9d 00 b0 59 ec 0e
06 1a 0d 92 c8 5f f4 f9 ae 1e bb 80 4c 23 89 21
Key material offset:    8
AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Telcontar:/data/storage_c/tmp_borrar #


Open or activate the encrypted device:


Telcontar:/data/storage_c/tmp_borrar # cryptsetup luksOpen /dev/loop7 cr_nombre
Enter passphrase for /data/storage_c/tmp_borrar/crypta:
Telcontar:/data/storage_c/tmp_borrar # cryptsetup status /dev/mapper/cr_nombre
/dev/mapper/cr_nombre is active.
type:    LUKS1
cipher:  aes-xts-plain64
keysize: 256 bits
device:  /dev/loop7
loop:    /data/storage_c/tmp_borrar/crypta
offset:  4096 sectors
size:    2043904 sectors
mode:    read/write
Telcontar:/data/storage_c/tmp_borrar #

Check it:

Telcontar:/data/storage_c/tmp_borrar # file -s /dev/mapper/cr_nombre
/dev/mapper/cr_nombre: symbolic link to `../dm-2'
Telcontar:/data/storage_c/tmp_borrar # cryptsetup status cr_nombre
/dev/mapper/cr_nombre is active.
type:    LUKS1
cipher:  aes-xts-plain64
keysize: 256 bits
device:  /dev/loop7
loop:    /data/storage_c/tmp_borrar/crypta
offset:  4096 sectors
size:    2043904 sectors
mode:    read/write
Telcontar:/data/storage_c/tmp_borrar # file -s /dev/dm-2
/dev/dm-2: data
Telcontar:/data/storage_c/tmp_borrar #

Second layer attempt.


Telcontar:/data/storage_c/tmp_borrar # cryptsetup -v --key-size 256 luksFormat --cipher aes-cbc-essiv /dev/mapper/cr_nombre

WARNING!
========
This will overwrite data on /dev/mapper/cr_nombre irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
device-mapper: reload ioctl on  failed: Invalid argument
Failed to open temporary keystore device.
device-mapper: remove ioctl on temporary-cryptsetup-8521 failed: No such device or address
device-mapper: reload ioctl on temporary-cryptsetup-8521 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-8521 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-8521 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-8521 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-8521 failed: No such device or address
Command failed with code 5: Input/output error
Telcontar:/data/storage_c/tmp_borrar # file /dev/mapper/cr_nombre
/dev/mapper/cr_nombre: symbolic link to `../dm-2'
Telcontar:/data/storage_c/tmp_borrar # file /dev/dm-2
/dev/dm-2: block special
Telcontar:/data/storage_c/tmp_borrar #

Log:



(cipher aes)

<0.3> 2014-12-31 14:49:59 Telcontar kernel - - - [728137.840264] device-mapper: table: 253:3: crypt: Error allocating crypto tfm
<0.4> 2014-12-31 14:49:59 Telcontar kernel - - - [728137.840268] device-mapper: ioctl: error adding target to table

(cipher aes-cbc-essiv)

<0.3> 2014-12-31 14:50:59 Telcontar kernel - - - [728198.060452] device-mapper: table: 253:3: crypt: Error creating IV
<0.4> 2014-12-31 14:50:59 Telcontar kernel - - - [728198.060456] device-mapper: ioctl: error adding target to table

With keysize 32, I get error


<0.3> 2014-12-31 14:58:20 Telcontar kernel - - - [728638.764782] device-mapper: table: 253:3: crypt: Error decoding and setting key
<0.4> 2014-12-31 14:58:20 Telcontar kernel - - - [728638.764785] device-mapper: ioctl: error adding target to table

Guesses:

wrong cipher (I have always used the default one, and the manual is not clear on available ones).
wrong device? Should it be a mounted filesystem?

The device exists and is writeable:


Telcontar:/data/storage_c/tmp_borrar # dd if=/dev/zero of=/dev/mapper/cr_nombre bs=1M count=900
900+0 records in
900+0 records out
943718400 bytes (944 MB) copied, 5.88488 s, 160 MB/s
Telcontar:/data/storage_c/tmp_borrar #

Concept test of second layer with the same default cipher:


Telcontar:/data/storage_c/tmp_borrar # cryptsetup -v --key-size 256 luksFormat /dev/mapper/cr_nombre

WARNING!
========
This will overwrite data on /dev/mapper/cr_nombre irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
Command successful.
Telcontar:/data/storage_c/tmp_borrar #

Works. So the problem is the syntax. Check


Telcontar:/data/storage_c/tmp_borrar # cryptsetup status cr_nombre
/dev/mapper/cr_nombre is active and is in use.
type:    LUKS1
cipher:  aes-xts-plain64
keysize: 256 bits
device:  /dev/loop7
loop:    /data/storage_c/tmp_borrar/crypta
offset:  4096 sectors
size:    2043904 sectors
mode:    read/write
Telcontar:/data/storage_c/tmp_borrar # cryptsetup status cr_nombre_dos
/dev/mapper/cr_nombre_dos is active.
type:    LUKS1
cipher:  aes-xts-plain64
keysize: 256 bits
device:  /dev/mapper/cr_nombre
offset:  4096 sectors
size:    2039808 sectors
mode:    read/write
Telcontar:/data/storage_c/tmp_borrar #

See? double encryption.


Telcontar:/data/storage_c/tmp_borrar # dd if=/dev/zero of=/dev/mapper/cr_nombre_dos bs=1M count=900
900+0 records in
900+0 records out
943718400 bytes (944 MB) copied, 6.37297 s, 148 MB/s
Telcontar:/data/storage_c/tmp_borrar #

And it is writeable. I skip demonstrating how to mount it, that’s trivial - but not automatic.

Next step would be writing suitable entries in fstab and /etc/crypttab, and find out what happens on boot. I leave that to somebody else :wink:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)