[Cfrg] two-pass modes of operation

Agreed.  There is a question that always struck me as important, but  
one which I've never heard discussed: how do SIV and similar modes  
compare with Encryption with Associated Data (EAD) modes, like those  
defined in IEEE 1619.2 (EME2-AES and XCB-AES)?   These modes are the  
state of the art in "wide block encryption" as used for disk block  
encryption and suchlike; they are tweakable pseudorandom permutations  
with arbitrary-length inputs.

Both EAD modes require two serialized passes over the plaintext for  
both the sender and the recipient, in contrast to SIV, which  
inconveniences the sender more than the recipient; the EAD modes  
inconvenience the recipient as well.  So, if the sender can afford two  
passes, perhaps it would be reasonable to expect the receiver to  
perform two passes as well?

The IEEE EAD modes are not directly comparable to SIV, since the  
latter provides authentication.  But authentication could be added via  
a post-decryption redundancy check, as done in RFC 5649, so it is  
reasonable to compare them.

I believe that SIV and the EAD modes have roughly comparable  
computational cost.  Both EAD modes require two passes over the  
plaintext, but can perform all of the needed computations using  
paralellism, or a full pipeline.  This is in contrast to SIV, which  
uses CBC-MAC as an internal component and thus can't utilize  
paralellism or pipelining.

To my mind, the interesting questions here are:

1.  Where would misuse resistant crypto be valuable?

2.  Where can we tolerate the performance hit of two serialized passes  
over the plaintext?   How much advantage is it to have the receiver do  
one pass while the sender does two?

3.  How does performance compare between the EAD modes and SIV,  
especially in the scenarios identified in #1?

David

Full disclosure: my employer holds IPR on XCB.  Sorry, I know that IPR  
is cholesterol in the bloodstream of standards.

On Jul 20, 2011, at 9:57 AM, Jim Schaad wrote:

> That is completely correct.  SIV requires two passes for the sender  
> - but
> only one pass for the recipient.
>
>> -----Original Message-----
>> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On  
>> Behalf Of
>> Peter Gutmann
>> Sent: Wednesday, July 20, 2011 12:50 AM
>> To: dharkins@lounge.org; pgut001@cs.auckland.ac.nz
>> Cc: mcgrew@cisco.com; cfrg@irtf.org
>> Subject: Re: [Cfrg] request for comments on "Generation of  
>> Deterministic
>> Initialization Vectors (IVs) and Nonces"
>>
>> "Dan Harkins" <dharkins@lounge.org> writes:
>>
>>> Let me remind everyone of SIV mode*. It's a CTR mode derivative  
>>> but is
>>> resistant to nonce misuse. Unlike CBC, the nonce doesn't need to be
>>> unguessable. And it even provides a strong assurance of security  
>>> if the
>>> nonce is reused.
>>
>> Doesn't SIV require the entire message to be buffered, which makes it
>> unusable in streaming implementations?
>>
>> [Checks]
>>
>> Unless I've misinterpreted some part of Fig.3 and Fig.8 of RFC  
>> 5297, this
> can't
>> be used in a streaming implementation because the CMAC operation to
>> create the IV has to make a complete pass over the message before  
>> you can
>> start encrypting (this is also similar to a key-wrap mechanism that  
>> Colin
> Plumb
>> and I came up with for RFC 3211, although it'd need a tweak to use a
> proper
>> MAC for full integrity-protection, it was designed for non- 
>> expanding 512-
>> byte disk sector encryption and dates from the early 1990s, so it  
>> predates
>> pretty much all of the work that newer modes and mechanisms are  
>> built on).
>> SIV is quite nice for something like 802.11, SRTP, DTLS, and  
>> others, but
>> unfortunately won't work as a general-purpose mechanism.
>>
>> Are there any IP issues around SIV?
>>
>> Peter.
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>