Encrypted FS question

IgnorantGuru · 2009-11-27 18:00:24

I've observed some unusual behavior which I was wondering if someone can explain.

I don't need my entire hard drive encrypted so my habit is to create a small blowfish container just for financial documents and such using the cryptoloop and blowfish kernel modules. Something like:

## Load modules
/sbin/modprobe cryptoloop
/sbin/modprobe blowfish
## Make file "secfilename"
dd if=/dev/urandom of=secfilename bs=1024k count=10
## Set file as target of loop device
losetup -e blowfish /dev/loop0 secfilename
## Make ext3 filesystem
mkfs -t ext3 /dev/loop0
## Mount filesystem
mount -t ext3 /dev/loop0 /mnt/loop
#...
## Unmount, detach, and sync
umount /dev/loop0
## Detach loop device
losetup -d /dev/loop0
sync

Here's my question: A long time ago, when I changed from SUSE to Ubuntu, I could no longer mount the container - it said there was no valid FS on it. So I had to recreate it. This made me question SUSE's blowfish implementation - was it crippled or have a backdoor? Now, years later I have installed Arch, and once again my container wasn't portable. Arch couldn't open Ubuntu's blowfish container. I had to recreate it from scratch with the 'new' blowfish.

Will the real blowfish please stand up.

Needless to say, this makes me question the integrity of these modules. A cryptographic algorithm, if properly implemented, should not be distro-centric. For my purposes it's probably not critical, but what's going on? I can mount my unencrypted ext3 partitions created by Ubuntu fine in Arch. Why are the blowfish modules not compatible? Don't spare me details if you have them - thanks.

jelly · 2009-11-27 18:25:39

maybe the arch version, is different from the ubuntu one?

IgnorantGuru · 2009-11-27 18:34:47

Yes, the SUSE, Ubuntu, and Arch versions of blowfish are certainly different. The question is, why, and does this mean the encryption is not being done properly in two or more of them? FYI, one way to hijack crypto algorithms is to insert zeros in parts of the keys, etc, to make them weaker. One way to reveal this is to use a defferent implementation of the algorithm. For example, in GPG, CAST is CAST. Doesn't matter what piece of software you use, it should be able to decrypt the data encrypted with another. The handling of the containers (or in GPG the packets) can be different, which might be the case here, but I don't understand why that would be either - losetup shouldn't use a different container format between distributions.

Does anyone know who maintains the blowfish kernel module or losetup - it would be an interesting question I'd like to ask them. I don't see it listed as a package.

IgnorantGuru · 2009-11-27 18:42:16

And lest people think 'oh this is a secure program so I'm sure they did it right', that's not a good attitude to take with encryption - you have to be ever-vigilant. I have seen zeroes inserted into the keys of well-known linux software. I saw the code with my own eyes and reported it, and it was corrected. But why was it like that in the first place?

If I suspect any distros, it would be SUSE and Ubuntu more than Arch. But I'd like to know the answer to the mystery.

IgnorantGuru · 2009-11-29 17:01:39

For those interested, I thought I would share this...

I sent my question to those 'kernel people', and it got sent to one of the developers. He gave me this response:

>> Why are the blowfish modules not compatible?

>Have a look at section 2.8 of

> http://loop-aes.sourceforge.net/loop-AES.README

which in turn was written by Jari Ruusu, one of the losetup devs. That document is an interesting read. I can't say I fully understand the issue, even having read it, but it seems some versions used a different key hash. I don't know why Ubuntu's current usage would differ from Arch's current usage (is one using a buggy version still?), but at least they seem to be aware of the issue, which is reassuring.

IgnorantGuru · 2009-11-29 18:39:59

A further reply on this subject from Markus Reichelt is below, indicating there is a security problem involved.

---------------------------------------------------------------------
Re: blowfish and cryptoloop modules question
From: markus reichelt <xxx@xxx>
Date: Sun Nov 29 11:17:29 2009

> >> Why are the blowfish modules not compatible?
>
> > Have a look at section 2.8 of
>
> > http://loop-aes.sourceforge.net/loop-AES.README
>
> Thank you for your reply. I don't want to take your time because
> my understanding of these things is limited anyway, but few people
> understand this. So one more quick question if you don't mind.
> From my reading of that it sounds like the key hash was changed at
> some point, and it alluded to a bug compatibility. Yet why would
> the current Ubuntu usage and the current Arch usage be
> incompatible? Is one distro still using a buggy version of losetup
> or the kernel module, or are they just using different yet equally
> secure implementations?

The official kernel has these problems, and as far as I know nobody
maintains the loop code anymore. So it's just left as is.

Every distro out there is based on the official kernel and because of
this has the same security problems. Some distros, as (old) suse,
changed code of their own. That's why one needs to use a different
kind of hash to access files/containers made on such distros.

If you can, don't use mainline cryptoloop. Use loop-aes or
dm-crypt/luks instead, or truecrypt.

> Or, since I noticed that document was dated Oct 11, 2009, is the
> key hash change very recent such that a container created a few
> months ago is not compatible without the additional mounting
> commands?

No, that has been there for a very long time. And you are not the
only one running into that kind of problem, it pops up on a regular
basis:

http://lists.debian.org/debian-user/200 … 00340.html
http://lists.debian.org/debian-user/200 … 00318.html
---------------------------------------------------------------------------

IgnorantGuru · 2009-11-29 20:29:49

A little more on this...

I just compiled loop-aes and tried to patch it, and I think in the process discovered that Arch doesn't use the mainline cryptoloop in the first place - it seems to already have the AES support from Jari Ruusu. If so, score one for Arch. This is not the case for Ubuntu, which seems to use mainline (read: security bugs) cryptoloop. However, Ubuntu's losetup man page does say it is deprecated in favor of dm-crypt (man cryptsetup), whereas Arch's losetup man page does not say this.

If anyone in the know can confirm this about AES support in Arch's cryptoloop please let me know. I think you can just use

losetup -e AES256 /dev/loop0 filename

bender02 · 2009-11-30 09:29:44

IgnorantGuru wrote:

I just compiled loop-aes and tried to patch it, and I think in the process discovered that Arch doesn't use the mainline cryptoloop in the first place - it seems to already have the AES support from Jari Ruusu. If so, score one for Arch.

That would be quite a surprise, given that arch applies only 2 aufs patches and 3 patches that change the logo to the kernel. See http://projects.archlinux.org/linux-2.6 … ee/patches
That would mean that Ruusu's loop-aes is in the mainline kernel, which would be a great news, but I don't believe it's true.

jac · 2009-11-30 10:20:54

Also quoting from the System Encryption with LUKS for dm-crypt wiki page:

A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.

So, it definitively doesn't.

bender02 · 2009-11-30 11:58:45

Well, while it's a great source for various practical info, wiki should not be taken too seriously. It might be outdated, or just plain wrong - remember that it was written by one of the users - so you can expect about the same level of truth to it as a forum post.

In this case it might be correct, although I personally thing that "much better" and "far more secure" is a bit exaggerated. As far as I know, there is no successful attack against LUKS yet (unless you explicitly use an insecure cipher like aes in ECB mode). Also I haven't seen any serious benchmarks that would compare the two.

IgnorantGuru · 2009-11-30 15:38:02

Thanks for the info. As far as I can tell, there is AES support in Arch's cryptoloop, though. If you attempt to use AES encryption without loading cryptoloop it won't work. And you can load a module named "aes".

From man losetup (default Arch installation):

LOSETUP(8)                  MAINTENANCE COMMANDS                  LOSETUP(8)

NAME
       losetup - set up and control loop devices

SYNOPSIS
...
       -C itercountk
              Runs hashed passphrase through itercountk thousand  iterations
              of  AES-256 before using it for loop encryption. This consumes
              lots of CPU cycles at loop setup/mount  time  but  not  there‐
              after.  In  combination  with  passphrase seed this slows down
              dictionary attacks. Iteration is not done in multi-key mode.

       -d     Detach the file or device associated with the  specified  loop
              device.

       -e encryption
              Enable  data encryption. Following encryption types are recog‐
              nized:

              NONE   Use no encryption (default).
              XOR    Use a simple XOR encryption.
              AES128 AES
                     Use 128 bit AES encryption. Passphrase is  hashed  with
                     SHA-256 by default.
              AES192 Use  192  bit AES encryption. Passphrase is hashed with
                     SHA-384 by default.
              AES256 Use 256 bit AES encryption. Passphrase is  hashed  with
                     SHA-512 by default.

              twofish128 twofish160 twofish192 twofish256
              blowfish128 blowfish160 blowfish192 blowfish256
              serpent128 serpent192 serpent256 mars128 mars192
              mars256 rc6-128 rc6-192 rc6-256 tripleDES
                     These  encryption  types  are  available  if  they  are
                     enabled in kernel configuration or  corresponding  mod‐
                     ules have been loaded to kernel.
...

AUTHORS
       Original version: Theodore Ts'o <tytso@athena.mit.edu>
       AES support: Jari Ruusu

Linux                            2008-10-15                       LOSETUP(8)

And from man swapon:

       If  loop=/dev/loop?   and  encryption=AES128  options  are present in
       /etc/fstab then swapon -a will set up loop devices using random keys,
       run  mkswap  on  them,  and  enable  encrypted swap on specified loop
       devices. Encrypted loop devices are set up with page size  offset  so
       that  unencrypted  swap  signatures on first page of swap devices are
       not touched.  swapoff -a will tear down such loop devices.

FYI, the loop-aes package from sourceforge includes patches for util-linux-ng, including mount, losetup, some other programs, and the associated man pages. It looks like Arch's man pages have these patches in place, and it looks like losetup, swapon, etc have them in place as well. This is not the case with Ubuntu running the same kernel version. In that case, cryptoloop will not accept AES as an encryption type, and the man pages don't even mention it.

So it still looks to me like this loop-aes has been integrated into Arch, including its default cryptoloop kernel module.

But it's also true that when you patch loop-aes yourself, you're supposed to disable cryptoloop in your kernel compile and use loop.ko in the extra folder instead. That doesn't seem to be the configuration in Arch either.

At any rate, the AES encryption tests functional, so it's there. Whether it is done properly I can say. But someone seems to have gone to the trouble of integrating some version of it, and it has Ruusu's name on it right in the man page (just like his sourceforge patches).

IgnorantGuru · 2009-11-30 16:07:34

Also, the test script in the sourceforge package (make tests) ran with almost no errors, indicating the driver was performing correctly, even though I was using the default Arch cryptoloop. The only error was an IO error at the end, but it wasn't related to a bad encryption/decryption - those tests on AES passed.

.:B:. · 2009-11-30 16:16:04

IgnorantGuru wrote:

A little more on this...
I just compiled loop-aes and tried to patch it, and I think in the process discovered that Arch doesn't use the mainline cryptoloop in the first place - it seems to already have the AES support from Jari Ruusu. [...]
If anyone in the know can confirm this about AES support in Arch's cryptoloop please let me know.

Arch hasn't loop-AES built in. I used to have my data partitions on loop-AES, and either you need to patch the kernel or build a new loop module (as per the loop-AES author's instructions) to use loop-AES. Arch does have support for loop-AES in its util-linux-ng package (which otherwise you would have had to rebuild too). If you want I can link you to my all-in-one patches for a few 2.6 kernels up to 2.6.31 (tried and tested in case you worry, with a 3 TB RAID 5 ). The patches the author provides require you to do some stuff manually still, hence why I amended it.

IgnorantGuru · 2009-11-30 16:52:48

Can you explain the difference between the loop-aes support in Arch's util-linux-ng package and the loop-aes from sourceforge? Is there a compelling reason not to use the built-in support? And why does loading the cryptoloop module enable AES encryption if it's not built-in? I'm just trying to get a handle on what the components involved are.

I'd like to see the patches but I'm not sure I'm ready to undertake that. Thanks.

bender02 · 2009-11-30 17:06:19

AFAIK, for using loop-aes you need two separate things:
- kernel support (= the patched loop.ko module; is *not* done in arch by default)
- userspace support, so that you can actually mount, create and manipulate the encrypted containers (= patched util-linux-ng, which *are* supplied by default in arch)

cryptoloop needs the same two things, except the kernel support is an extra module (called cryptoloop.ko).
AES is just a type of a crypto algorithm that is widely used in various things. This algo is used in the loop-aes implementation, apparently also in cryptoloop implementation; and is default in LUKS (although there you can choose some other ones). It also matters *how* is it used (the so-called "mode"). In cryptoloop it is used in ECB (electronic code book) mode, which was shown to be relatively easily crackable. The other two modes are I think "plain" and "XTS", with the XTS to be recommended.

IgnorantGuru · 2009-11-30 17:13:55

bender02 wrote:

In cryptoloop it is used in ECB (electronic code book) mode, which was shown to be relatively easily crackable. The other two modes are I think "plain" and "XTS", with the XTS to be recommended.

Thanks for the explanation. It's shameful the way they build only broken and weak encryption into the linux kernel.

One thing I still don't understand is why the 'make tests' function from the loop-aes package passed most of the encryption tests. It seemed to be testing the encryption and the result, so I would think it would have detected the difference caused by the ECB mode. If there any easy way to tell which mode cryptoloop is using?

And what algorithm or method, available in a default Arch install, would you recommend? Markus suggested "Use loop-aes or dm-crypt/luks instead, or truecrypt."

bender02 · 2009-11-30 20:10:41

IgnorantGuru wrote:

One thing I still don't understand is why the 'make tests' function from the loop-aes package passed most of the encryption tests. It seemed to be testing the encryption and the result, so I would think it would have detected the difference caused by the ECB mode. If there any easy way to tell which mode cryptoloop is using?

If it was testing the encryption, then it of course works, arch kernel comes with all the crypto algorithms available in the kernel. The can be all available at the same time, it's just a matter of each program what it uses. 'cat /proc/crypto' tells you what hash/crypto algos you have available right now, for more you can load the appropriate kernel modules. For instance, 'sudo modprobe blowfish' loads the blowfish module, and then it will appear in /proc/crypto. This way, you can have simultaneously mounted and using some cryptoloop container, loop-aes container and LUKS container, with the same, or different ciphers.

I don't know of any way of telling what does cryptoloop use, apart from looking at its source code.

IgnorantGuru wrote:

And what algorithm or method, available in a default Arch install, would you recommend? Markus suggested "Use loop-aes or dm-crypt/luks instead, or truecrypt."

- I personally use dm-crypt/luks - it's easy to set up and supported by arch out-of-the-box. See the wiki.
- loop-aes has the disadvantage of having to maintain an extra kernel - but as the wiki says, it's probably slightly "more secure" and faster, so if you're up to it, ask B how does he do it
- truecrypt has nothing to do with kernel, it runs entirely in userspace. I don't want to rely on third party apps, but otherwise it's also OK.
As far as ciphers go, the defaults will all the three above are fine (although I use aes-xts-plain instead of the default aes-cbc-essiv with luks, but I can't really tell the difference, I've never looked into it.)

.:B:. · 2009-11-30 21:20:00

IgnorantGuru wrote:

Can you explain the difference between the loop-aes support in Arch's util-linux-ng package and the loop-aes from sourceforge?

There is no difference... You need both the patched util-linux-ng and a loopback module that supports loop-AES.

Is there a compelling reason not to use the built-in support?

There *is* no builtin support. Check the default kernel PKGBUILD.

And why does loading the cryptoloop module enable AES encryption if it's not built-in? I'm just trying to get a handle on what the components involved are.

I'm sure it's possible to use AES somewhere. After all, WPA2 uses AES too. Just because you AES doesn't mean it's loop-AES though.

As bender02 says, loop-AES requires kernel modifications (either replacing the loop module or building a whole new kernel), I build my own kernels - hence the patch.

The benefit of loop-AES is that your keys are scrambled in RAM, while most other encryption schemes on Linux allow you to recover keys even after a reboot (whereas the scrambling loop-AES applies prevents that). Of course it's up to you to decide whether that's what you want - but IMHO you should pick an encryption scheme that is as complete as possible. If your data *is* sensitive and someone gets to lay his hands on it you can be sure they'll know how to compromise the encryption scheme. Keys being accessible in RAM (and recoverable) is not something new.

IgnorantGuru · 2009-11-30 22:00:53

Thanks for the additional info.

soloport · 2010-01-05 00:03:14

bender02 wrote:

AFAIK, for using loop-aes you need two separate things:
- kernel support (= the patched loop.ko module; is *not* done in arch by default)
- userspace support, so that you can actually mount, create and manipulate the encrypted containers (= patched util-linux-ng, which *are* supplied by default in arch)

Here's a PKGBUILD patch -- sort of.

milomouse · 2010-01-05 22:47:40

In kernel 2.6.33 I noticed it now asks about loop-aes support built-in and the default is "Y"es (feature says (NEW)). Is this the same as the sourceforge loop-aes we're talking about? I guess you'd still need to patch util-linux-ng as per soloport's PKGBUILD link which I must've missed before.

soloport · 2010-01-06 11:53:45

milomouse wrote:

In kernel 2.6.33 I noticed it now asks about loop-aes support built-in and the default is "Y"es (feature says (NEW)). Is this the same as the sourceforge loop-aes we're talking about? I guess you'd still need to patch util-linux-ng as per soloport's PKGBUILD link which I must've missed before.

CONFIG_CRYPTO_AES=y

Is part of the Cyphers section. (Often relatively old settings still say "(NEW)".) Block loop device must be un-set to support loop-AES.

# CONFIG_BLK_DEV_LOOP is not set

i.e. kernel 2.6.33 requires same traditional treatment.

milomouse · 2010-01-06 21:32:09

Well, it shows:

Symbol: BLK_DEV_LOOP_AES [=y]
Prompt: AES encrypted loop device support
  Defined at drivers/block/Kconfig:251
  Depends on: BLK_DEV [=y] && BLK_DEV_LOOP [=n]
  Location:
    -> Device Drivers
      -> Block devices (BLK_DEV [=y])
        -> Loopback device support (BLK_DEV_LOOP [=n]

And I also see BLK_DEV_LOOP_KEYSCRUB [=y]. These are the values I selected, I believe the defaults are "N"o for loop-aes and keyscrubbing. I'm using kernel26-2.6.33-rc2 also with zen patches.

soloport · 2010-01-07 01:34:31

milomouse wrote:

I'm using kernel26-2.6.33-rc2 also with zen patches.

Zen Patches include the following patch:

{drivers/block/Kconfig}

          Most users will answer N here.

-config BLK_DEV_CRYPTOLOOP
-       tristate "Cryptoloop Support"
-       select CRYPTO
-       select CRYPTO_CBC
+config BLK_DEV_LOOP_AES
+       bool "AES encrypted loop device support"
+       depends on BLK_DEV_LOOP
+       ---help---
+         If you want to use AES encryption algorithm to encrypt loop
+         devices, say Y here. If you don't know what to do here, say N.
+
+config BLK_DEV_LOOP_KEYSCRUB
+       bool "loop encryption key scrubbing support"
        depends on BLK_DEV_LOOP
...etc.

OrangeRoot1000 · 2010-01-14 00:48:55

Three excellent tools in the Linux tool chest that are:

Totally portable
Totally Xplatform
Easy to implement

Encfs/Fuse/SSHFS -- this is container size encryption -- fast
Bcrypt.. xplatform, fast one line command to encrypt file
GPG - Most ppl overlook this but it's very handy on smaller files and folders, you can "sign" any documentyou recieve to know teh origins. It is NOT good for large files.

I hae gone with ALL 3 apps from 6 different distros, gone to bsds and back and NEVER, knock on wood lost any data.

Arch Linux

#1 2009-11-27 18:00:24

Encrypted FS question

#2 2009-11-27 18:25:39

Re: Encrypted FS question

#3 2009-11-27 18:34:47

Re: Encrypted FS question

#4 2009-11-27 18:42:16

Re: Encrypted FS question

#5 2009-11-29 17:01:39

Re: Encrypted FS question

#6 2009-11-29 18:39:59

Re: Encrypted FS question

#7 2009-11-29 20:29:49

Re: Encrypted FS question

#8 2009-11-30 09:29:44

Re: Encrypted FS question

#9 2009-11-30 10:20:54

Re: Encrypted FS question

#10 2009-11-30 11:58:45

Re: Encrypted FS question

#11 2009-11-30 15:38:02

Re: Encrypted FS question

#12 2009-11-30 16:07:34

Re: Encrypted FS question

#13 2009-11-30 16:16:04

Re: Encrypted FS question

#14 2009-11-30 16:52:48

Re: Encrypted FS question

#15 2009-11-30 17:06:19

Re: Encrypted FS question

#16 2009-11-30 17:13:55

Re: Encrypted FS question

#17 2009-11-30 20:10:41

Re: Encrypted FS question

#18 2009-11-30 21:20:00

Re: Encrypted FS question

#19 2009-11-30 22:00:53

Re: Encrypted FS question

#20 2010-01-05 00:03:14

Re: Encrypted FS question

#21 2010-01-05 22:47:40

Re: Encrypted FS question

#22 2010-01-06 11:53:45

Re: Encrypted FS question

#23 2010-01-06 21:32:09

Re: Encrypted FS question

#24 2010-01-07 01:34:31

Re: Encrypted FS question

#25 2010-01-14 00:48:55

Re: Encrypted FS question

Board footer