Simo Sorce <s...@redhat.com> writes: >> But it looks like one has to pass the complete message to one call? > > Yes, due to ciphertext stealing, XTS needs to know what are the last > two blocks, or at the very least needs to withhold the last processed > block in order to be able to change it if a final partial block is > provided. This means inputs and outputs would not be symmetrical and I > felt it would make it somewhat hard to deal with as an API. > In general XTS is used for block storage and the input is always fully > available (and relatively small, either around 512 bytes, or 4k).
I see. Can you mention this (and the fact that messages must be at least one full block) in the manual? Would it make sense to rename functions to xts_encrypt_message, xts_decrypt_message, to emphasize that they operate on complete messages? That would be analogous with the ccm message functions. >> So the second key, with E_k2, is only ever used to encrypt the IV? If >> you add a set_iv function, that could do this encryption and only store >> E_k2(IV). > > What would be the advantage ? With an api for complete messages only, my suggestion makes little sense. > Looks the same indeed, should I share it? Just copy it from cmac? > Something else? Would be nice to share it, but since it's so short, duplication is no big deal. Also re-reading the cmac version, block_mulx, I think it's unfortunate to use READ_UINT64 and WRITE_UINT64, since arguments are aligned. It would be preferable to load 64-bit values and use __builtin_bswap64 when needed and available (see ctr.c for a similar hack). But that's an independent improvement. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
