search

vincenthz / hs-crypto-cipher

DEPRECATED by cryptonite; A collection of cryptographic block and stream ciphers in haskell
22 stars 14 forks source link

strange XTS encryption #39

Closed stbuehler closed 1 year ago

stbuehler commented 11 years ago

Hi,

the XTS encryption mode seems strange. The "official" doc (http://axelkenzo.ru/downloads/1619-2007-NIST-Submission.pdf) doesn't have an IV; instead it uses the sPoint as IV, and encrypts it once and uses it as tweak. The GF multiplication is only done within a sector; so you have to "restart" at each sector boundary (it could break anyway, as sector boundaries might not be aligned to the block size).

In any case iniTweak = iterate xtsGFMul encTweak !! fromIntegral sPoint looks like a very bad idea. Exponentiation can be done a lot faster.

Please clarify what the intention behind your XTS mode is. Also please document that xtsGFMul is doing a multiplication with the X^1 polynom in the GF_128 field with X^128+X^7+X^2+X^1+X^0 as irreducible polynom :)

Given that this mode only works with 128-bit block ciphers you might want to split it into a separate class.

vincenthz commented 11 years ago

yes, exponantiation can be done faster, just like in the C file too. it wasn't meant at a permanent piece of code, but just a getting-started bits.

For the 128 bit only thing, yes I realized the problem when my test suite automatically tried to XTS with DES, next major version will have the function as a maybe. At the moment you'ld have to know not to use XTS with a non 128 bits block size cipher. Just like AEAD shouldn't be use with some ciphers.

You're right about the lack of documentation, some stuff could be more documented. i do accept pull requests. hints :-)

The IV and the spoint is the same thing here (maybe it would have some value to create its own types instead of reusing the IV type), however it's valuable to have it altogether; There's nothing that says that sector need to mean the sector on disk, nor what their size is. I could have a scheme where my block size is 2mb and it would make sense to have the spoint to do small update at the end of a sector.

stbuehler commented 11 years ago

Ok, so you're expecting the "sector offset" in other implementations as IV, and sPoint is an additional block offset in that sector to jump to?

Without the sector jump the xtsGFMul implementation is not that critical (apart from being endian broken), as it would get applied only once per block - with the sector jump it gets crazy :)

To fix the endianess you could perhaps use getWord64be or getWord64le from Data.Serialize.Get (and the Putter).