On Fri, 2019-03-15 at 17:30 +0100, Niels Möller wrote: > Simo Sorce <[email protected]> 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?
I will. > 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. Good idea. > > > 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. I can make a new function and attempt to make these improvements there, then it can either be shared or copied back to cmac at a later time. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
