[dm-crypt] Efficacy of xts over 1TB

[dm-crypt] Efficacy of xts over 1TB

[David Santamaría Rogado]

Hello,

Jonas Meurer from Debian Cryptsetup Team has send me this e-mail
address (dm-crypt@saout.de) as this is the best place for my question:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494584#15, says about
a XTS detriment on security on large filesystems.

But in the wikipedia's discussion:
http://en.wikipedia.org/wiki/Talk:Disk_encryption_theory#Issues_with_XTS

"Issues with XTS

There is also an issue about the size of the filesystem encrypted with
the support of XTS. This is discussed here:
http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2008-September/002265.html
—Preceding unsigned comment added by 62.2.182.207 (talk) 19:40, 1
April 2010 (UTC)

This is a misconception, since it does not apply to large filesystems
(containing many data units/sectors, which are encrypted totally
indepently), but to very large single data units, i.e.: The size of
any single data unit should not exceed 270 bytes. The data unit size
for a typical filesystem is between 512 and 64536 bytes only
(29/216).93.205.111.251 (talk) 15:37, 2 April 2010 (UTC)"


So, XTS has collision troubles with >500 GB or >1TB of data, or, it's a
misconception and there isn't any issue about this on large
filesystems.

Thanks in advice.

Re: [dm-crypt] Efficacy of xts over 1TB

[Arno Wagner]

Hi David,

first XTS mode is not the default anywhere in cryptsetup, so 
why would you want to use it? Is there any specific problem 
with CBC-ESSIV that you wish do address?

On the other hand, TrueCrupt (not related to this project)
does use XTS mode as default.

The one limitation I find in the NIST document is "2^20 AES blocks" 
which would be 128 bit blocks * 2^20 = 16MB per data unit maximum. 
Data Units in the case of disk encryption would be 512 bytes 
typically.

Looking at what seems to have gone on here, there is indication
that incompetent cipher(mode) design did happen, as the two
keys for XTS seem to be unecessary and adding complexity without
gain. Also the security goals of XTS seem to be not specified clearly: 
  http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/XTS_comments-Liskov_Minematsu.pdf
  http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf 
This would be a reason to stay away from XTS, something may have
been subtly messed up.

As a side note, the XTS spec seems to be behind a IEEE paywall, which 
would be another reason not to use it, public standards need to be
accessible for free.

Arno



On Thu, Jul 22, 2010 at 04:57:43PM +0200, David Santamar??a Rogado wrote:
> Hello,
> 
> Jonas Meurer from Debian Cryptsetup Team has send me this e-mail
> address (dm-crypt@saout.de) as this is the best place for my question:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494584#15, says about
> a XTS detriment on security on large filesystems.
> 
> But in the wikipedia's discussion:
> http://en.wikipedia.org/wiki/Talk:Disk_encryption_theory#Issues_with_XTS
> 
> "Issues with XTS
> 
> There is also an issue about the size of the filesystem encrypted with
> the support of XTS. This is discussed here:
> http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2008-September/002265.html
> ???Preceding unsigned comment added by 62.2.182.207 (talk) 19:40, 1
> April 2010 (UTC)
> 
> This is a misconception, since it does not apply to large filesystems
> (containing many data units/sectors, which are encrypted totally
> indepently), but to very large single data units, i.e.: The size of
> any single data unit should not exceed 270 bytes. The data unit size
> for a typical filesystem is between 512 and 64536 bytes only
> (29/216).93.205.111.251 (talk) 15:37, 2 April 2010 (UTC)"
> 
> 
> So, XTS has collision troubles with >500 GB or >1TB of data, or, it's a
> misconception and there isn't any issue about this on large
> filesystems.
> 
> Thanks in advice.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

On Sun, 2010-07-25 at 12:34 +0200, Arno Wagner wrote:
> first XTS mode is not the default anywhere in cryptsetup, so 
> why would you want to use it? Is there any specific problem 
> with CBC-ESSIV that you wish do address?
I've always thought XTS was considered to be the "securest"?! Is it not?

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Milan Broz]

On 07/25/2010 12:34 PM, Arno Wagner wrote:
> This would be a reason to stay away from XTS, something may have
> been subtly messed up.
> 
> As a side note, the XTS spec seems to be behind a IEEE paywall, which 
> would be another reason not to use it, public standards need to be
> accessible for free.

You should then suggest not use hardisks and storage technologies too
because most of standards are not accesible for free:-)
</joke>

Seriously, XTS-AES is FIPS140-2 approved and I see no problem to use it.
Also read
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/follow-up_XTS_comments-Ball.pdf

Yes, final version is not available but draft specification is still there
(this is IEEE business, not hiding algorithm definition IMHO).

Just please note one thing, which is dm-crypt special here:

default "plain IV" is 32 bit only, so if anyone uses it on >2TB partition
some sectors shares IV (IV generator restarts, opening it to to watermarking
and similar attacks).

Please _always_ use plain64 (*aes-xts-plain64*) if you want use it for large
devices. (plain64 produces the same IV for <2TB.
Available since 2.6.33, Truecrypt 7 already does that, thanks:-)

Milan

Re: [dm-crypt] Efficacy of xts over 1TB

[Heinz Diehl]

On 25.07.2010, Christoph Anton Mitterer wrote: 

> I've always thought XTS was considered to be the "securest"?! Is it not?

AFAIK, XTS and EME are most secure per today. By the way, EME is what the 
commercial PGP WDE uses. However, EME is slow, and, even worse, it's patented, 
and therefore unlikely to get into any open source based cryptosystem 
in the near future.

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Sun, 2010-07-25 at 14:25 +0200, Milan Broz wrote:
> Just please note one thing, which is dm-crypt special here:
> 
> default "plain IV" is 32 bit only, so if anyone uses it on >2TB partition
> some sectors shares IV (IV generator restarts, opening it to to watermarking
> and similar attacks).
> 
> Please _always_ use plain64 (*aes-xts-plain64*) if you want use it for large
> devices. (plain64 produces the same IV for <2TB.
> Available since 2.6.33, Truecrypt 7 already does that, thanks:-)

1) What's the maximum size a partition can (securely) have with plain64?

2) Is plain64 solwer than the the normal plain? If not,... and even
if,.. wouldn't it be better to let "plain" be what currently "plain64"
is and to add a e.g. "plain32" or so, which people can use if the really
know what they're doing?

3) In any case,.. this should go in the FAQ, Arno, can you add this
please?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Milan Broz]

On 07/25/2010 03:14 PM, Christoph Anton Mitterer wrote:

> 1) What's the maximum size a partition can (securely) have with plain64?

not talking about encryption mode security, just about plain IV:

plain 64 is just 64bit unsigned (512b sector number with optional initial
offset), sector are also 64bit, so limit is the same like maximum block
device in Linux currently.

> 2) Is plain64 solwer than the the normal plain? If not,... and even
> if,.. wouldn't it be better to let "plain" be what currently "plain64"
> is and to add a e.g. "plain32" or so, which people can use if the really
> know what they're doing?

It is not slower (plain uses 64bit too but with masking 32bits out,
I guess this is some cryptoloop legacy)

plain64 discussion was already in this list - we cannot change plain because
of backward compatibility (Imagine old 4TB LUKS device ("plain" iv mode in header)
- after this change everything above 2TB is garbage.)
I prefer keep small open problem here (only few such systems in fact) to
destroying users data for sure.
(I can add warning/hint to cryptsetup binary if using large device.)

Default modes in cryptsetup now use essiv:sha256 (no problem here).
Mainly for backward compatibility (best compatible/safe mode,
e.g. RHEL/CentOS5 do not have XTS yet), otherwise I personally prefer XTS mode:-)

You have to set -c cipher-mode-plain manually, I expect you know what
are you doing then.
 
> 3) In any case,.. this should go in the FAQ, Arno, can you add this
> please?

yes, I thought it is already there...

Milan

Re: [dm-crypt] Efficacy of xts over 1TB

[Arno Wagner]

On Sun, Jul 25, 2010 at 02:25:32PM +0200, Milan Broz wrote:
> 
> On 07/25/2010 12:34 PM, Arno Wagner wrote:
> > This would be a reason to stay away from XTS, something may have
> > been subtly messed up.
> > 
> > As a side note, the XTS spec seems to be behind a IEEE paywall, which 
> > would be another reason not to use it, public standards need to be
> > accessible for free.
> 
> You should then suggest not use hardisks and storage technologies too
> because most of standards are not accesible for free:-)
> </joke>

The drafts are free ;-)
 
> Seriously, XTS-AES is FIPS140-2 approved and I see no problem to use it.

Well, I basically do not see the algorithm. Maybe searching for 15 
Minutes was not enough, but when something is hidden in Crypto,
I always become very suspicuous.

> Also read
> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/follow-up_XTS_comments-Ball.pdf
> 
> Yes, final version is not available but draft specification is still there
> (this is IEEE business, not hiding algorithm definition IMHO).

Have a link to it?

Seriously, I suspect XTS is fine, but not finding the description
and detailed security analysis online bothers me more than a bit.

> Just please note one thing, which is dm-crypt special here:
> 
> default "plain IV" is 32 bit only, so if anyone uses it on >2TB partition
> some sectors shares IV (IV generator restarts, opening it to to watermarking
> and similar attacks).

That was the thing with dm-crypt, yes. 

> Please _always_ use plain64 (*aes-xts-plain64*) if you want use it for large
> devices. (plain64 produces the same IV for <2TB.
> Available since 2.6.33, Truecrypt 7 already does that, thanks:-)

Ok. Will put that in the FAQ in a few days.

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] Efficacy of xts over 1TB

[Arno Wagner]

On Sun, Jul 25, 2010 at 03:14:24PM +0200, Christoph Anton Mitterer wrote:
> On Sun, 2010-07-25 at 14:25 +0200, Milan Broz wrote:
> > Just please note one thing, which is dm-crypt special here:
> > 
> > default "plain IV" is 32 bit only, so if anyone uses it on >2TB partition
> > some sectors shares IV (IV generator restarts, opening it to to watermarking
> > and similar attacks).
> > 
> > Please _always_ use plain64 (*aes-xts-plain64*) if you want use it for large
> > devices. (plain64 produces the same IV for <2TB.
> > Available since 2.6.33, Truecrypt 7 already does that, thanks:-)
> 
> 1) What's the maximum size a partition can (securely) have with plain64?

That would be larger than you can buy ;-)

512B * 2 ^64 = 9444 EB = 9.2 * 10^21 B

 
> 2) Is plain64 solwer than the the normal plain? If not,... and even
> if,.. wouldn't it be better to let "plain" be what currently "plain64"
> is and to add a e.g. "plain32" or so, which people can use if the really
> know what they're doing?

I suspect backwards compatribility and not everybody running a 
kernel >= 2.6.33
 
> 3) In any case,.. this should go in the FAQ, Arno, can you add this
> please?

I will. Once I have seen an XTS spec ;-)

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] Efficacy of xts over 1TB

[Milan Broz]

On 07/25/2010 05:28 PM, Arno Wagner wrote:
> On Sun, Jul 25, 2010 at 02:25:32PM +0200, Milan Broz wrote:

>> Seriously, XTS-AES is FIPS140-2 approved and I see no problem to use it.
> 
> Well, I basically do not see the algorithm. Maybe searching for 15 
> Minutes was not enough, but when something is hidden in Crypto,
> I always become very suspicuous.

Draft is here (referenced from Linux kernel crypt XTS implementation)
http://grouper.ieee.org/groups/1619/email/pdf00086.pdf 

Milan

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2459 bytes --]

On Sun, 2010-07-25 at 15:52 +0200, Milan Broz wrote:
> not talking about encryption mode security, just about plain IV:
> 
> plain 64 is just 64bit unsigned (512b sector number with optional initial
> offset), sector are also 64bit, so limit is the same like maximum block
> device in Linux currently.
Well but as far as I understand, this means that the same IV could be
used in multiple sectors (after the 32bit), right?
And wouldn't this have a negative impact on the security?


> > 2) Is plain64 solwer than the the normal plain? If not,... and even
> > if,.. wouldn't it be better to let "plain" be what currently "plain64"
> > is and to add a e.g. "plain32" or so, which people can use if the really
> > know what they're doing?
> 
> It is not slower (plain uses 64bit too but with masking 32bits out,
> I guess this is some cryptoloop legacy)
> 
> plain64 discussion was already in this list - we cannot change plain because
> of backward compatibility (Imagine old 4TB LUKS device ("plain" iv mode in header)
> - after this change everything above 2TB is garbage.)
I see... what about this idea:
In newer releases of cryptsetup, give a warning whenever people use
"plain" suggesting them to use "plain64"?!


> I prefer keep small open problem here (only few such systems in fact) to
> destroying users data for sure.
Uhm,.. what do you mean?

> (I can add warning/hint to cryptsetup binary if using large device.)
Ah ^^...
Wouldn't it be better to always warn, even on devices smaller than the
limit for plain? I mean luks devices are easily resizeable so people
could run into that problem later.



> Default modes in cryptsetup now use essiv:sha256 (no problem here).
> Mainly for backward compatibility (best compatible/safe mode,
> e.g. RHEL/CentOS5 do not have XTS yet), otherwise I personally prefer XTS mode:-)
Are you going to change this someday? I mean to xts?


> You have to set -c cipher-mode-plain manually, I expect you know what
> are you doing then.
Well,... I've also thought I knew what I did,.. but apparently not ;)

 
Nevertheless,... it all comes down to:
1) Devices smaller than 2TB are also secure with "plain"....
2) larger devices have to use plain64 in order to avoid the same IV
begin used after the boundary
3) No other currently known weakness in XTS and/or it's IV generation
algo.
4) XTS is the most secure mode at the moment?

Right?


Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On Sun, 2010-07-25 at 17:32 +0200, Arno Wagner wrote:
> 512B * 2 ^64 = 9444 EB = 9.2 * 10^21 B
btw: the 512 bytes... is this always the statical block size in
cryptsetup/dm-crypt or would I have to use e.g. 4K if I have a disk with
such a block size (i.e. does cryptsetup/dm-crytp always use 512b blocks
or does it use the underlying physical block size)?

Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

Hey...

I was looking at this:
http://en.wikipedia.org/wiki/XTS_mode#Issues_with_XTS

Anybody with some deeper knowledge about it?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Milan Broz]

On 07/26/2010 12:48 AM, Christoph Anton Mitterer wrote:
> On Sun, 2010-07-25 at 17:32 +0200, Arno Wagner wrote:
>> 512B * 2 ^64 = 9444 EB = 9.2 * 10^21 B
> btw: the 512 bytes... is this always the statical block size in
> cryptsetup/dm-crypt or would I have to use e.g. 4K if I have a disk with
> such a block size (i.e. does cryptsetup/dm-crytp always use 512b blocks
> or does it use the underlying physical block size)?

Device-mapper (and here dm-crypt too) always calculate size in 512b sectors,
but is also device topology aware (it honors alignment/optimal io size for 4k hw sector).

IOW sector in linux block level is always 512b but devices with 4k will work
without problems (and with optimal aligned IOs)

You just cannot have dm-crypt using atomic crypto 4k units currently, it is just
low-level hw sector size.
(Maybe in future there could be option for that but it requires new LUKS header flags
at least because such mode is incompatible.)

Milan

Re: [dm-crypt] Efficacy of xts over 1TB

[Milan Broz]

On 07/26/2010 12:37 AM, Christoph Anton Mitterer wrote:

>> I prefer keep small open problem here (only few such systems in fact) to
>> destroying users data for sure.
> Uhm,.. what do you mean?

Imagine that someone today has LUKS device of >2TB and data on it. Switch
to full 64 bit "plain" IV will change IV for all sectors above 2TB limit.
I think users prefer read data from there instead of random noise:-)

So question is if XTS is ok for such large drives - the 1TB mentioned limit
elsewhere is possible misinterpretation (block size/device size confusion?).

(... real answer must come from an expert in cryptography based on proper analysis.)

And Loop-aes people will surely mention something about CBC with multikey:-)


>> Mainly for backward compatibility (best compatible/safe mode,
>> e.g. RHEL/CentOS5 do not have XTS yet), otherwise I personally prefer XTS mode:-)
> Are you going to change this someday? I mean to xts?

Dunno, there is still many old distros and people are using cryptsetup
for USB to move data between systems.

Anyway, distro maintainer can set default using configure switch already
--with-luks1-mode=xts (see also other switches).

So if you want to switch default in Debian, no problem:-)

Milan

Re: [dm-crypt] Efficacy of xts over 1TB

[Arno Wagner]

On Mon, Jul 26, 2010 at 12:37:44AM +0200, Christoph Anton Mitterer wrote:
> On Sun, 2010-07-25 at 15:52 +0200, Milan Broz wrote:
> > not talking about encryption mode security, just about plain IV:
> > 
> > plain 64 is just 64bit unsigned (512b sector number with optional initial
> > offset), sector are also 64bit, so limit is the same like maximum block
> > device in Linux currently.
> Well but as far as I understand, this means that the same IV could be
> used in multiple sectors (after the 32bit), right?

Err, no? That would be "after 64 bit".

> And wouldn't this have a negative impact on the security?

If you go over 64 bit sector numbers, definitely. However it is
hard to quantify how large this impact would be.
 
> > > 2) Is plain64 solwer than the the normal plain? If not,... and even
> > > if,.. wouldn't it be better to let "plain" be what currently "plain64"
> > > is and to add a e.g. "plain32" or so, which people can use if the really
> > > know what they're doing?
> > 
> > It is not slower (plain uses 64bit too but with masking 32bits out,
> > I guess this is some cryptoloop legacy)
> > 
> > plain64 discussion was already in this list - we cannot change plain because
> > of backward compatibility (Imagine old 4TB LUKS device ("plain" iv mode in header)
> > - after this change everything above 2TB is garbage.)
> I see... what about this idea:
> In newer releases of cryptsetup, give a warning whenever people use
> "plain" suggesting them to use "plain64"?!

I like this approach.
 
> > I prefer keep small open problem here (only few such systems in fact) to
> > destroying users data for sure.
> Uhm,.. what do you mean?
> 
> > (I can add warning/hint to cryptsetup binary if using large device.)
> Ah ^^...
> Wouldn't it be better to always warn, even on devices smaller than the
> limit for plain? I mean luks devices are easily resizeable so people
> could run into that problem later.

I think this is out of scope. Somebody rezising an encrypted device
without looking into the limits of the encryption used, is asking
for trouble. Also there will be a FAQ entry on resizing ;-)
 

> > Default modes in cryptsetup now use essiv:sha256 (no problem here).
> > Mainly for backward compatibility (best compatible/safe mode,
> > e.g. RHEL/CentOS5 do not have XTS yet), otherwise I personally prefer XTS mode:-)
> Are you going to change this someday? I mean to xts?
> 
> 
> > You have to set -c cipher-mode-plain manually, I expect you know what
> > are you doing then.
> Well,... I've also thought I knew what I did,.. but apparently not ;)

Hehe. Crypto is hard.
   
> Nevertheless,... it all comes down to:
> 1) Devices smaller than 2TB are also secure with "plain"....

Yes.

> 2) larger devices have to use plain64 in order to avoid the same IV
> begin used after the boundary

Yes.

> 3) No other currently known weakness in XTS and/or it's IV generation
> algo.

Yes. 

> 4) XTS is the most secure mode at the moment?

No. That is a judgement call. It is quite possible that cbc-essiv
is just as secure. For "most secure mode" you need an increment
in security compared to other modes. And that may also very likely 
depend on the attack scenatio, i.e. some mode may be more secure
under scenario A and some other mode under scenario B. Also what
"more secure" means is variable.

Don't go for that "best xyz" idiocity that modern advertizement 
is so fond of. There can be equally good solutions or the 
difference can be small enough not to matter.

It seems to me the latter is currently the case for XTS and
cbc-essiv. However XTS is surely going to be analyzed and
attacked with more effort, being more widely used, which can 
both increase (if it is "secure") and decresee (if it has 
flaws) its security. But any attacks on both would be pretty 
exotic.

> Right?

See above.

Caveat as before: I am not a cryptographer.

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] Efficacy of xts over 1TB

[Mario 'BitKoenig' Holbe]

Arno Wagner <arno@wagner.name> wrote:
> first XTS mode is not the default anywhere in cryptsetup, so 
> why would you want to use it? Is there any specific problem 

It's standardized by NIST :)

> with CBC-ESSIV that you wish do address?

CBC-ESSIV is specifically designed to tweak CBC to withstand watermark
attacks, but does not address other kinds of attacks CBC is vulnerable
to, like leakage, malleability, etc. XTS is not vulnerable to them.

Thus, depending on your personal security needs there may be scenarios
where you don't want to use CBC-ESSIV. Or you just prefer to use
standardized mechanisms :)

> The one limitation I find in the NIST document is "2^20 AES blocks" 
> which would be 128 bit blocks * 2^20 = 16MB per data unit maximum. 

The other one you can find in D.4.3: strong security is proven as long
as the same key is not used to encrypt >>1TB data.

Btw... just because there was a discussion regarding plain vs. plain64
in this thread: Of course the above also holds for plain64. - I guess
this is what Milan meant when he did explicitely state not talk about
encryption mode security while explaining plain64.

And btw.2... Jonas forwarded Micahs mail to this list as well:
Message-ID: <20080902122833.GF29731@resivo.wgnet.de>
This is basically why Clemens created
http://code.google.com/p/cryptsetup/issues/detail?id=13
based on:
Message-ID: <2f83750a0904160037n4a260b96g266b9d735a745556@mail.gmail.com>
Subject: Re: Plans to avoid weaknesses in big volumes? (was: Re: SMP-aware kcryptd?)


regards
   Mario
-- 
Computer Science is no more about computers than astronomy is about
telescopes.                                       -- E. W. Dijkstra

Re: [dm-crypt] Efficacy of xts over 1TB

[Mario 'BitKoenig' Holbe]

David Santamaría Rogado <howl.nsp@gmail.com> wrote:
> There is also an issue about the size of the filesystem encrypted with
> the support of XTS. This is discussed here:
> http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2008-September/002265.html

Yes, Micah refers to D.4.3 in the NIST "Extract from IEEE Std 1619-2007"
here: strong security is proven as long as the same key is not used to
encrypt >>1TB data.

> But in the wikipedia's discussion:
> http://en.wikipedia.org/wiki/Talk:Disk_encryption_theory#Issues_with_XTS

It seems like this guy didn't read D.4.3, but refers to 5.1.

> So, XTS has collision troubles with >500 GB or >1TB of data, or, it's a
> misconception and there isn't any issue about this on large
> filesystems.

It's not exactly collisions, but more like a collision probability, if
you want to keep the term. Effectively, its the sucess probability of an
attack that increases. Depending on the amount of data you like to
encrypt and on your security needs this may or may not be a concern for
you. The attack success probability doesn't instantly jump to 1 if you
encrypt more than 1TB of data, but increases from not better than 2^-53
for 1TB to about 2^-37 for 1PB to about 2^-17 for 1EB.

This may or may not sound less dangerous for you than it really is. Just
consider an incremented exponent means a double-up (though, we're
talking about very small numbers here).

Please also note that depending on your security needs and usage
pattern, the term "a key is used to encrypt 1TB of data" is not
necessarily equivalent to "a key is used to encrypt a 1TB disk". If you,
for example, have a disk where much data is modified often and you
expect your attacker to be able to get snapshots of the encrypted disk
without your knowledge, your "safe" disk size effectively decreases.


regards
   Mario
-- 
The social dynamics of the net are a direct consequence of the fact that
nobody has yet developed a Remote Strangulation Protocol.  -- Larry Wall

Re: [dm-crypt] Efficacy of xts over 1TB

[Mario 'BitKoenig' Holbe]

Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de> wrote:
> http://en.wikipedia.org/wiki/XTS_mode#Issues_with_XTS
> Anybody with some deeper knowledge about it?

No deeper knowledge, but the authors of XTS refer to the separation of
keys on the purpose they are used for as good security design practice,
as the NIST Key Management Guidelines do as well.

It may or may not provide additional security. This basically depends on
what you compare it to.
For example: if you would specify a derivation of XTS where one key is
used for both AESEnc operations or where one key is derived from the
other using PBKDF2 (or both from a 3rd), you actually would need to
prove that there is no bad interference between the two AESEnc
operations and PBKDF2. If the math behind it would be "bad", it could
produce collisions, or shortening, for example. I don't know if
somebody ever did this, but if you choose two independent keys, you just
circumvent to do do the math.
Thus, I think the more important part is: it does not harm security :)

Btw.: please don't confuse the example above with Clemens proposal in
Message-ID: <2f83750a0904160037n4a260b96g266b9d735a745556@mail.gmail.com>
This is different because the keys derived from each other are used
mostly independent there (except for block moves).


regards
   Mario
-- 
> As Luke Leighton said once on samba-ntdom, "now, what was that about
> rebooting?   that was so long ago, i had to look it up with man -k."

Re: [dm-crypt] Efficacy of xts over 1TB

[Arno Wagner]

Updated the FAQ with a comment on XTS and how to use it, as well
as plain64 and the question of resizing a dm-crypt/LIKS container.

Feel free to comment.

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] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Mon, 2010-07-26 at 01:42 +0200, Milan Broz wrote:
> Device-mapper (and here dm-crypt too) always calculate size in 512b sectors,
> but is also device topology aware (it honors alignment/optimal io size for 4k hw sector).
> 
> IOW sector in linux block level is always 512b but devices with 4k will work
> without problems (and with optimal aligned IOs)
Good to know :)



> You just cannot have dm-crypt using atomic crypto 4k units currently, it is just
> low-level hw sector size.
> (Maybe in future there could be option for that but it requires new LUKS header flags
> at least because such mode is incompatible.)
But that would also require support in the block layer and dm right?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Mon, 2010-07-26 at 02:14 +0200, Milan Broz wrote:
> Imagine that someone today has LUKS device of >2TB and data on it. Switch
> to full 64 bit "plain" IV will change IV for all sectors above 2TB limit.
> I think users prefer read data from there instead of random noise:-)
Are you really sure?! ;)  ... would be a nice /dev/random alternative or
so ^^


> So question is if XTS is ok for such large drives - the 1TB mentioned limit
> elsewhere is possible misinterpretation (block size/device size confusion?).
> 
> (... real answer must come from an expert in cryptography based on proper analysis.)
So you guess the the 1TB limit could be actually a "don't have blocks
larger than 1TB" limit?!


> Anyway, distro maintainer can set default using configure switch already
> --with-luks1-mode=xts (see also other switches).
> 
> So if you want to switch default in Debian, no problem:-)
I seem to have rather bad luck in moving cryptsetup things at distro
level... ;)


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On Mon, 2010-07-26 at 10:53 +0200, Arno Wagner wrote:
> > Well but as far as I understand, this means that the same IV could be
> > used in multiple sectors (after the 32bit), right?
> Err, no? That would be "after 64 bit".

Uhm why? If we have 64, bits but the upper 32 are masked 0 as far as I
understood... ?


> If you go over 64 bit sector numbers, definitely. However it is
> hard to quantify how large this impact would be.
But 64bit 512byte sectors would allow us a ~9,4 ZB device, right? So
that is unlikely to happen the next... say 3 years or so ;)


> > I see... what about this idea:
> > In newer releases of cryptsetup, give a warning whenever people use
> > "plain" suggesting them to use "plain64"?!
> I like this approach.
Thanks :) perhaps better than a warning would even be some interactive
question.


> I think this is out of scope. Somebody rezising an encrypted device
> without looking into the limits of the encryption used, is asking
> for trouble. Also there will be a FAQ entry on resizing ;-)
Well... if my calculation above is correct, we'd at least never leave
the scope with plain 64.

Nevertheless... it would be at least possible to change luksResize to
print a warning,.. but of course this won't happen in all cases (plain
dm-crypt, close/reopen), which is why I suggested plain64 to be
generally used,.. especially if it has not drawbacks.

Milan what do you think?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Arno Wagner]

On Mon, Jul 26, 2010 at 10:47:43PM +0200, Christoph Anton Mitterer wrote:
> On Mon, 2010-07-26 at 10:53 +0200, Arno Wagner wrote:
> > > Well but as far as I understand, this means that the same IV could be
> > > used in multiple sectors (after the 32bit), right?
> > Err, no? That would be "after 64 bit".
> 
> Uhm why? If we have 64, bits but the upper 32 are masked 0 as far as I
> understood... ?

For plain. Not for plain64, i.e. plain is plain 64 with 32 bits 
masked and plain64 is full 64 bits.
 
> > If you go over 64 bit sector numbers, definitely. However it is
> > hard to quantify how large this impact would be.
> But 64bit 512byte sectors would allow us a ~9,4 ZB device, right? So
> that is unlikely to happen the next... say 3 years or so ;)

I hope so ;-)

> > > I see... what about this idea:
> > > In newer releases of cryptsetup, give a warning whenever people use
> > > "plain" suggesting them to use "plain64"?!
> > I like this approach.
> Thanks :) perhaps better than a warning would even be some interactive
> question.
> 
> 
> > I think this is out of scope. Somebody rezising an encrypted device
> > without looking into the limits of the encryption used, is asking
> > for trouble. Also there will be a FAQ entry on resizing ;-)
> Well... if my calculation above is correct, we'd at least never leave
> the scope with plain 64.

;-)
 
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] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Mon, 2010-07-26 at 23:01 +0200, Arno Wagner wrote:
> On Mon, Jul 26, 2010 at 10:47:43PM +0200, Christoph Anton Mitterer wrote:
> > On Mon, 2010-07-26 at 10:53 +0200, Arno Wagner wrote:
> > > > Well but as far as I understand, this means that the same IV could be
> > > > used in multiple sectors (after the 32bit), right?
> > > Err, no? That would be "after 64 bit".
> > 
> > Uhm why? If we have 64, bits but the upper 32 are masked 0 as far as I
> > understood... ?
> 
> For plain. Not for plain64, i.e. plain is plain 64 with 32 bits 
> masked and plain64 is full 64 bits.
Yeah that's what I meant,.. did I write plain64?

 
> > > If you go over 64 bit sector numbers, definitely. However it is
> > > hard to quantify how large this impact would be.
> > But 64bit 512byte sectors would allow us a ~9,4 ZB device, right? So
> > that is unlikely to happen the next... say 3 years or so ;)
> 
> I hope so ;-)
Well depends.... if I'm the one inventing such a storage device,... I'd
hope not ;)


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Arno Wagner]

On Mon, Jul 26, 2010 at 11:28:03PM +0200, Christoph Anton Mitterer wrote:
> On Mon, 2010-07-26 at 23:01 +0200, Arno Wagner wrote:
> > On Mon, Jul 26, 2010 at 10:47:43PM +0200, Christoph Anton Mitterer wrote:
> > > On Mon, 2010-07-26 at 10:53 +0200, Arno Wagner wrote:
> > > > > Well but as far as I understand, this means that the same IV could be
> > > > > used in multiple sectors (after the 32bit), right?
> > > > Err, no? That would be "after 64 bit".
> > > 
> > > Uhm why? If we have 64, bits but the upper 32 are masked 0 as far as I
> > > understood... ?
> > 
> > For plain. Not for plain64, i.e. plain is plain 64 with 32 bits 
> > masked and plain64 is full 64 bits.
> Yeah that's what I meant,.. did I write plain64?

Hmm. I think so, but I am not sure anymore. Anyways, plain64
solves the problem. Incidentially I have kernel 2.6.34 (and 
now 2.6.34.1) running on several different machines without 
any problem, and it has plain64. Not that I have a disk large 
enough to need it ;-)
 
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] Using plain64/plain IV (initialisation vector) in dm-crypt

[Milan Broz]

This thread is going crazy... :)

1) Facts about using plain IV generator:

- "plain" IV is 32bit only, supported by all kernels
- you should avoid using it for >2TB devices
- it will remain this way because of backward compatibility (howgh:-)

- "plain64" is fully 64bit, available since kernel 2.6.33
- for device < 2TB it produces the same output as "plain"

=> use plain64 for new devices if you want to use tweakable encryption
mode like XTS (or LRW), e.g. cryptsetup -c aes-xts-plain64

p.s.
Never use plain* IV for CBC mode, use ESSIV there.
<joke>If you are using ECB mode, you are lost anyway.</joke>

2) crypsetup should have always safe defaults.
It is aes-cbc-essiv:sha256 with 256bit key currently.


3) For the resize - we cannot catch all situations, someone can
dd LUKS disk to another bigger volume without "resize" command.

Tools will suggest using plain64 but it cannot force it.


> So you guess the the 1TB limit could be actually ...

Forgot about 1TB limit, it is different XTS only problem.
We mixed up two unrelated problems here.

Milan

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Arno Wagner]

On Tue, Jul 27, 2010 at 10:46:44AM +0200, Milan Broz wrote:
> This thread is going crazy... :)

Slow day here ;-)

> 1) Facts about using plin IV generator:
> 
> - "plain" IV is 32bit only, supported by all kernels
> - you should avoid using it for >2TB devices
> - it will remain this way because of backward compatibility (howgh:-)
> 
> - "plain64" is fully 64bit, available since kernel 2.6.33
> - for device < 2TB it produces the same output as "plain"
> 
> => use plain64 for new devices if you want to use tweakable encryption
> mode like XTS (or LRW), e.g. cryptsetup -c aes-xts-plain64

Added to the FAQ yesterday. Updated just now that plain64 is
backwards compatible below 2TB.
 
> p.s.
> Never use plain* IV for CBC mode, use ESSIV there.
> <joke>If you are using ECB mode, you are lost anyway.</joke>
> 
> 2) crypsetup should have always safe defaults.
> It is aes-cbc-essiv:sha256 with 256bit key currently.
> 
> 
> 3) For the resize - we cannot catch all situations, someone can
> dd LUKS disk to another bigger volume without "resize" command.

Yes. My FAQ recomendation is to make a backup, create a new
container in the target size and then restore the data. I 
think resizing the filesystem is just too risky otherwise.

> Tools will suggest using plain64 but it cannot force it.
> 
> 
> > So you guess the the 1TB limit could be actually ...
> 
> Forgot about 1TB limit, it is different XTS only problem.
> We mixed up two unrelated problems here.

Indeed. 

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] Using plain64/plain IV (initialisation vector) in dm-crypt

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

On Tue, 2010-07-27 at 10:46 +0200, Milan Broz wrote:
> This thread is going crazy... :)
Well... what about me... my last crypto lectures are already some years
ago, and it seems I've forgotten most of it ;)


> 1) Facts about using plain IV generator:
> 
> - "plain" IV is 32bit only, supported by all kernels
> - you should avoid using it for >2TB devices
> - it will remain this way because of backward compatibility (howgh:-)
> 
> - "plain64" is fully 64bit, available since kernel 2.6.33
> - for device < 2TB it produces the same output as "plain"
> 
> => use plain64 for new devices if you want to use tweakable encryption
> mode like XTS (or LRW), e.g. cryptsetup -c aes-xts-plain64
Clear so far... (hadn't LRW some weaknesses?)
So with plain64 we're always safe (at least until I invent my ZB-devices
and get rich ^^)

We're also safe with that limit on the block size, as our blocks are
much smaller than that 2^20 mentioned by Arno, right?

Last but not least the issue mentioned by Mario... the overall amount of
written data, when someone is able to take snapshots in between.
As far as I understand this may become a problem after several hundreds
of TBs written,... right? Guess it allows some probability attacks or
so?
Is there any way to avoid this? Or only to re-encode the device
regularly with another key (btw: is it with LUKS possible to do this on
the fly?)?
But I guess that issue is not limited to XTS, is it?


> 2) crypsetup should have always safe defaults.
> It is aes-cbc-essiv:sha256 with 256bit key currently.
*Still suggesting to replace this some day with xts, at least if it
mitigates some attacks, as mentioned before here*


> 3) For the resize - we cannot catch all situations, someone can
> dd LUKS disk to another bigger volume without "resize" command.
> 
> Tools will suggest using plain64 but it cannot force it.
Nice.


> > So you guess the the 1TB limit could be actually ...
> Forgot about 1TB limit, it is different XTS only problem.
> We mixed up two unrelated problems here.
Uhm,.... and which one is it then?


Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Tue, 2010-07-27 at 12:47 +0200, Arno Wagner wrote: 
> Yes. My FAQ recomendation is to make a backup, create a new
> container in the target size and then restore the data. I 
> think resizing the filesystem is just too risky otherwise.
Why exactly do you mean? Any other pitfalls than that a user continues
to use plain instead of plain64?
I thought everything else in the LUKS header would be independent of the
amount of storage after it.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Mario 'BitKoenig' Holbe]

Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de> wrote:
> (hadn't LRW some weaknesses?)

Yes.

> Last but not least the issue mentioned by Mario... the overall amount of
> written data, when someone is able to take snapshots in between.
> As far as I understand this may become a problem after several hundreds
> of TBs written,... right? Guess it allows some probability attacks or

This depends on your attack model and whether you believe in forensic
magic. If your attacker cannot snapshot your encrypted data, the size of
your encrypted disk equals the amount of encrypted data an attacker can
get. If your attacker can snapshot your encrypted data, you are right.

For example, if you like to protect against disk theft your attack model
doesn't include snapshots. If you like to protect against spying your
attack model very likely includes snapshots.

Note, that if your attack model doesnt allow your attacker to snapshot
your encrypted data, you are pretty safe with CBC-ESSIV anyways. Lots of
the attacks XTS can but CBC-ESSIV cannot withstand require on-the-fly
access to encrypted data as well (well, malleability doesn't).

Btw... Arno: w.r.t. Gutmann and off-track-forensics: I usually avoid
replying just to say "Please mind the smiley", but here is a good place
to mention it :) No, I don't believe in off-track-forensics on todays
hard disks, but cryptsetup does: luks/keymanage.c:wipe().

Btw.2... Just in case somebody gets this wrong because I'm hammering on
the difference between 1T disks and 1T encrypted data, 1T limits and
whatever: I'm personally feeling pretty well with aes-xts-plain 256
(i.e. AES-128 - there's a nice whitepaper by Seagate on AES-128 vs.
AES-256) on 1.5T disks. The reason I'm insisting on such differences is
that it is my deep belief that there are no "safe defaults" on security
(well, there is a pathologically one). You always have to understand
what's your goals and what you do. 

> Is there any way to avoid this? Or only to re-encode the device
> regularly with another key

Yep that's your way to go :)

> (btw: is it with LUKS possible to do this on the fly?)?

Nope. Not yet. It's possible to code it, though :)

> But I guess that issue is not limited to XTS, is it?
...
> On Tue, 2010-07-27 at 10:46 +0200, Milan Broz wrote:
>> Forgot about 1TB limit, it is different XTS only problem.

I'm not intending to mention that I have any deeper understanding of the
Rogaway 2004 paper, but as far as I understand it, this limit holds at
least for all XOR-Encryption(XE)-based tweakable block ciphers.


regards
   Mario
-- 
The secret that the NSA could read the Iranian secrets was more
important than any specific Iranian secrets that the NSA could
read.                           -- Bruce Schneier

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Milan Broz]

On 07/27/2010 05:45 PM, Mario 'BitKoenig' Holbe wrote:
>>> Forgot about 1TB limit, it is different XTS only problem.
> 
> I'm not intending to mention that I have any deeper understanding of the
> Rogaway 2004 paper, but as far as I understand it, this limit holds at
> least for all XOR-Encryption(XE)-based tweakable block ciphers.

I tried to not mix that XTS/XEX 1TB problem with plain IV explanation,
so it should read "1TB data limit is different problem not related
to plain/plain64 IV limit"
(I changed subject to mention IV only - but forgot to mention it.)

Sorry for confusion:-)

Milan

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Arno Wagner]

On Tue, Jul 27, 2010 at 04:17:12PM +0200, Christoph Anton Mitterer wrote:
> On Tue, 2010-07-27 at 12:47 +0200, Arno Wagner wrote: 
> > Yes. My FAQ recomendation is to make a backup, create a new
> > container in the target size and then restore the data. I 
> > think resizing the filesystem is just too risky otherwise.
> Why exactly do you mean? Any other pitfalls than that a user continues
> to use plain instead of plain64?
> I thought everything else in the LUKS header would be independent of the
> amount of storage after it.

Yes, but you need to 

  a) resize the raw container (partition, file, disk)
  b) reboot to make the kernel see the changed size
  c) decrypt the container 
  d) wipe the additional space from the decrypted side
  e) resize the filesystem in the container

d) is optional but highly recommended. 

If you get anything wrong here, the risk of wiping your 
LUKS header (with complete data loss) or damaging the filesystem
for dm-crypt (with at least partial data loss) are high enough to
justify doing a backup. Also, power loss or a system crash during
the filesystem resizing can also result in arbitrary bad data loss.

But if you have a backup, recreating the filesystem in the new
size is the easiest option. You do not strictly need to recreate 
the LUKS header, but if you are prepared to do it, you are not 
screwed if it turns out that it suffered damage. 

So, yes, you can do this without backup and just keeping the
original LUKS header. But I will continue to recomend a full
data backup and recreating the container after resizing it. 
If you are proficient enough to not need that, be my guest,
but if you mess up and lose all your data, I will be entitled
to make fun of you ;-)

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 

[dm-crypt] Including the FAQ in the tarball?

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

Hey...

On Mon, 2010-07-26 at 20:09 +0200, Arno Wagner wrote:
> Updated the FAQ with a comment on XTS and how to use it, as well
> as plain64 and the question of resizing a dm-crypt/LIKS container.
> 
> Feel free to comment.
Before I forget it....

I'd like to see the FAQ as text file or so being part of the tarball...
especially as it's not guaranteed that users will ever stumble across
the website.

Any objections?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Efficacy of xts over 1TB

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

On Mon, 2010-07-26 at 11:04 +0200, Mario 'BitKoenig' Holbe wrote:
> This is basically why Clemens created
> http://code.google.com/p/cryptsetup/issues/detail?id=13
Interesting... is this ever going to be implemented?

Wouldn't that mean however, that setting up the mapping takes much
longer?

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Including the FAQ in the tarball?

[Arno Wagner]

On Tue, Jul 27, 2010 at 08:16:36PM +0200, Christoph Anton Mitterer wrote:
> Hey...
> 
> On Mon, 2010-07-26 at 20:09 +0200, Arno Wagner wrote:
> > Updated the FAQ with a comment on XTS and how to use it, as well
> > as plain64 and the question of resizing a dm-crypt/LIKS container.
> > 
> > Feel free to comment.
> Before I forget it....
> 
> I'd like to see the FAQ as text file or so being part of the tarball...
> especially as it's not guaranteed that users will ever stumble across
> the website.
> 
> Any objections?
> 
> 
> Cheers,
> Chris.

Fine by me. I can produce an ASCII version for each release.

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] Efficacy of xts over 1TB

[David Santamaría Rogado]

Thanks a lot for the information, believe it or not, I had also
questions concerning about resizing cyphered volumes that have came up
:) Also the detail of plain64 is very important.

Thanks again.

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

On Tue, 2010-07-27 at 17:45 +0200, Mario 'BitKoenig' Holbe wrote:
> This depends on your attack model and whether you believe in forensic
> magic. If your attacker cannot snapshot your encrypted data, the size of
> your encrypted disk equals the amount of encrypted data an attacker can
> get. If your attacker can snapshot your encrypted data, you are right.
I usually always expect the worst case,... i.e. that my attackers can
make snapshots... ;) *paranoid*


> Note, that if your attack model doesnt allow your attacker to snapshot
> your encrypted data, you are pretty safe with CBC-ESSIV anyways.
Well I'm rather concerned about XTS (which I use anyway at the
moment)... especially give that there are AFAIU at least two issues
which are not solved by plain64 IV generation...

- The one that you continuously write data and an attacker possibly
snapshots it...
- The other thing mentioned here by Milan with the 1TB...

Or was that the same?


> You always have to understand
> what's your goals and what you do.
Well I guess that's impossible for most end users,... (and all people
who wiped ;) their cryptography lectures knowledge)... especially when
it comes to the math behind all that...
Therefore I think we need good FAQ/documentation which teach also the
"end user" what to do in order to get "best possible" security..



Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On Tue, 2010-07-27 at 17:55 +0200, Milan Broz wrote:
> I tried to not mix that XTS/XEX 1TB problem with plain IV explanation,
> so it should read "1TB data limit is different problem not related
> to plain/plain64 IV limit"
> (I changed subject to mention IV only - but forgot to mention it.)
> 
> Sorry for confusion:-)
No problem,.. but if there is another problem,... which means one cannot
have >1TB (Rogaway 2004 mentioned by Mario),... we should add that to
the FAQ (that people should not create larger devices), and perhaps give
a warning when doing so...


Thanks,
Chris :)

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Mario 'BitKoenig' Holbe]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

On Tue, Jul 27, 2010 at 08:58:52PM +0200, Christoph Anton Mitterer wrote:
> On Tue, 2010-07-27 at 17:45 +0200, Mario 'BitKoenig' Holbe wrote:
> > This depends on your attack model and whether you believe in forensic
> I usually always expect the worst case,... i.e. that my attackers can
> make snapshots... ;) *paranoid*

Mh, that's highly inefficient on the one hand and not the worst case on
the other :)

W.r.t. efficiency: I have a nice little Ideapad w/ VIA Nano (i.e.
PadLock): running XTS on that thing is horribly slow (at least on Linux,
at least at the moment) because the PadLock does not natively support
XTS and the Linux XTS implementation is not very accelerator friendly
atm. But it does support CBC and the speed is only marginally lower for
256 than for 128bit keysize. Thus, I can choose slow XTS or I can do
256bit CBC-ESSIV on it near disk speed.
Guess what - as long as I consider the snapshot threat small enough, of
course I will go with CBC-ESSIV.
I also have a Workstation w/ Core2Quad. Here, XTS is as fast as
CBC-ESSIV and 256 is significantly slower than 128bit keys.
Guess what - I take the additional security XTS provides and go with
128bit keys.

W.r.t. worst case: Some people would consider an attacker who cuts your
fingers piece by piece until you tell him your key a little bit worse
than one who is able to do snapshots.


Mario
-- 
Die Natur ist das einzige Buch, das auf allen Blaettern grossen Gehalt
bietet.
                                    -- Johann Wolfgang von Goethe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Arno Wagner]

On Tue, Jul 27, 2010 at 08:59:24PM +0200, Christoph Anton Mitterer wrote:
> On Tue, 2010-07-27 at 17:55 +0200, Milan Broz wrote:
> > I tried to not mix that XTS/XEX 1TB problem with plain IV explanation,
> > so it should read "1TB data limit is different problem not related
> > to plain/plain64 IV limit"
> > (I changed subject to mention IV only - but forgot to mention it.)
> > 
> > Sorry for confusion:-)
> No problem,.. but if there is another problem,... which means one cannot
> have >1TB (Rogaway 2004 mentioned by Mario),... we should add that to
> the FAQ (that people should not create larger devices), and perhaps give
> a warning when doing so...

First, this is a soft limit, and it becomes a real concern 
at around 1000TB. And second, it affects all ciphers with 
128 bit block size, as far as I understand the issue, and
hence is not anything specific for our case.

So, no, not an FAQ item IMO.

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] Efficacy of xts over 1TB

[Mario 'BitKoenig' Holbe]

Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de> wrote:
> On Mon, 2010-07-26 at 11:04 +0200, Mario 'BitKoenig' Holbe wrote:
>> This is basically why Clemens created
>> http://code.google.com/p/cryptsetup/issues/detail?id=3D13
> Wouldn't that mean however, that setting up the mapping takes much
> longer?

Nope, not necessarily. The reason for the initial setup taking some time
is that we choose a large iteration count for PBKDF2 to make attacks
based on guessing the (possibly weak) passphrase harder. This is not
necessary for the derivation of subsequent master keys.


regards
   Mario
-- 
Why did the tachyon cross the road?
Because it was on the other side.

Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt

[Milan Broz]

On 07/27/2010 05:45 PM, Mario 'BitKoenig' Holbe wrote:

> For example, if you like to protect against disk theft your attack model
> doesn't include snapshots. If you like to protect against spying your
> attack model very likely includes snapshots.

Well, the discussion here is about encryption modes etc - I guess probably
one of the stronger part of the chain.

But you mention attack models where you can do snapshots or spying...

- in most situations it means that attacker have physical access to machine
There are many other attacks then which are simpler (memory scan, installing
hw keylogger, installing malware - in all levels from bios to kernel, various
power measures, injecting intentional hw malfunctions etc)

- if attacker have unprivileged account on machine with running encryption,
there are cache attacks on aes implementation

... just examples, threat model depends on real usecase

So, knowledge of encryption mode security and proper use limits is surely
important but we must analyse the whole system and its connections outside.
And usually there are weaker parts elsewhere (...which are also people obviously
http://xkcd.com/538/ :)

If possible encryption mode scares you, you can still use stacking
of various ciphers - like Truecrypt does. If one is broken, there is still
another level.
It is easy to do it with cryptsetup also (IOW LUKS over LUKS).

When mentioning TC - their requirements and precautions applies to cryptsetup
as well http://www.truecrypt.org/docs/?s=security-requirements-and-precautions
...


> Btw... Arno: w.r.t. Gutmann and off-track-forensics: I usually avoid
> replying just to say "Please mind the smiley", but here is a good place
> to mention it :) No, I don't believe in off-track-forensics on todays
> hard disks, but cryptsetup does: luks/keymanage.c:wipe().

(Neither me :), it doesn't work for SSD/Flash drives at all,
but once it is there why remove it? It should not harm:-)

>> Is there any way to avoid this? Or only to re-encode the device
>> regularly with another key
> 
> Yep that's your way to go :)
> 
>> (btw: is it with LUKS possible to do this on the fly?)?
> Nope. Not yet. It's possible to code it, though :)

Maybe one day it will be there but probably as part of LVM
(which will use libcryptsetup for key management for encrypted
logical volumes).

It is possible to encode some simple function to reencode disk
in-place. But I would like to have something better, LVM
already provides most of infrastructure for such block device
operations. (beware: I am also lvm developer:)

Milan

Re: [dm-crypt] Including the FAQ in the tarball?

[Heinz Diehl]

On 28.07.2010, Christoph Anton Mitterer wrote: 

> I'd like to see the FAQ as text file or so being part of the tarball...
> especially as it's not guaranteed that users will ever stumble across
> the website.

A up-to-date FAQ should always be included in all forthcoming releases, of
course. Looking for documentation in the tarball itself is (nja, should be) 
what's most natural to anybody, before looking elsewhere.

Re: [dm-crypt] XTS cipher mode limitations

[Christoph Anton Mitterer]

Hi.

Sorry for re-visiting this issue one (hopefully) last time... but at
least to me not everything was fully clear yet.
And I guess having a final conclusion which we could also put in the FAQ
would be not to bad.

With respect to XTS:

1) I guess we've already concluded that it's one of the securest modes
available (if not the securest),... also protecting against certain
attacks for which the others are vulnerable.


2) There was this IV boundary issue when using just "plain",... but this
is effectively none, if one uses "plain64"... as this is enough for
2^64*512byte volumes.
Right?


3) There was a limitation on the block size, used with XTS, right? But
as we _always_ use 512 byte (even if the device below uses larger
sectors), we're fine anyway.
Right?


4) There was the (general issue) that if an attacker can make
snapshots,... you can only write some amount of data (with the same key)
until probability increases that attacks are possible, right?

Is this only the case when he can make snapshots?

In XTS, this starts to get a problem after about 100TB (IIRC) of data
have been written, right?
So the "solution" to this is: periodic re-encoding


5) Not sure whether I just didn't understand this,... but was'n there
another limit with respect to about 1TB? And what was that about?



So in the end we could put in the FAQ, that with XTS:
- users should use plain64
- periodically re-encode before about 100TB
- 1TB thingy?!


Are there any other general things one should consider?
(Of course I assume, that attackers have no easier way, e.g. via
internet/software exploits or via physical force)



Thanks,
Chris.


btw:
On Wed, 2010-07-28 at 10:42 +0200, Milan Broz wrote:
> Maybe one day it will be there but probably as part of LVM
> (which will use libcryptsetup for key management for encrypted
> logical volumes).
> 
> It is possible to encode some simple function to reencode disk
> in-place. But I would like to have something better, LVM
> already provides most of infrastructure for such block device
> operations. (beware: I am also lvm developer:)
And? Already started coding? ;)


btw2: Point (3) leads me to a different question.
Imagin I have a disk with 4k sectors, put dm-crypt on it,... then the
logical ones are 512 byte sectors, right?
Now I put another layer or a filesystem on top.
What happen's to the alignment now? Will it use 4k or 512 bytes?

Re: [dm-crypt] XTS cipher mode limitations

[Arno Wagner]

Hi Chris,

hope I remember this right.

On Fri, Aug 20, 2010 at 11:11:48PM +0200, Christoph Anton Mitterer wrote:
> Hi.
> 
> Sorry for re-visiting this issue one (hopefully) last time... but at
> least to me not everything was fully clear yet.
> And I guess having a final conclusion which we could also put in the FAQ
> would be not to bad.
> 
> With respect to XTS:
> 
> 1) I guess we've already concluded that it's one of the securest modes
> available (if not the securest),... also protecting against certain
> attacks for which the others are vulnerable.

Yes.
 
> 2) There was this IV boundary issue when using just "plain",... but this
> is effectively none, if one uses "plain64"... as this is enough for
> 2^64*512byte volumes.
> Right?

Yes. Although plain64 is not available on older kernels.
 

> 3) There was a limitation on the block size, used with XTS, right? But
> as we _always_ use 512 byte (even if the device below uses larger
> sectors), we're fine anyway.
> Right?

Yes. 
 
> 4) There was the (general issue) that if an attacker can make
> snapshots,... you can only write some amount of data (with the same key)
> until probability increases that attacks are possible, right?

Yes. Not an XTS-related problem though, but general
for block encryption as needed with filesystems.

> Is this only the case when he can make snapshots?

Yes, the attacker needs all data, as he/she is looking for collisons.
If I understand thios right, the attacker does however not need to
store all date, a, say, 128 bit hash and a 64 bit block number
would be enough. That is 24 Byte/Block and for, say, 100TB, 
this is about 5TB. Then the attackler would need to search 
for duplicates in the hash part (i.e. about 3TB). Quite 
a bit of effort for very little data exposure.

> In XTS, this starts to get a problem after about 100TB (IIRC) of data
> have been written, right?

Depending on paranoia level:  1....1000TB
Note that is risks exposing that two single disk blocks have 
the same content, which generally is not a problem at all. 

Also note that the attacker needs to store 

> So the "solution" to this is: periodic re-encoding

Or ignore it, as it does not help the attacker in most cases
and an the attacker has massive effort (storing a lot of TBs of
data and then checking for matches).
 
> 5) Not sure whether I just didn't understand this,... but was'n there
> another limit with respect to about 1TB? And what was that about?

No. It is just that below 1TB the possibility for this attack is
low enouigh to effectively be zero. 
  
> So in the end we could put in the FAQ, that with XTS:
> - users should use plain64

Only for volumes > 2TB. Already in there.

> - periodically re-encode before about 100TB
> - 1TB thingy?!

No sure it makes sense. But I can put it in there.

Was there a literature reference for the attack? 
If I out this into the FAQ, then I need to 
get it right as it is something more complicated and the
data exposure is low enough that most people rightfully 
will not care and most attackers will not be able to do it
anyways due to the high anount of storage needed.
 
> Are there any other general things one should consider?
> (Of course I assume, that attackers have no easier way, e.g. via
> internet/software exploits or via physical force)

Not that I can see at the moment.

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] XTS cipher mode limitations (FAQ additions)

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

Hi Arno.

Thanks for that =)

On Sat, 2010-08-21 at 02:22 +0200, Arno Wagner wrote:
> > 1) I guess we've already concluded that it's one of the securest modes
> > available (if not the securest),... also protecting against certain
> > attacks for which the others are vulnerable.
> Yes.

I know this will probably lead to some discussion ;) ... but should we
perhaps suggest this in the FAQ?
E.g. something like a section "Which mode should one use?", and then XTS
withstands currently most known attacks, it has been standardised by
IEEE (1619 IIRC). etc. pp.
Perhaps also than one should use plain64 in all kernels supporting it,
and at least when device > 2TB.


btw: In the question "Can I resize a dm-crypt or LUKS partition?", you
say one should not use it with > 2TB.
May I suggest to add a (see <link to Are there any problems with "plain"
IV? What is "plain64"?>)? Other wise people may miss that it's ok to use
it with > 2TB when plain 64 is used.



May I suggest that all occurrences of e.g. 2 TB are replaced by e.g. 2
TiB?


May I further suggest, that in all references to 2TB, we add "(= 2^32 *
512 bytes)"?
There's always that problem that one never knows whether TB really means
TB or TiB.


> > 3) There was a limitation on the block size, used with XTS, right? But
> > as we _always_ use 512 byte (even if the device below uses larger
> > sectors), we're fine anyway.
> > Right?
> Yes.
Perhap we can add this to the FAQ, too.
People may have read about it,... but don't know whether it's a problem
or not. So telling them "no everything's fine as long as our blocky are
smaller than xxxx bytes) can be a good idea.
Especially as the wikipedia article contains some FUD about this.


> > - periodically re-encode before about 100TB
> > - 1TB thingy?!
> 
> No sure it makes sense. But I can put it in there.

I'd suggest so,... for people with the highest paranoia ;)
Perhaps with a note, that this is probably not such a big problem for
many scenarios.

Also adding that this is a general problem, what one can do against it,
and the rough values when it is estimated to become a problem (e.g. for
XTS).



> Was there a literature reference for the attack? 
> If I out this into the FAQ, then I need to 
> get it right as it is something more complicated and the
> data exposure is low enough that most people rightfully 
> will not care and most attackers will not be able to do it
> anyways due to the high anount of storage needed.
Uhm... no idea unfortunately...


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations)

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

Hi.


Regarding this attacks involving snapshots and the total amount of data
written to an encrypted volume.

Is there an easy way or perhaps even a working tool, which accounts the
total amount of bytes written to a given block device (either directly
or via something that is on top of that block device (filesystem or
other block device layers)?

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations)

[Arno Wagner]

bwm-ng does it, so it must be possible. 
I think /proc/diskstats is the place to look.

Arno

On Sun, Aug 22, 2010 at 02:56:52PM +0200, Christoph Anton Mitterer wrote:
> Hi.
> 
> 
> Regarding this attacks involving snapshots and the total amount of data
> written to an encrypted volume.
> 
> Is there an easy way or perhaps even a working tool, which accounts the
> total amount of bytes written to a given block device (either directly
> or via something that is on top of that block device (filesystem or
> other block device layers)?
> 
> Cheers,
> Chris.



> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
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] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations)

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

On Sun, 2010-08-22 at 18:01 +0200, Arno Wagner wrote:
> I think /proc/diskstats is the place to look.
Yeah,... of course,... I just didn't want to make my hands dirty with
"programming" ;) (actually I didn't want to invent the cycle twice ;) )

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] XTS cipher mode limitations (FAQ additions)

[Arno Wagner]

On Sun, Aug 22, 2010 at 02:50:32PM +0200, Christoph Anton Mitterer wrote:
> Hi Arno.
> 
> Thanks for that =)
> 
> On Sat, 2010-08-21 at 02:22 +0200, Arno Wagner wrote:
> > > 1) I guess we've already concluded that it's one of the securest modes
> > > available (if not the securest),... also protecting against certain
> > > attacks for which the others are vulnerable.
> > Yes.
> 
> I know this will probably lead to some discussion ;) ... but should we
> perhaps suggest this in the FAQ?
> E.g. something like a section "Which mode should one use?", and then XTS
> withstands currently most known attacks, it has been standardised by
> IEEE (1619 IIRC). etc. pp.
> Perhaps also than one should use plain64 in all kernels supporting it,
> and at least when device > 2TB.


I think the item "What about XTS mode?" already covers that.

 
> btw: In the question "Can I resize a dm-crypt or LUKS partition?", you
> say one should not use it with > 2TB.
> May I suggest to add a (see <link to Are there any problems with "plain"
> IV? What is "plain64"?>)? Other wise people may miss that it's ok to use
> it with > 2TB when plain 64 is used.


Added.

 
> May I suggest that all occurrences of e.g. 2 TB are replaced by e.g. 2
> TiB?

Since I typically insist on that, I should have done this in 
the first place. Diexed also for MB and kB. (No GB in there)

 
> 
> May I further suggest, that in all references to 2TB, we add "(= 2^32 *
> 512 bytes)"?
> There's always that problem that one never knows whether TB really means
> TB or TiB.

Instead changed all 2TB to 2TiB. 

 
> > > 3) There was a limitation on the block size, used with XTS, right? But
> > > as we _always_ use 512 byte (even if the device below uses larger
> > > sectors), we're fine anyway.
> > > Right?
> > Yes.
> Perhap we can add this to the FAQ, too.
> People may have read about it,... but don't know whether it's a problem
> or not. So telling them "no everything's fine as long as our blocky are
> smaller than xxxx bytes) can be a good idea.
> Especially as the wikipedia article contains some FUD about this.

Added.
 
 
> > > - periodically re-encode before about 100TB
> > > - 1TB thingy?!
> > 
> > No sure it makes sense. But I can put it in there.
> 
> I'd suggest so,... for people with the highest paranoia ;)
> Perhaps with a note, that this is probably not such a big problem for
> many scenarios.
> 
> Also adding that this is a general problem, what one can do against it,
> and the rough values when it is estimated to become a problem (e.g. for
> XTS).
> 
> 
> 
> > Was there a literature reference for the attack? 
> > If I out this into the FAQ, then I need to 
> > get it right as it is something more complicated and the
> > data exposure is low enough that most people rightfully 
> > will not care and most attackers will not be able to do it
> > anyways due to the high anount of storage needed.
> Uhm... no idea unfortunately...

Well, if it comes up again, I can look at it.  I will 
however not start to distribute my own FUD and I am 
not a good enough cryptographer for a really thorough
analysis of the issue. I am willing to read a paper on
it if somebody else provides the link ;-)

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] tool to account the written number of bytes to a block device

[Milan Broz]

On 08/22/2010 11:57 PM, Christoph Anton Mitterer wrote:
> On Sun, 2010-08-22 at 18:01 +0200, Arno Wagner wrote:
>> I think /proc/diskstats is the place to look.
> Yeah,... of course,... I just didn't want to make my hands dirty with
> "programming" ;) (actually I didn't want to invent the cycle twice ;) )

iostat -N ?

(and save results after reboot)

Milan

Re: [dm-crypt] XTS cipher mode limitations

[Ramius]

Hi everyone :)

2010/8/21 Arno Wagner <arno@wagner.name>
>
> Hi Chris,
>
> hope I remember this right.
>
> On Fri, Aug 20, 2010 at 11:11:48PM +0200, Christoph Anton Mitterer wrote:
>
> > 2) There was this IV boundary issue when using just "plain",... but this
> > is effectively none, if one uses "plain64"... as this is enough for
> > 2^64*512byte volumes.
> > Right?
>
> Yes. Although plain64 is not available on older kernels.

Is it advisable to use essiv with xts, where plain64 is not available?
What are advantages/disadvantages of this combination?

Cheers.

Re: [dm-crypt] tool to account the written number of bytes to a block device

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

On Mon, 2010-08-23 at 09:14 +0200, Milan Broz wrote:
> iostat -N ?
Ah... that sounds nice...

Will have a look whether it also supports infinite logging of the data
=)


Thx,
Chris

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] XTS cipher mode limitations (FAQ additions)

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

Hi Arno.

Thanks for the other changes =)

On Mon, 2010-08-23 at 02:46 +0200, Arno Wagner wrote:
> Since I typically insist on that, I should have done this in 
> the first place.
;-)

> Diexed also for MB and kB. (No GB in there)
Yeah,.. I meant of course all of them =)


> > May I further suggest, that in all references to 2TB, we add "(= 2^32 *
> > 512 bytes)"?
> > There's always that problem that one never knows whether TB really means
> > TB or TiB.
> Instead changed all 2TB to 2TiB. 
I guess it could be still nice to show the "forumla"... so that people
know how that 2 TiB come together... (guess many don't know that dmcrypt
_always_ uses 512 byte blocks).


btw: That might even qualify for its own FAQ entry,... that it uses
always 512byte blocks, and that e.g. the number in the payload offset
from luksDump are also blocks.



> Well, if it comes up again, I can look at it.  I will 
> however not start to distribute my own FUD and I am 
> not a good enough cryptographer for a really thorough
> analysis of the issue. I am willing to read a paper on
> it if somebody else provides the link ;-)
Once you should add it... don't forget (which I just realised recently
^^) that it's about the written data in blocks,... not just the written
data itself, at least if I understand it correctly.

So say we _would_ have a hard limit on 1TB, and I'd just write 1 bit,
I'd still have "used up" 512 bytes from my safety buffer, before having
to re-encode, right?

btw: Milan, do you know about any paper dealing with that issue?


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]