[hadoukenio]

I chose eryptfs over TrueCrypt because I wasn't happy with using encryption software written by an anonymous developer. Was this a naive decision or do others feel the same?

The audit linked says that it ecryptfs might not have been designed/written by a cryptographer. What would people recommend these days seeing as TrueCrypt is likely to be compromised and ecryptfs might not be as secure as it could be?

[tptacek]

EcryptFS and Truecrypt are very different systems.

Truecrypt is simulated hardware encryption. It creates a virtual encrypted hard disk, which your operating system can more or less treat like an ordinary hard disk, but for the kernel hooks Truecrypt adds to lock and unlock the disk.

EcryptFS is an encrypted filesystem. Unlike Truecrypt, which encrypts individual disk blocks, systems like EcryptFS encrypt and decrypt whole files.

All else being equal, you'd prefer an encrypted filesystem to a simulated encrypted hard disk. Some of the reasons are technical: the crypto involved in encrypting a block device is crappier than the crypto involved in protecting a file (most notably, block crypto is typically not authenticated). But at a higher level, the reason is that you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.

All things are not equal though, and to select EcryptFS over Truecrypt, you also have to select EcryptFS's design and implementation over Truecrypt's. Truecrypt's design is simple and has been looked at more carefully than EcryptFS's. On the other hand, Truecrypt is an XTS cryptosystem, which isn't great. I would have a hard time making a recommendation between the two.

It's more important that you understand the limitations of transparent disk encryption. Unless you are pretty regularly telling your crypto software that it's OK to unlock a given file or disk or whatever, then it's probably "always on", and your keys are always resident in memory, and your files are more or less always exposed to malware. Malware is a much scarier threat (for most people) than police raids.

If you're interested: we work in a pretty high-risk environment (we handle a lot of hazmat). Our general crypto regime at Matasano is:

* Everyone uses Filevault2's native XTS disk encryption (along with some fiddly rules for what state your machine needs to be in if it's in your bag).

* Everyone uses OS X encrypted DMGs (I don't remember what the block crypto design for DMGs is, but you can check out John the Ripper if you're curious) to isolate different projects; we audit machines to make sure keys aren't in the keyring.

* Everyone uses PGP for email and to encrypt specific files.

If this sounds like a pain in the ass, be aware that this is pretty close to the minimum viable amount of security you can be providing a mobile device; if you're skipping one of these steps, you should know why.

[wyager]

>All else being equal, you'd prefer an encrypted filesystem to a simulated encrypted hard disk.

I disagree for these reasons:

1. This decreases composability. With encrypted filesystems, I can't mix and match filesystems and cryptosystems to suit my needs. There is no reason they need to be convolved.

2. This increases complexity. Now, the person writing the software has to be an expert in both filesystems and cryptosystems if they want to do a good job. There is more room for error. (You might say it violates the UNIX philosophy of "do one thing and do it well".)

3. This leaks information to an attacker. They know the layout of my files even without my password. I'm more comfortable with absolutely everything looking like a giant monolithic block of random data.

[tptacek]

There's nothing I can say in response to this comment that I haven't already said upthread and here:

http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

[wyager]

Thanks for the link. Those are some very valid points.

[tptacek]

Of course, there's some validity to the "composability" point, which is why we use both full-disk encryption and encryption at the filesystem layer. I don't think enabling full-disk encryption is a bad thing. Having full-disk encryption is what allows me not to panic if I leave my laptop in the unlocked back seat of my car; I don't have to worry about what state the filesystem was in, because the whole disk is locked.

[pbsd]

Do you guys only use OS X over there, or are there equivalent setups for other systems?

[tptacek]

The iSEC people use Windows and Linux, but I don't know what they use for encryption. Everyone at Matasano is on OS X.

[atmosx]

What kind of encryption do you use at Matasano?

You use the build-in disk image encrypted volumes (AES-128/256 IIRC), or some proprietary software? Do you have a standard policy (e.g. FileVault) or no?

[dchest]

See the bottom of the grand-grandparent comment https://news.ycombinator.com/item?id=8059218

[atmosx]

thanks

[hadoukenio]

That's a great explanation. Thanks for that. Now I'm curious about why it's so locked down at Matasano... what are the main threats to need full-disk encryption and then multiple encrypted containers per project?

I should have explained my reasoning for originally choosing ecryptfs. I find it really convenient doing a backup of ecryptfs' cipher-text. Since it's simple files, an rsync will do. If I wanted to backup virtual encrypted disks, I would first have to mount source and destination to do an rsync, or painstakingly do an entire dd without the mount... maybe I'm just doing it wrong?

[wglb]

First protection is against laptop being stolen and the hazmat is exposed.

Separate vaults are useful if you have multiple clients, say, and you are doing pen tests. While you are working on one, the others are not unlocked.

[objectivefs]

For laptops it might be easier to avoid storing any of your sensitive data to disk.

Use a non-local encrypted filesystem per project to get the isolation and to avoid your local storage. Mount the project filesystem when needed, unmount it when done, and when not in use it is simply inaccessible to the laptop.

While any encrypted filesystem not stored on your laptop would work for this, ours[1] makes this workflow very easy.

[1] https://objectivefs.com

[ynniv]

block crypto is typically not authenticated

Is this simple oversight?

you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.

Doesn't this leak information? An attacker knows very little about an opaque block, but may be able to use file length and modification order to some advantage.

[tptacek]

No, it's not simple oversight. Here's my best stab at an explanation:

http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Regarding information leakage: both schemes leak some degree of information (for reasons I get into in that post, XTS is deterministic). But because encrypted filesystems don't have to respect strict block boundaries, they can do a variety of things to limit or eliminate leakage. It's much harder for block device crypto to solve this problem.

Naive encrypted filesystems don't, of course. Like I said, I'd have a hard time making a recommendation between Truecrypt and EcryptFS.

[ynniv]

Regarding authentication it only mentions performance and block failure. It seems that your company does use encrypted DMGs, so are these problem mitigated by having a larger encrypted unit size and reliable data storage?

[tptacek]

Think about it. How do you authenticate a block device?

Do you:

(a) Authenticate the ciphertext of the whole device as a unit? So, any time you update any block on the entire disk, you also need to update the MAC tag? What happens if you do that? Any block corruption occurring anywhere on the device breaks the MAC tag for the entire disk.

(b) Authenticate each individual sector? Where do you store the MAC tags? There's an awful lot of sectors on a disk. Also: what does it mean to have a single corrupted sector in a file consisting of many sectors?

(c) ???

Of course, the answer is that full-disk encryption tools (ie simulated encrypted disks, like Truecrypt) don't authenticate. There's no good place to store the tags and no good units of data to authenticate.

What does it mean that encrypted disk sectors aren't authenticated? Well, it means two things:

(i) Attackers can perform targeted rewrites of data on the disk, typically at a full-sector level; in practice, this means that they can randomize any sector of the disk, and the encryption software can't know that the now-random data isn't real data, nor can the operating system. By aiming these random blocks at trusted metadata or executable binary code, attackers can potentially turn this ability into a much more serious attack.

(ii) Because the encryption software must trust the outcome of decryption, even when attackers tamper with data to make its output random, attackers gain the ability to feed chosen ciphertext into the encryption software. This sounds like an academic concern, but it's the basis for many of cryptosystem attack classes we've learned about in the past decade, most notably the padding oracles.

[mhogomchungu]

>Authenticate each individual sector? Where do you store the MAC tags? There's an awful lot of sectors on a disk. Also: what does it mean to have a single corrupted sector in a file consisting of many sectors?

openbsd does this with their geli tool[1]. Look at the tool's documentation for the "-a" option.

The authentication stuff are stored on the sector itself. I remember looking at their implementation a while ago but cant seem to be able to dig up the documentation link at the moment.

[1] http://www.freebsd.org/cgi/man.cgi?query=geli&sektion=8&manp...

[Khaine]

Do you guys use anything to manage your encrypted DMGs (like knox https://agilebits.com/knox)?

[daeken]

I can't speak to their current setup, but when I was there, pretty much everyone used Knox. Great app.

[bignaj]

Well, TrueCrypt (controversially) recommended BitLocker... that seems to be one of the few options left. Disclaimer: I work for Microsoft in a non-related division but I feel like if it's good enough to protect enterprise customers' secrets it's good enough for my personal use outside of work. You are free to use whatever you like, of course. The HN neckbeard illuminati will likely disagree with me, already aware of this. To each his/her own.

[fluidcruft]

BitLocker has the advantage of being accepted by my employer and now that XP was banished in favor of Win7 it's available on all of the company computers.

It has the extreme disadvantage that I can't mount my disk on anything except windows. Which is a no-go given that I mostly live in Linux and most of my colleagues do a lot of work with MacOS. We all have Windows machines for the bureaucratic stuff we must do (word documents, excel, various internal web portals that require IE or some sort of ActiveX plugin). The things is: when it comes to closed source companies, Microsoft is one that I am willing to accept that they have sound engineering and release policies. But they refuse to explain how it works, so we can't inter-operate and we have to do something else.

(Which for me means that I use a FIPS certified hardware encrypted USB drive with a built in keypad that you use to enter a pin, but for everyone else it basically means they don't bother and just use stupid unencrypted FAT drives and don't care if they "get caught". Or they try to use the awful Box sync shit IT is currently trying to foist on us)

[tux1968]

You should be able to mount BitLocker volumes under Linux with Fuse:

    https://github.com/Aorimn/dislocker

[bignaj]

Just to add some perspective... for most of the world lack of support for Linux isn't an extreme disadvantage. For most it's not a disadvantage at all. I have a Linux machine and use Linux servers just like you, but welcome to the HN bubble...

[Dylan16807]

That disclaimer really detracts from your post.

But on topic, BitLocker is only suitable for enterprise because it's simply unavailable for home versions.

[eli]

No, it's available on the "Ultimate" edition of windows too, which is for home use. Many higher-end Windows machines come with it already installed.

[bignaj]

I agree, but I feel like it's only fair to report any potential conflict of interest (come from a research background where this is standard). You are also incorrect: Bitlocker is not only available for enterprise versions. See the other reply to your comment :)

[Dylan16807]

It's not that you have a disclaimer, it's that you're being hostile in it.

Ultimate is a weird expensive combined edition that doesn't even exist for Windows 8. I didn't think I had to specifically exclude it, but I definitely don't accept it as making BitLocker available for 'home versions'

[x1798DE]

>What would people recommend these days seeing as TrueCrypt is likely to be compromised and ecryptfs might not be as secure as it could be?

Just to push back on this a bit, I don't think it's particularly likely that TrueCrypt is in any way compromised. It's been stable software for quite some time now, it's open source, and there have been no identified flaws with it. The main problem with TrueCrypt is that it may be nearing the end of its useful life as filesystem technology changes and TrueCrypt is not updated along with it (this has already happened with GPT/UEFI and TrueCrypt's full-disk encryption). If TrueCrypt will work for you, at the moment you don't really have to worry that it's been compromised or worry about "lack of support" (note it hadn't been updated for over two years before the abrupt departure of the anonymous devs).

It's quite possible that you won't even run into any compatibility issues in the future, as future encryption tools will likely offer support for TrueCrypt volumes - once the phase II (crypto) audit is complete, assuming no major flaws are found, it will be a vetted, open technology, so it'd be a no-brainer to write an implementation based on it.

[tptacek]

I'm involved in the TC audit, and zero of the people I know that are working with the TC audit believe that it's compromised.

[mhogomchungu]

TrueCrypt in linux has a serious security issue discussed below and i hope you guys will address this.

TrueCrypt has a serious security bug that allows a person who can mount TrueCrypt volumes to get root shell or run any command as root user because it mount its volumes with "suid" option instead of "nosuid" option.

You can get the below program to test locally if you have a linux box around.

http://pastebin.com/vT4G7nU0

[simoncion]

> 4. set the binary to have 4755 permissions with owner as root:root.

If you can do this, you already have root access. If you have root access, then you don't need dirty tricks to get root access.

Additionally, in the three minutes that I spent searching, I found a bunch of evidence that indicated that TrueCrypt volumes mounted through FUSE are mounted with the nosuid option. (Ferinstance, search for 'nosuid' here: http://www.reddit.com/r/archlinux/comments/1fcwvr/truecrypt_... )

[mhogomchungu]

Reads the instructions again

At step 4,you create the volume on the computer you have root access(a home computer for example),copy the program and set up necessary permission on the program

At step 5,you take the "hot" volume to another computer where you do not have root access to(like a friend's computer).On this friend computer,you open the "hot" volume and then run the suid-root program to gain root shell or run any other root command your prefer.

In a nutshell,if you are on linux and you have TrueCrypt installed,give me your computer to open my TrueCrypt volume and i can get root shell in seconds.No kidding.

The link i provided gave source code to test the exploit,if you cant or prefer not to,the check below link that speaks of the same exploit

http://vinicius777.github.io/blog/2014/07/14/truecrypt-privi...

[simoncion]

I cannot repro. See this transcript:

http://pastebin.com/y958QtWh

By the way:

  $ man mount
  MOUNT(8)                     System Administration                    MOUNT(8)

  NAME
       mount - mount a filesystem

  SYNOPSIS
  <snip>
       defaults
              Use default options: rw, suid, dev, exec, auto, nouser, and async.
  <snip>

[wglb]

How is this different than creating a disk with appropriate properties and handing it to a gullible system operator to mount the physical device?

[mhogomchungu]

Its not.

A user provided volume/device should always be mounted with "nosuid,nodev" options,some people will add "noexec" into the mix but i find it not to be very useful.

Most "sane" mount front ends will also not mount any arbitrary file system on these user provided volumes/devices.They will only mount file systems they explicitly allow and file systems that are already known by the system ie file systems whose modules are already loaded.This is done to prevent misuse of mount to load kernel modules that are not already loaded.

The problem is with what options were used with mount command and TrueCrypt uses bad options.Here,TrueCrypt is used not for its encryption feature,but for its bad mount command usage.Any other tool with the same bad usage will do in carrying out the exploit.

[wglb]

So perhaps TrueCrypt in linux has a serious security issue should be changed to read Linux has a serious security issue

Doesn't sound particular to TrueCrypt.

I remember fielding a support call from a customer running Coherent on the Commodore Z8000 system who fabricated a floppy with pretty much the same properties--used a user-space program to create a floppy with setuid and then mounted it.

Doesn't sound like TrueCrypt's problem.

[tptacek]

I'm only involved in the cryptography stuff.