[dm-crypt] aes-256-xts on a 2.5TB volume ... How much trouble am I in?

[dm-crypt] aes-256-xts on a 2.5TB volume ... How much trouble am I in?

[Christian Pernegger]

Hi all,

I've recently finished setting up our new file server, whose largest
filesystem is 2.5TB in size; ext3 on dm-crypt (aes-256-xts) on lvm on
md-raid5. The setup seems fine, but googling for an unrelated
performance problem brought to light some disconcerting news:

1) xts becomes more insecure the larger the encrypted volume is and is
thus not recommended for volumes >1TB. Great. How bad is this in my
case on a "makes cracking the encryption easier in theory" -- "any
scriptkiddie can do it in 5 seconds" scale?

2) Something about *-plain being 32 bit only and thus limited to 2TB.
What happens to data over 2TB? Less secure, not encrypted at all, kiss
it goodbye?

I can't recreate the mapping with different settings easily, since
I've already copied the data over and dismantled the old server but of
course everything depends on how bad this is ...

Thank you for your help

Chris

Re: [dm-crypt] aes-256-xts on a 2.5TB volume ... How much trouble am I in?

[Arno Wagner]

On Sun, Sep 13, 2009 at 09:46:23PM +0200, Christian Pernegger wrote:
> Hi all,
> 
> I've recently finished setting up our new file server, whose largest
> filesystem is 2.5TB in size; ext3 on dm-crypt (aes-256-xts) on lvm on
> md-raid5. The setup seems fine, but googling for an unrelated
> performance problem brought to light some disconcerting news:
> 
> 1) xts becomes more insecure the larger the encrypted volume is and is
> thus not recommended for volumes >1TB. Great. How bad is this in my
> case on a "makes cracking the encryption easier in theory" -- "any
> scriptkiddie can do it in 5 seconds" scale?

Likely in the "makes breaking it a few millions cheaper but 
leaves plenty" class. Also, you need to think about what your 
attacker model is. For example: If they cannot walk out with 
the disks, will transferring 2.5TB over the net be noticed?

> 2) Something about *-plain being 32 bit only and thus limited to 2TB.
> What happens to data over 2TB? Less secure, not encrypted at all, kiss
> it goodbye?

No idea. I would assume a sane implementation that reports
an error on access attempts past the limit, but worst case
is a wrap-around and overwrite of data at the beginning.
 
> I can't recreate the mapping with different settings easily, since
> I've already copied the data over and dismantled the old server but of
> course everything depends on how bad this is ...

Well, you can always use your backup procedure to move the data 
off and put it back on under new encryption. You do have backup, 
right?

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

Re: [dm-crypt] aes-256-xts on a 2.5TB volume ... How much trouble am I in?

[Mario 'BitKoenig' Holbe]

Christian Pernegger <pernegger@gmail.com> wrote:
> Hi all,
>
> I've recently finished setting up our new file server, whose largest
> filesystem is 2.5TB in size; ext3 on dm-crypt (aes-256-xts) on lvm on
> md-raid5. The setup seems fine, but googling for an unrelated
> performance problem brought to light some disconcerting news:
>
> 1) xts becomes more insecure the larger the encrypted volume is and is
> thus not recommended for volumes >1TB. Great. How bad is this in my
> case on a "makes cracking the encryption easier in theory" -- "any
> scriptkiddie can do it in 5 seconds" scale?

Regarding this you could have a look at a mail from Jonas Meurer to this
list with Message-ID: <20080902122833.GF29731@resivo.wgnet.de> where he
forwards a mail from Micah Anderson to pkg-cryptsetup-devel@:

| According to the IETF NIST submission[0] for the tweakable block
| cipher xts (and I paraphrase here, as the document prohibits direct
| quotation): the proof yields strong security guarantees as long as the
| same key is not used to encrypt much more than 1 terabyte of data. Up
| until this point, no attack can succeed with probability better than
| approximately one in eight quadrillion. However this security
| guarantee deteriorates as more data is encrypted with the same
| key. With a petabyte the attack success probability rate decreases to
| *at most* eight in a trillion, with an exabyte, the success
| probability is reduced to *at most* eight in a million.

So, I would say that you are not in that big trouble with a 2.5T volume.
However, when "scriptkiddies" are in your attack vector, the more
important question arises: what do you expect them to be able to do?
When they are able to hack into your system, they simply have your key.

> 2) Something about *-plain being 32 bit only and thus limited to 2TB.
> What happens to data over 2TB? Less secure, not encrypted at all, kiss
> it goodbye?

the data above 2T is less secure but all data is less secure.
It is encrypted, it does not get lost and it does not overwrite other
data.


regards
   Mario
-- 
Evidently men are more intelligent than women. Every woman on earth
believes that men should be able to read minds. Every man knows this
is impossible. Ergo, we are more intelligent.

Re: [dm-crypt] aes-256-xts on a 2.5TB volume ... How much trouble am I in?

[Christian Pernegger]

>> I've recently finished setting up our new file server, whose largest
>> filesystem is 2.5TB in size; ext3 on dm-crypt (aes-256-xts) on lvm on
>> md-raid5.

For the record, that should be aes-512-xts throughout ...

> Also, you need to think about what your attacker model is.

Not a very sophisticated one. Encryption enables me to RMA/sell/give
away disks with reasonable expectation that the data on them won't be
read. Since we're tight on space the server isn't as physically secure
as I'd like. I doubt anyone could walk off with it without my
knowledge, but rebooting into a root shell would be possible.

> Well, you can always use your backup procedure to move the data off and put it back on under new encryption.

I could, but it's a real PITA :)

> the data above 2T is less secure but all data is less secure.
> It is encrypted, it does not get lost and it does not overwrite other
> data.

To be honest, I couldn't quite parse that one, but the gist of it
seems to be positive. I'll leave the box as-is for the moment and see
if I can't do something about that performance problem first, lest I
have to redo the whole thing twice.

Thanks for your help,

Chris