* [dm-crypt] Efficacy of xts over 1TB @ 2010-07-22 14:57 David Santamaría Rogado 2010-07-25 10:34 ` Arno Wagner ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: David Santamaría Rogado @ 2010-07-22 14:57 UTC (permalink / raw) To: dm-crypt 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-22 14:57 [dm-crypt] Efficacy of xts over 1TB David Santamaría Rogado @ 2010-07-25 10:34 ` Arno Wagner 2010-07-25 11:18 ` Christoph Anton Mitterer ` (2 more replies) 2010-07-26 9:17 ` Mario 'BitKoenig' Holbe 2010-07-27 18:42 ` David Santamaría Rogado 2 siblings, 3 replies; 55+ messages in thread From: Arno Wagner @ 2010-07-25 10:34 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 10:34 ` Arno Wagner @ 2010-07-25 11:18 ` Christoph Anton Mitterer 2010-07-25 12:29 ` Heinz Diehl 2010-07-25 12:25 ` Milan Broz 2010-07-26 9:04 ` Mario 'BitKoenig' Holbe 2 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-25 11:18 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 11:18 ` Christoph Anton Mitterer @ 2010-07-25 12:29 ` Heinz Diehl 0 siblings, 0 replies; 55+ messages in thread From: Heinz Diehl @ 2010-07-25 12:29 UTC (permalink / raw) To: dm-crypt 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 10:34 ` Arno Wagner 2010-07-25 11:18 ` Christoph Anton Mitterer @ 2010-07-25 12:25 ` Milan Broz 2010-07-25 13:14 ` Christoph Anton Mitterer 2010-07-25 15:28 ` Arno Wagner 2010-07-26 9:04 ` Mario 'BitKoenig' Holbe 2 siblings, 2 replies; 55+ messages in thread From: Milan Broz @ 2010-07-25 12:25 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 12:25 ` Milan Broz @ 2010-07-25 13:14 ` Christoph Anton Mitterer 2010-07-25 13:52 ` Milan Broz 2010-07-25 15:32 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner 2010-07-25 15:28 ` Arno Wagner 1 sibling, 2 replies; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-25 13:14 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 13:14 ` Christoph Anton Mitterer @ 2010-07-25 13:52 ` Milan Broz 2010-07-25 22:37 ` Christoph Anton Mitterer 2010-07-25 22:52 ` Christoph Anton Mitterer 2010-07-25 15:32 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner 1 sibling, 2 replies; 55+ messages in thread From: Milan Broz @ 2010-07-25 13:52 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 13:52 ` Milan Broz @ 2010-07-25 22:37 ` Christoph Anton Mitterer 2010-07-26 0:14 ` Milan Broz 2010-07-26 8:53 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner 2010-07-25 22:52 ` Christoph Anton Mitterer 1 sibling, 2 replies; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-25 22:37 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 22:37 ` Christoph Anton Mitterer @ 2010-07-26 0:14 ` Milan Broz 2010-07-26 20:38 ` Christoph Anton Mitterer 2010-07-26 8:53 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner 1 sibling, 1 reply; 55+ messages in thread From: Milan Broz @ 2010-07-26 0:14 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 0:14 ` Milan Broz @ 2010-07-26 20:38 ` Christoph Anton Mitterer 2010-07-27 8:46 ` [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt Milan Broz 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-26 20:38 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-26 20:38 ` Christoph Anton Mitterer @ 2010-07-27 8:46 ` Milan Broz 2010-07-27 10:47 ` Arno Wagner 2010-07-27 14:15 ` Christoph Anton Mitterer 0 siblings, 2 replies; 55+ messages in thread From: Milan Broz @ 2010-07-27 8:46 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 8:46 ` [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt Milan Broz @ 2010-07-27 10:47 ` Arno Wagner 2010-07-27 14:17 ` Christoph Anton Mitterer 2010-07-27 14:15 ` Christoph Anton Mitterer 1 sibling, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-07-27 10:47 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 10:47 ` Arno Wagner @ 2010-07-27 14:17 ` Christoph Anton Mitterer 2010-07-27 16:08 ` Arno Wagner 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-27 14:17 UTC (permalink / raw) To: Arno Wagner; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 14:17 ` Christoph Anton Mitterer @ 2010-07-27 16:08 ` Arno Wagner 0 siblings, 0 replies; 55+ messages in thread From: Arno Wagner @ 2010-07-27 16:08 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 8:46 ` [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt Milan Broz 2010-07-27 10:47 ` Arno Wagner @ 2010-07-27 14:15 ` Christoph Anton Mitterer 2010-07-27 15:45 ` Mario 'BitKoenig' Holbe 1 sibling, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-27 14:15 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 14:15 ` Christoph Anton Mitterer @ 2010-07-27 15:45 ` Mario 'BitKoenig' Holbe 2010-07-27 15:55 ` Milan Broz ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Mario 'BitKoenig' Holbe @ 2010-07-27 15:45 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 15:45 ` Mario 'BitKoenig' Holbe @ 2010-07-27 15:55 ` Milan Broz 2010-07-27 18:59 ` Christoph Anton Mitterer 2010-07-27 18:58 ` Christoph Anton Mitterer 2010-07-28 8:42 ` Milan Broz 2 siblings, 1 reply; 55+ messages in thread From: Milan Broz @ 2010-07-27 15:55 UTC (permalink / raw) To: Mario 'BitKoenig' Holbe; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 15:55 ` Milan Broz @ 2010-07-27 18:59 ` Christoph Anton Mitterer 2010-07-27 19:37 ` Arno Wagner 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-27 18:59 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt, Mario 'BitKoenig' Holbe [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 18:59 ` Christoph Anton Mitterer @ 2010-07-27 19:37 ` Arno Wagner 0 siblings, 0 replies; 55+ messages in thread From: Arno Wagner @ 2010-07-27 19:37 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 15:45 ` Mario 'BitKoenig' Holbe 2010-07-27 15:55 ` Milan Broz @ 2010-07-27 18:58 ` Christoph Anton Mitterer 2010-07-27 19:35 ` Mario 'BitKoenig' Holbe 2010-07-28 8:42 ` Milan Broz 2 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-27 18:58 UTC (permalink / raw) To: Mario 'BitKoenig' Holbe; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 18:58 ` Christoph Anton Mitterer @ 2010-07-27 19:35 ` Mario 'BitKoenig' Holbe 0 siblings, 0 replies; 55+ messages in thread From: Mario 'BitKoenig' Holbe @ 2010-07-27 19:35 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt 2010-07-27 15:45 ` Mario 'BitKoenig' Holbe 2010-07-27 15:55 ` Milan Broz 2010-07-27 18:58 ` Christoph Anton Mitterer @ 2010-07-28 8:42 ` Milan Broz 2010-08-20 21:11 ` [dm-crypt] XTS cipher mode limitations Christoph Anton Mitterer 2 siblings, 1 reply; 55+ messages in thread From: Milan Broz @ 2010-07-28 8:42 UTC (permalink / raw) To: Mario 'BitKoenig' Holbe; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] XTS cipher mode limitations 2010-07-28 8:42 ` Milan Broz @ 2010-08-20 21:11 ` Christoph Anton Mitterer 2010-08-21 0:22 ` Arno Wagner 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-08-20 21:11 UTC (permalink / raw) To: dm-crypt; +Cc: Milan Broz 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? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] XTS cipher mode limitations 2010-08-20 21:11 ` [dm-crypt] XTS cipher mode limitations Christoph Anton Mitterer @ 2010-08-21 0:22 ` Arno Wagner 2010-08-22 12:50 ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Arno Wagner @ 2010-08-21 0:22 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] XTS cipher mode limitations (FAQ additions) 2010-08-21 0:22 ` Arno Wagner @ 2010-08-22 12:50 ` Christoph Anton Mitterer 2010-08-23 0:46 ` Arno Wagner 2010-08-22 12:56 ` [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) Christoph Anton Mitterer 2010-08-24 16:19 ` [dm-crypt] XTS cipher mode limitations Ramius 2 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-08-22 12:50 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] XTS cipher mode limitations (FAQ additions) 2010-08-22 12:50 ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer @ 2010-08-23 0:46 ` Arno Wagner 2010-08-25 9:36 ` Christoph Anton Mitterer 0 siblings, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-08-23 0:46 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] XTS cipher mode limitations (FAQ additions) 2010-08-23 0:46 ` Arno Wagner @ 2010-08-25 9:36 ` Christoph Anton Mitterer 0 siblings, 0 replies; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-08-25 9:36 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) 2010-08-21 0:22 ` Arno Wagner 2010-08-22 12:50 ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer @ 2010-08-22 12:56 ` Christoph Anton Mitterer 2010-08-22 16:01 ` Arno Wagner 2010-08-24 16:19 ` [dm-crypt] XTS cipher mode limitations Ramius 2 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-08-22 12:56 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) 2010-08-22 12:56 ` [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) Christoph Anton Mitterer @ 2010-08-22 16:01 ` Arno Wagner 2010-08-22 21:57 ` Christoph Anton Mitterer 0 siblings, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-08-22 16:01 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) 2010-08-22 16:01 ` Arno Wagner @ 2010-08-22 21:57 ` Christoph Anton Mitterer 2010-08-23 7:14 ` [dm-crypt] tool to account the written number of bytes to a block device Milan Broz 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-08-22 21:57 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] tool to account the written number of bytes to a block device 2010-08-22 21:57 ` Christoph Anton Mitterer @ 2010-08-23 7:14 ` Milan Broz 2010-08-25 9:27 ` Christoph Anton Mitterer 0 siblings, 1 reply; 55+ messages in thread From: Milan Broz @ 2010-08-23 7:14 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] tool to account the written number of bytes to a block device 2010-08-23 7:14 ` [dm-crypt] tool to account the written number of bytes to a block device Milan Broz @ 2010-08-25 9:27 ` Christoph Anton Mitterer 0 siblings, 0 replies; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-08-25 9:27 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] XTS cipher mode limitations 2010-08-21 0:22 ` Arno Wagner 2010-08-22 12:50 ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer 2010-08-22 12:56 ` [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) Christoph Anton Mitterer @ 2010-08-24 16:19 ` Ramius 2 siblings, 0 replies; 55+ messages in thread From: Ramius @ 2010-08-24 16:19 UTC (permalink / raw) To: dm-crypt 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 22:37 ` Christoph Anton Mitterer 2010-07-26 0:14 ` Milan Broz @ 2010-07-26 8:53 ` Arno Wagner 2010-07-26 20:47 ` Christoph Anton Mitterer 1 sibling, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-07-26 8:53 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 8:53 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner @ 2010-07-26 20:47 ` Christoph Anton Mitterer 2010-07-26 21:01 ` Arno Wagner 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-26 20:47 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 20:47 ` Christoph Anton Mitterer @ 2010-07-26 21:01 ` Arno Wagner 2010-07-26 21:28 ` Christoph Anton Mitterer 0 siblings, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-07-26 21:01 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 21:01 ` Arno Wagner @ 2010-07-26 21:28 ` Christoph Anton Mitterer 2010-07-26 21:35 ` Arno Wagner 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-26 21:28 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 21:28 ` Christoph Anton Mitterer @ 2010-07-26 21:35 ` Arno Wagner 0 siblings, 0 replies; 55+ messages in thread From: Arno Wagner @ 2010-07-26 21:35 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 13:52 ` Milan Broz 2010-07-25 22:37 ` Christoph Anton Mitterer @ 2010-07-25 22:52 ` Christoph Anton Mitterer 2010-07-26 9:42 ` Mario 'BitKoenig' Holbe 1 sibling, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-25 22:52 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 22:52 ` Christoph Anton Mitterer @ 2010-07-26 9:42 ` Mario 'BitKoenig' Holbe 2010-07-26 18:09 ` Arno Wagner 0 siblings, 1 reply; 55+ messages in thread From: Mario 'BitKoenig' Holbe @ 2010-07-26 9:42 UTC (permalink / raw) To: dm-crypt 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." ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 9:42 ` Mario 'BitKoenig' Holbe @ 2010-07-26 18:09 ` Arno Wagner 2010-07-27 18:16 ` [dm-crypt] Including the FAQ in the tarball? Christoph Anton Mitterer 0 siblings, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-07-26 18:09 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dm-crypt] Including the FAQ in the tarball? 2010-07-26 18:09 ` Arno Wagner @ 2010-07-27 18:16 ` Christoph Anton Mitterer 2010-07-27 18:23 ` Arno Wagner 2010-07-29 8:17 ` Heinz Diehl 0 siblings, 2 replies; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-27 18:16 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Including the FAQ in the tarball? 2010-07-27 18:16 ` [dm-crypt] Including the FAQ in the tarball? Christoph Anton Mitterer @ 2010-07-27 18:23 ` Arno Wagner 2010-07-29 8:17 ` Heinz Diehl 1 sibling, 0 replies; 55+ messages in thread From: Arno Wagner @ 2010-07-27 18:23 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Including the FAQ in the tarball? 2010-07-27 18:16 ` [dm-crypt] Including the FAQ in the tarball? Christoph Anton Mitterer 2010-07-27 18:23 ` Arno Wagner @ 2010-07-29 8:17 ` Heinz Diehl 1 sibling, 0 replies; 55+ messages in thread From: Heinz Diehl @ 2010-07-29 8:17 UTC (permalink / raw) To: dm-crypt 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 13:14 ` Christoph Anton Mitterer 2010-07-25 13:52 ` Milan Broz @ 2010-07-25 15:32 ` Arno Wagner 2010-07-25 22:48 ` Christoph Anton Mitterer 1 sibling, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-07-25 15:32 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 15:32 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner @ 2010-07-25 22:48 ` Christoph Anton Mitterer 2010-07-25 23:42 ` Milan Broz 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-25 22:48 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 22:48 ` Christoph Anton Mitterer @ 2010-07-25 23:42 ` Milan Broz 2010-07-26 18:35 ` Christoph Anton Mitterer 0 siblings, 1 reply; 55+ messages in thread From: Milan Broz @ 2010-07-25 23:42 UTC (permalink / raw) To: Christoph Anton Mitterer; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 23:42 ` Milan Broz @ 2010-07-26 18:35 ` Christoph Anton Mitterer 0 siblings, 0 replies; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-26 18:35 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 12:25 ` Milan Broz 2010-07-25 13:14 ` Christoph Anton Mitterer @ 2010-07-25 15:28 ` Arno Wagner 2010-07-25 18:11 ` Milan Broz 1 sibling, 1 reply; 55+ messages in thread From: Arno Wagner @ 2010-07-25 15:28 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 15:28 ` Arno Wagner @ 2010-07-25 18:11 ` Milan Broz 0 siblings, 0 replies; 55+ messages in thread From: Milan Broz @ 2010-07-25 18:11 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-25 10:34 ` Arno Wagner 2010-07-25 11:18 ` Christoph Anton Mitterer 2010-07-25 12:25 ` Milan Broz @ 2010-07-26 9:04 ` Mario 'BitKoenig' Holbe 2010-07-27 18:21 ` Christoph Anton Mitterer 2 siblings, 1 reply; 55+ messages in thread From: Mario 'BitKoenig' Holbe @ 2010-07-26 9:04 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-26 9:04 ` Mario 'BitKoenig' Holbe @ 2010-07-27 18:21 ` Christoph Anton Mitterer 2010-07-27 21:02 ` Mario 'BitKoenig' Holbe 0 siblings, 1 reply; 55+ messages in thread From: Christoph Anton Mitterer @ 2010-07-27 18:21 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-27 18:21 ` Christoph Anton Mitterer @ 2010-07-27 21:02 ` Mario 'BitKoenig' Holbe 0 siblings, 0 replies; 55+ messages in thread From: Mario 'BitKoenig' Holbe @ 2010-07-27 21:02 UTC (permalink / raw) To: dm-crypt 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-22 14:57 [dm-crypt] Efficacy of xts over 1TB David Santamaría Rogado 2010-07-25 10:34 ` Arno Wagner @ 2010-07-26 9:17 ` Mario 'BitKoenig' Holbe 2010-07-27 18:42 ` David Santamaría Rogado 2 siblings, 0 replies; 55+ messages in thread From: Mario 'BitKoenig' Holbe @ 2010-07-26 9:17 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dm-crypt] Efficacy of xts over 1TB 2010-07-22 14:57 [dm-crypt] Efficacy of xts over 1TB David Santamaría Rogado 2010-07-25 10:34 ` Arno Wagner 2010-07-26 9:17 ` Mario 'BitKoenig' Holbe @ 2010-07-27 18:42 ` David Santamaría Rogado 2 siblings, 0 replies; 55+ messages in thread From: David Santamaría Rogado @ 2010-07-27 18:42 UTC (permalink / raw) To: dm-crypt 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. ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2010-08-25 9:36 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-07-22 14:57 [dm-crypt] Efficacy of xts over 1TB David Santamaría Rogado 2010-07-25 10:34 ` Arno Wagner 2010-07-25 11:18 ` Christoph Anton Mitterer 2010-07-25 12:29 ` Heinz Diehl 2010-07-25 12:25 ` Milan Broz 2010-07-25 13:14 ` Christoph Anton Mitterer 2010-07-25 13:52 ` Milan Broz 2010-07-25 22:37 ` Christoph Anton Mitterer 2010-07-26 0:14 ` Milan Broz 2010-07-26 20:38 ` Christoph Anton Mitterer 2010-07-27 8:46 ` [dm-crypt] Using plain64/plain IV (initialisation vector) in dm-crypt Milan Broz 2010-07-27 10:47 ` Arno Wagner 2010-07-27 14:17 ` Christoph Anton Mitterer 2010-07-27 16:08 ` Arno Wagner 2010-07-27 14:15 ` Christoph Anton Mitterer 2010-07-27 15:45 ` Mario 'BitKoenig' Holbe 2010-07-27 15:55 ` Milan Broz 2010-07-27 18:59 ` Christoph Anton Mitterer 2010-07-27 19:37 ` Arno Wagner 2010-07-27 18:58 ` Christoph Anton Mitterer 2010-07-27 19:35 ` Mario 'BitKoenig' Holbe 2010-07-28 8:42 ` Milan Broz 2010-08-20 21:11 ` [dm-crypt] XTS cipher mode limitations Christoph Anton Mitterer 2010-08-21 0:22 ` Arno Wagner 2010-08-22 12:50 ` [dm-crypt] XTS cipher mode limitations (FAQ additions) Christoph Anton Mitterer 2010-08-23 0:46 ` Arno Wagner 2010-08-25 9:36 ` Christoph Anton Mitterer 2010-08-22 12:56 ` [dm-crypt] tool to account the written number of bytes to a block device (was: XTS cipher mode limitations) Christoph Anton Mitterer 2010-08-22 16:01 ` Arno Wagner 2010-08-22 21:57 ` Christoph Anton Mitterer 2010-08-23 7:14 ` [dm-crypt] tool to account the written number of bytes to a block device Milan Broz 2010-08-25 9:27 ` Christoph Anton Mitterer 2010-08-24 16:19 ` [dm-crypt] XTS cipher mode limitations Ramius 2010-07-26 8:53 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner 2010-07-26 20:47 ` Christoph Anton Mitterer 2010-07-26 21:01 ` Arno Wagner 2010-07-26 21:28 ` Christoph Anton Mitterer 2010-07-26 21:35 ` Arno Wagner 2010-07-25 22:52 ` Christoph Anton Mitterer 2010-07-26 9:42 ` Mario 'BitKoenig' Holbe 2010-07-26 18:09 ` Arno Wagner 2010-07-27 18:16 ` [dm-crypt] Including the FAQ in the tarball? Christoph Anton Mitterer 2010-07-27 18:23 ` Arno Wagner 2010-07-29 8:17 ` Heinz Diehl 2010-07-25 15:32 ` [dm-crypt] Efficacy of xts over 1TB Arno Wagner 2010-07-25 22:48 ` Christoph Anton Mitterer 2010-07-25 23:42 ` Milan Broz 2010-07-26 18:35 ` Christoph Anton Mitterer 2010-07-25 15:28 ` Arno Wagner 2010-07-25 18:11 ` Milan Broz 2010-07-26 9:04 ` Mario 'BitKoenig' Holbe 2010-07-27 18:21 ` Christoph Anton Mitterer 2010-07-27 21:02 ` Mario 'BitKoenig' Holbe 2010-07-26 9:17 ` Mario 'BitKoenig' Holbe 2010-07-27 18:42 ` David Santamaría Rogado
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.