Item — HN Reader

I don't get the title.

The title tells me I don't want XTS.

Then the post explains that I don't want FDE, for sundry reasons. Then it tells me, sure, go ahead and use FDE, but be aware of the limitations.

At that point it looks like I want XTS, after all.

Then it shows how XTS works and where cryptographers are seeing problems.

And then... well, there is no "then". The recommendations don't deal with FDE at all.

I think the post would be much stronger, if it either had some alternative mode to present or (I'd be more interested in that) it showed other ways to achieve what people usually try to achieve with FDE. And usability is a big one there. Bitlocker is huge. FileVault is huge. People can actually use it.

An aside: Has anyone ever seriously used XTS mode for anything but FDE? I've only encountered it in Truecrypt and the part of Boneh's Crypto I where he's talking about FDE. But that doesn't mean much, I admit.

2 comments

The post ends with the takeaways I'm hoping for:

1. Try not to rely on FDE at all.

2. For God's sake don't use XTS for anything other than FDE.

There's an encrypted filesystem guy that suggested they were moving to XTS. That's what prompted the post.

Usability is great. I think you should turn FDE on. But turning on FDE buys you a lot less than you think it does. There's a pretty good chance that FDE isn't going to do anything for you if your computer is seized by the FBI, because the key will probably resident when they do that.

You don't want XTS, in general, because you don't want to turn a simpler problem (safely encrypting your secrets) into a hard problem (simulating hardware encryption).

Do you know if there are any effective forensic attacks in use against the TRESOR design?

(I was one of the authors of the cold boot paper at USENIX Security, but I haven't followed the subsequent history of attacks and defenses very consistently.)

TRESOR is only effective against passive forensics and only protects key material.

It does not protect against an attacker able to manipulate memory contents through, say, DMA or other malicious devices.

Hi Steve,

I remember the DMA situation from a few years ago being quite bad, and it looks like you or one of your colleagues has posted some good resources on that at

http://privatecore.com/resources-overview/physical-memory-at...

I realize that with PrivateCore you're taking quite a comprehensive approach to this problem and not bothering with more piecemeal counterforensic approaches, but I'm still curious about what counterforensic techniques exist for people who aren't going as far as you are. For example, can we make stock Linux deny memory access on external buses with a software policy, or is this simply not something that can be accomplished from software?

I imagine you have good arguments for why the piecemeal approach is likely to fail in the face of an skilled forensic attacker. But many of the attacks that you described to me when we last talked about this were more along the lines of hardware-assisted Evil Maid attacks in an unmonitored and unsupervised colo, rather than forensic attacks against an unmodified encrypted laptop. I'm curious about how different the threat scenarios are between these two cases now.

Enabling IOMMU is one relatively easy software mitigation to DMA attacks. There are some gaps, but it stops the trivial cases where a device can access all of memory.

> [IOMMU:] There are some gaps

Do you happen to have a link where I can read more about those?

In practice, many encrypted filesystems already use encryption that's strictly worse than XTS, and they generally use the same block-based model as full disk encryption for exactly the same performance reasons.

Okay, so I seem to have gotten the gist of it.

Still, I want XTS. :-)

If I was hoping to persuade someone other than a potential crypto designer, I probably wouldn't have tried to explain the XEX tweak. :)

Every developer is a potential crypto designer. Alas, quite a few of them turn out to actually design crypto. Not everyone is reading HN. ;-)

I agree. Although the article content is good and reaches a good, nuanced conclusion, the title is going to confuse people. Many people will only ever encounter XTS when setting up full disk encryption with dm-crypt, where they'll be presented with the choice between XTS and CBC-ESSIV. This is already a confusing choice with no good context to help a user make a decision. Remembering this headline, I bet some people are going to pick CBC-ESSIV over XTS, which is wrong.

The title is also somewhat link-baity, since I clicked expecting bombshell revelations about XTS. I suggest the mods to change it to "You don't want XTS (except for full disk encryption)."

Since the article doesn't really endorse XTS in any context, I'm not sure your proposed title is accurate.

I didn't write the article for the front page of HN. I wrote it so that the next time someone says "we're going to switch from CBC to something more advanced like XTS", I can point them at the article instead of writing a long comment.

> Since the article doesn't really endorse XTS in any context, I'm not sure your proposed title is accurate.

But it's also not saying that you shouldn't use XTS for full disk encryption. In fact it seems to say it's probably OK for full disk encryption: "It’s certainly better than ECB, CBC, and CTR for FDE. For the crappy job we ask it to do, XTS is probably up to the task."

> I didn't write the article for the front page of HN. I wrote it so that the next time someone says "we're going to switch from CBC to something more advanced like XTS", I can point them at the article instead of writing a long comment.

Understood. Unfortunately it's on the front page of HN now and I think it (the HN article) needs a better title considering the audience.

My issue with your proposed title is that it endorses disk encryption. People should use FDE, but FDE sucks.