On Wed, Aug 07, 2019 at 04:14:22PM +0000, Pascal Van Leeuwen wrote: > > > > In your case, we are not dealing with known plaintext attacks, > > > > > > > Since this is XTS, which is used for disk encryption, I would argue > > > we do! For the tweak encryption, the sector number is known plaintext, > > > same as for EBOIV. Also, you may be able to control data being written > > > to the disk encrypted, either directly or indirectly. > > > OK, part of the data into the CTS encryption will be previous ciphertext, > > > but that may be just 1 byte with the rest being the known plaintext. > > > > > > > The tweak encryption uses a dedicated key, so leaking it does not have > > the same impact as it does in the EBOIV case. > > > Well ... yes and no. The spec defines them as seperately controllable - > deviating from the original XEX definition - but in most practicle use cases > I've seen, the same key is used for both, as having 2 keys just increases > key storage requirements and does not actually improve effective security > (of the algorithm itself, implementation peculiarities like this one aside > :-), as XEX has been proven secure using a single key. And the security > proof for XTS actually builds on that while using 2 keys deviates from it. > This is a common misconception. Actually, XTS needs 2 distinct keys to be a CCA-secure tweakable block cipher, due to another subtle difference from XEX: XEX (by which I really mean "XEX[E,2]") builds the sequence of masks starting with x^1, while XTS starts with x^0. If only 1 key is used, the inclusion of the 0th power in XTS allows the attack described in Section 6 of the XEX paper (https://web.cs.ucdavis.edu/~rogaway/papers/offsets.pdf). Of course, it's debatable what this means *in practice* to the usual XTS use cases like disk encryption, for which CCA security may not be critical... But technically, single-key XTS isn't secure under as strong an attack model as XEX. - Eric -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
