> -----Original Message-----
> From: Milan Broz <gmazyland@xxxxxxxxx>
> Sent: Sunday, August 11, 2019 1:13 PM
> To: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>; Pascal Van Leeuwen
> <pvanleeuwen@xxxxxxxxxxxxxx>
> Cc: Horia Geanta <horia.geanta@xxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; dm-
> devel@xxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx
> Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support
>
> On 10/08/2019 06:39, Ard Biesheuvel wrote:
> > Truncated IVs are a huge issue, since we already expose the correct
> > API via AF_ALG (without any restrictions on how many of the IV bits
> > are populated), and apparently, if your AF_ALG request for xts(aes)
> > happens to be fulfilled by the CAAM driver and your implementation
> > uses more than 64 bits for the IV, the top bits get truncated silently
> > and your data might get eaten.
>
> Actually, I think we have already serious problem with in in kernel (no AF_ALG needed).
>
> I do not have the hardware, but please could you check that dm-crypt big-endian IV
> (plain64be) produces the same output on CAAM?
>
> It is 64bit IV, but big-endian and we use size of cipher block (16bytes) here,
> so the first 8 bytes are zero in this case.
>
> I would expect data corruption in comparison to generic implementation,
> if it supports only the first 64bit...
>
> Try this:
>
> # create small null device of 8 sectors, we use zeroes as fixed ciphertext
> dmsetup create zero --table "0 8 zero"
>
> # create crypt device on top of it (with some key), using plain64be IV
> dmsetup create crypt --table "0 8 crypt aes-xts-plain64be
> e8cfa3dbfe373b536be43c5637387786c01be00ba5f730aacb039e86f3eb72f3 0 /dev/mapper/zero 0"
>
> # and compare it with and without your driver, this is what I get here:
> # sha256sum /dev/mapper/crypt
> 532f71198d0d84d823b8e410738c6f43bc3e149d844dd6d37fa5b36d150501e1 /dev/mapper/crypt
> # dmsetup remove crypt
>
> You can try little-endian version (plain64), this should always work even with CAAM
> dmsetup create crypt --table "0 8 crypt aes-xts-plain64
> e8cfa3dbfe373b536be43c5637387786c01be00ba5f730aacb039e86f3eb72f3 0 /dev/mapper/zero 0"
>
> # sha256sum /dev/mapper/crypt
> f17abd27dedee4e539758eabdb6c15fa619464b509cf55f16433e6a25da42857 /dev/mapper/crypt
> # dmsetup remove crypt
>
> # dmsetup remove zero
>
>
> If you get different plaintext in the first case, your driver is actually creating
> data corruption in this configuration and it should be fixed!
> (Only the first sector must be the same, because it has IV == 0.)
>
It will very likely fail with that CAAM h/w, but that only proves that you
should not use plain64be IV's together with CAAM h/w. Which should be
entirely avoidable in real life unless you have some unlikely requirement
to move physical encrypted diks from one system (without CAAM h/w and needing
these plain64be IV's for some reason) to another system (with CAAM h/w) and be
able to decrypt them there.
Formally, these plain64be IV's are actually WRONG, since the XTS specification is
very clear on the byte order of the sector number ("little endian byte array").
> Milan
>
> p.s.
> If you ask why we have this IV, it was added per request to allow map some chipset-based
> encrypted drives directly. I guess it is used for some data forensic things.
>
Sounds like someone got the endianness wrong ;-)
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
