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

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

[Arno Wagner]

On Mon, Jul 26, 2010 at 10:38:06PM +0200, Christoph Anton Mitterer wrote:
> 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?!

Actually, it is the "plain" implementation that causes a 2TB limit 
because of repeating IVs. XTS has a block size limit, at 2^20 bits, 
(I think) but it is a recommended limit. As 512 bytes we are well 
below that :-)
 
> > 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... ;)

Well...

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: 791 bytes --]

On Mon, 2010-07-26 at 23:07 +0200, Arno Wagner wrote:
> > So you guess the the 1TB limit could be actually a "don't have blocks
> > larger than 1TB" limit?!
> Actually, it is the "plain" implementation that causes a 2TB limit 
> because of repeating IVs. XTS has a block size limit, at 2^20 bits, 
> (I think) but it is a recommended limit. As 512 bytes we are well 
> below that :-)
So you mean we have two limits?

1) The limit related to the IVs that we get from "plain" after 32bit 512
byte blocks, or that we would get from plain64 on a Zettabyte device.

2) Another limit, on the maximum block size (which was misconceived as a
maximum filesystem size) that can be securely used which is that 1TB
thingy?
However we should never hit that one too?!


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: 262 bytes --]

Well....

I've just read some sections of the Standard... D4 and D6... it rather
seems that really the whole size (of the partition) is meant,... and not
just the block size... although they speak of ranges > 100 TB


*confused now*


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:31:56PM +0200, Christoph Anton Mitterer wrote:
> On Mon, 2010-07-26 at 23:07 +0200, Arno Wagner wrote:
> > > So you guess the the 1TB limit could be actually a "don't have blocks
> > > larger than 1TB" limit?!
> > Actually, it is the "plain" implementation that causes a 2TB limit 
> > because of repeating IVs. XTS has a block size limit, at 2^20 bits, 
> > (I think) but it is a recommended limit. As 512 bytes we are well 
> > below that :-)
> So you mean we have two limits?

Yes. One on the block number and one on the block size.
 
> 1) The limit related to the IVs that we get from "plain" after 32bit 512
> byte blocks, or that we would get from plain64 on a Zettabyte device.

That is IV limit, i.e. the limit on the block numbers.

> 2) Another limit, on the maximum block size (which was misconceived as a
> maximum filesystem size) that can be securely used which is that 1TB
> thingy?
> However we should never hit that one too?!

That is the size for the individual blocks encrypted. For
dm-crypt/LUKS we use 512 byte blocks, but XTS can do much larger.
However beyond a certain block size it security is suspected to 
degrade. I looked the limits up again, the hard limit is 
(2^128)-2 x 128 bit blocks. If I understand this correctly 
exceeding this limit breaks the cipher. Then there is the 
soft limit of 2^20 x 128 bit, i.e. 16MB block size. The block
size should be kept below that and 512B is well below it. 

I do not know of any 1TB limit.

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 Mon, Jul 26, 2010 at 11:42:37PM +0200, Christoph Anton Mitterer wrote:
> Well....
> 
> I've just read some sections of the Standard... D4 and D6... it rather
> seems that really the whole size (of the partition) is meant,... and not
> just the block size... although they speak of ranges > 100 TB
> 
> 
> *confused now*
> 
> 
> Cheers,
> Chris.

I suspect that comes from only 2^128 possible cipher blocks and the
birthday paradox which would give you the same cipher block twice
when having around 2^64 blocks (modelled as random).

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:
> I've just read some sections of the Standard... D4 and D6... it rather
> seems that really the whole size (of the partition) is meant,... and not

No, no, no, hell, no. They don't mean a size of a partition, or a disk
or whatever. They talk about an amount of data because they mean exactly
that: an amount of data encrypted using the same key.

If you set up dm-crypt with aes-xts-plain on a 500G partition, fill it
up with data, remove everything and fill it up again with other data you
*did* encrypt 1TB of data using the same key despite the fact that your
partition might only be 500G.
Please feel free to re-proceed the exercise with a 250G partition.

Of course, your attacker has to be able to capture a snapshot after the
first fill-up ... probably via some forensic magic - people who believe
in encryption often tend to also still believe in Peter Gutmann :)


regards
   Mario
-- 
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.
                                -- Bruce Schneier

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

[Arno Wagner]

On Tue, Jul 27, 2010 at 01:42:01AM +0200, Mario 'BitKoenig' Holbe wrote:
> Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de> wrote:
> > I've just read some sections of the Standard... D4 and D6... it rather
> > seems that really the whole size (of the partition) is meant,... and not
> 
> No, no, no, hell, no. They don't mean a size of a partition, or a disk
> or whatever. They talk about an amount of data because they mean exactly
> that: an amount of data encrypted using the same key.
> 
> If you set up dm-crypt with aes-xts-plain on a 500G partition, fill it
> up with data, remove everything and fill it up again with other data you
> *did* encrypt 1TB of data using the same key despite the fact that your
> partition might only be 500G.
> Please feel free to re-proceed the exercise with a 250G partition.
> 
> Of course, your attacker has to be able to capture a snapshot after the
> first fill-up ... 

And that is the real limit in practice. This is more relevant for,
e.g., encrypting tape backups or other backups were a number
of generations is kept. If I understand this correctly, the
actual data exposure if you encrypt in the order of 2^(n/2)
bits, with n your block lenght, is very small, namely two blocks. 
But I would need to check to be sure.

> probably via some forensic magic - people who believe
> in encryption often tend to also still believe in Peter Gutmann :)

Here I highly recomment the Epilogue, were Gutmann puts that into 
perspective for modern drives: "...it's unlikely that anything 
can be recovered from any recent drive except perhaps a single 
level via basic error-cancelling techniques...". Also note that 
nobody claims to sucessfully have done that and all major data
recovery outfits claim they cannot recover anything after a single
overwerwrite with zeros on modern drives. Also note that tape is very
different and Gutmann still applies there. (Original paper with
updates: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html)
 
> regards
>    Mario
> -- 
> If you think technology can solve your problems you don't understand
> technology and you don't understand your problems.
>                                 -- Bruce Schneier

Nice quote! 

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

[Uwe Menges]

On 07/27/2010 01:42 AM, Mario 'BitKoenig' Holbe wrote:
> Of course, your attacker has to be able to capture a snapshot after the
> first fill-up ... probably via some forensic magic - people who believe
> in encryption often tend to also still believe in Peter Gutmann :)

No forensic magic is needed if you are eg. using a LUKS crypted iSCSI
volume and the attacker is able to mirror you network traffic.

Cheers, Uwe

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

[Arno Wagner]

On Sun, Aug 15, 2010 at 07:26:44PM +0200, Uwe Menges wrote:
> On 07/27/2010 01:42 AM, Mario 'BitKoenig' Holbe wrote:
> > Of course, your attacker has to be able to capture a snapshot after the
> > first fill-up ... probably via some forensic magic - people who believe
> > in encryption often tend to also still believe in Peter Gutmann :)
> 
> No forensic magic is needed if you are eg. using a LUKS crypted iSCSI
> volume and the attacker is able to mirror you network traffic.
> 
> Cheers, Uwe

Well, if the attacker mirrors your network traffic with iSCSI, 
encryption does not matter anymore for any change analysis.

But using such a set-up wpuld be pretty stupid anayways.... ;-)

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:
> Well, if the attacker mirrors your network traffic with iSCSI, 
> encryption does not matter anymore for any change analysis.
> But using such a set-up wpuld be pretty stupid anayways.... ;-)

Why? Do you have better ideas how to circumvent trusting your remote
Backup Provider than encrypting everything before sending it away?

Encrypted block-devices via iSCSI, AoE, or NBD are some of the more
comfortable solutions I'm thinking about when it comes to efficient
remote multi-generation backups (using rsnapshot on top, for example).


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

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

[Arno Wagner]

On Mon, Aug 16, 2010 at 01:44:59PM +0200, Mario 'BitKoenig' Holbe wrote:
> Arno Wagner <arno@wagner.name> wrote:
> > Well, if the attacker mirrors your network traffic with iSCSI, 
> > encryption does not matter anymore for any change analysis.
> > But using such a set-up wpuld be pretty stupid anayways.... ;-)
> 
> Why? Do you have better ideas how to circumvent trusting your remote
> Backup Provider than encrypting everything before sending it away?
>
> Encrypted block-devices via iSCSI, AoE, or NBD are some of the more
> comfortable solutions I'm thinking about when it comes to efficient
> remote multi-generation backups (using rsnapshot on top, for example).

I should have said "...pretty stupid anyways, if you are worried
about a change analysis attack.".

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

[octane indice]

En réponse à Arno Wagner <arno@wagner.name> :
> Well, if the attacker mirrors your network traffic with iSCSI,
> encryption does not matter anymore for any change analysis.
>
I don't know if it is the right place to ask, but do you have
any links with this "change analysis" thing ?

Thanks 
I.Octane
 
> _______________________________________________
> 




Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

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

[Arno Wagner]

On Mon, Aug 16, 2010 at 02:55:44PM +0200, octane indice wrote:
> En r?ponse ? Arno Wagner <arno@wagner.name> :
> > Well, if the attacker mirrors your network traffic with iSCSI,
> > encryption does not matter anymore for any change analysis.
> >
> I don't know if it is the right place to ask, but do you have
> any links with this "change analysis" thing ?

Not really. What it does is expose on sector level (xts, EME)
what parts of the filesystem are changed. The idea is that
this can form a distinctice pattern, for example "Netscape
is launching", "An email was received in mbox format" or
"A Skype connection was initiated". In some contexts, this 
type of information leakage can be a risk. 

Typically this is only a risk in a SigInt context, were 
people have long ago given up reading content (because 
it is too much effort with encryption or even infeasible), 
but look at traffic patterns. For example, it seems you can 
pretty clearly see from the pattern whether a military 
attack is imminent.

This is advanced IT Security vodoo and not really relevant
for most users. The one context I can think of were it
becomes relevant is if a specific application intentionally
cause some kind of pattern to either signal it has been
started or to actually leak information. For example
a corrupted encryption program couls signal key-bits
to the world in this fashion. Note that this is not
really relevant for anything that has net access, as there 
bits are far easier to leak or directly send to the attacker.
For most typical usage it is not a relevant threat.

If you have questions, I will be happy to elaborate more.

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: 565 bytes --]

Hi.


But this goes IMO more in the plausible denyability direction, doesn't
it?
An attacker would still be not able to read what was written.
And for most applications it should be extremely difficult or even
impossible to make any conclusions,.. because of fragmentation... etc.
pp.

Another issue is of course when you have corrupted programs in the
system.... but then you're screwed anyway,... and there are usually much
easier to implement hidden channels.... (but this argument shouldn't
count as I always say myself ;) ).


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 Sat, Aug 21, 2010 at 10:45:35PM +0200, Christoph Anton Mitterer wrote:
> Hi.
> 
> 
> But this goes IMO more in the plausible denyability direction, doesn't
> it?

I think not even that. The attacker already know you likely have
encrypted data or a lot of randomness. But then you have been
changing that in a typical pattern for filesystem access.

The data leakage is real, but very, very low in volume and will
not matter in almost all situations IMO, and therefore nobody
will bother attacking that. Now if you store and process
highly sensitive data in the exabyte-range, it might be a
minor concern (an attacker could plant a document and later
detect ot has been added to the encrypted device), but even
there effort is extreme. 

This is an example of an academic attack. Interesting, and
show a real limit of the employed encryption method, but
irrelevant for the real world.

> An attacker would still be not able to read what was written.
> And for most applications it should be extremely difficult or even
> impossible to make any conclusions,.. because of fragmentation... etc.
> pp.

I agree.

> Another issue is of course when you have corrupted programs in the
> system.... but then you're screwed anyway,... and there are usually much
> easier to implement hidden channels.... (but this argument shouldn't
> count as I always say myself ;) ).

Indeed. Just use a sequence of secors, and change or not them 
in a pattern.

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: 288 bytes --]

On Sun, 2010-08-22 at 01:14 +0200, Arno Wagner wrote:
> data in the exabyte-range
Uhm... guess the only guys which have secret data in that range find it
recently published at wikileaks anyway... ;) *HawHaw*
Perhaps we should CC the US DoD in this thread.... ^^


Cheers,
Chris.

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

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] 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] 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] 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] 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 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: 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

[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: 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

[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

[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

[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]

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

[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

[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

[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

[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

[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: 303 bytes --]

On Sun, 2010-07-25 at 15:25 -0700, Ietf Nist wrote:
> In debian bugreport #494584, the IETF NIST submission for cipher XTS was
> mentioned and linked.
So that one is the final submission? Perhaps someone (with crypto
knowledge) can compare it with what Linux' xts module does?


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: 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

[Ietf Nist]

Hello,

On 25/07/2010 Milan Broz wrote:
> 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 

In debian bugreport #494584, the IETF NIST submission for cipher XTS was
mentioned and linked. IETF had it online publically available until the
3. of September 2008. I fetched this document by then, and uploaded it
to several free file hosters:

http://www.filefactory.com/file/b2b8488/n/1619-2007-NIST-Submission.pdf
http://ul.to/uzyryq
http://speedshare.org/download.php?id=EBD56BF911
http://www.mediafire.com/?asf5nocdx75svsa
http://rapidshare.com/files/409054345/1619-2007-NIST-Submission.pdf
http://collectr.in/?d=16631C421

Be aware though that it's prohibited to copy and/or redistribute this
document.

Have fun.

PS: don't reply to sender address, it's a fake account. instead you
should reply to the mailing list directly: dm-crypt@saout.de



      

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

[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

[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

[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

[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

[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

[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

[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

[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 

[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.