Re: p1619 (disk): ciphertext-stealing, tweak-mapping, other

[Michael Torla]

David McGrew wrote: Hi Michael, thanks for your comments, more inline: On Dec 21, 2005, at 2:09 PM, Michael Torla wrote: David McGrew wrote: You mean advantage in terms of latency, right?  I'm not sure that   this is the case, since both XCB and EME* need to do one pass  over  the data before any data can be output, and I suspect that  the  circuit depth of those two passes isn't much different.  It  would be  interesting to see a detailed comparison.  For that  matter, it would  be worthwhile to discuss the implementation  scenarios enough to get a  good idea of what the "success  criteria" for wide-block modes like  these are.  (E.g. since all  of these modes require the data to be  buffered, what critical  path should be measured?  The path to output  the first byte, or  to output all of the bytes?) I've looked at this to some extent. >From the point of view of an arbitrary block size, XCB is much more  costly.  To support a block that is larger than the AES hardware  accelerator's buffer size, data must be fetched twice.  This  feature is unique to XCB; I've not seen it in any other mode of any  crypto algorithm I've looked at. AFAICT, the requirement that the encryptor buffer the block that it  is encrypting is a fundamental requirement for any cipher that is a  pseudorandom permutation with an input width that matches the  plaintext size.  Any mode that met the goal would the need to buffer  the data. EME and EME* and several other modes also have this property, IIUC.    In the EME specifications, the dependancy of the second ECB pass on  the results of the first ECB pass is somewhat hidden because it is  expressed indirectly through variables.  Note, for example, on page 4  of http://seclab.cs.ucdavis.edu/papers/eme.pdf that the variable M,  which is needed to compute the second ECB pass, is only computed  after the first ECB pass completes. you are right that EME has that property.  I have not read up on EME* yet. However, EME, as described for tweakable "wide block" encryption, restricts the data size to 4096 bits.  That may not be the intent of the original EME algorithm, but that's how I the document I saw reads. XCB supports any amount of data.  That, to me, is the difference. Now that I've found a description of ABL, I'll have to study that one as well. mt