Wow, there has been a lot of response. Thanks! This is what I wrote so far. Let me post it and I try to reply to the other messages. ===================================================================================== > I am aware of that issue. However, XTS mode should lead to a full sector > (512 Bytes) chage even if only one bit is changed. That is the whole > point of modes like XTS, EME, etc. XTS-AES-128 (key size is 256 bit then) is by design a narrow-block en-/decryption mode, i.e. a (thank god) *parallelizable* en-/decryption of consecutive 128 bit = 16 bytes sized blocks of data inside the 512 bytes sector. This makes 32 parallel en-/decryptions and flipping the 2345th bit in that sector will change the 19th block out of those 32 and nothing more (remember that the IV is constant for that sector; a fresh random IV instead would trigger a sector-wide change but leads to data expansion). This is simply ECB mode without mixing (as e.g. in EME - standardized but patented) or universal hashing (as e.g. in TET, HEHfp). Nevertheless, XTS is a damn fine mode of operation :-) > I think you just have to live with it at this time. It is not a severe > vulnerability in most situations. And it will not build up to badly, at > some time the blocks get re-used. The amounth of spares/write pool > in SSDs seems to be shrinking as well. That is true, I agree to such a pragmatic approach. But again: in XTS operation mode a single bit changes only 16 bytes of data and not the whole sector. It is definitely *not* a pseudo-random permutation on the sector as e.g. EME, XCB, TET or HEHfp. Anyway, I do think that there are other attack vector > > 1) Use random IVs. Leaves you with data expansion, since you have to store > > the IVs, and a pain in the *** effort to implement this reliably. > > It is. It also breaks the dm-model as additional accesses > are required. Not an option, I think. Absolutely. > > 2) Add a (claimed patent free) wide-block mode like TET or HEHfp (see > > articles below) from the Hash-Encrypt-Hash family to the Crypto-API and > > change the dmcrypt crypto engine to handle variable block sizes instead of > > always operating on 512 Bytes of data (compare the discussion: > > http://www.saout.de/pipermail/dm-crypt/2011-April/001667.html) > > I will have a look at the articles, but I think this is not > really an option either, agen because of mismatch with the > dm-layer. I would really like to understand this mismatch better. Is there any documentation that I could read except the source code itself? I am not a kernel space developer and would like to understand why (and what kind of) incompatibility issues arise when you think about a variable size of data processing via the dm-crypt crypto engine. I thought the file system block size is the smallest entity that is written and read in the system anyway. Why split this into 512 Byte chunks of data and not process the data that is carried through the crypto engine as a whole? > > Another (great) advantage of those wide-block modes is their inherent > > 1/2*MAC functionality due to the intended collision avoidance in the > > encryption layer that is built in by the universal hash pre- and > > post-processing („1/2“ for: not a MAC but more than no MAC at all). Here is a very important point concerning the TET or HEHfp mode of operation that I would like to emphasize again. Those operation modes offer the best security performance that one can get out of a length-preserving block device encryption mode. More precise: They each have three layers, a bijection, a parallelizable ECB encryption mode, and another bijection. The bijections have good cryptographic properties and depend on the secret key. They prevent collisions in the middle ECB layer. That is, controlled changes to the cipher text produce a possibly freaky plain text and hence are detectable. This is what I called „1/2*MAC“. If you want to have more security you would have to use a MAC on your plain/cipher text to make sure that you read what you have written before. > > Since you maintain the code I would like to know your opinion on this and > > if there is a chance to pursue such a project. > > That would be Milan. I am just the volunteer that does the documentation. > Milan actually gets paid for real work on cryotsetup. Thanks for clarifying those things to me. What about the following approach? Leave the dm-crypt crypto engine as it is – processing 512 bytes – and add e.g. TET or HEHfp to the Crypto-API and (as an option) to dm-crypt. This would add a pseudo-random operation on 512 Bytes of data to the system that is not present at the moment. Stavros _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
