RE: [Cfrg] new authenticated encryption draft

David, I have heard this argument as well for years. I guess I understand it in the abstract, but I still don't fully get how/where it would really work or be needed. Do we currently have a "segmented" seqNum version of ESP? If not, I don't understand how you can make the sequence numbers work across "uncoordinated" crypto modules. That is, anti-replay will cause problems it seems to me, both on transmit and receive, if there is no coordination. If there is a coordination, why can't the IV space just be divided among them (e.g., for N modules, use log2(N) bits in the IV to distinguish among the modules). Seems like that one-time setup would be very easy to do in a multi-module system, and it avoids the need for random IVs to avoid collisions, since each module can then just use a counter.

So I guess that, like Dan, I'm asking for a little better explanation of how a system requiring random IVs might actually be structured. If I can't picture at least one realistic scenario, I have a hard time seeing the need for it in a standard. Hopefully somebody can turn on the light bulb for me.

Doug Whiting

________________________________

From: David McGrew [mailto:mcgrew@cisco.com]
Sent: Thu 9/14/2006 5:01 PM
To: D. J. Bernstein
Cc: cfrg@ietf.org
Subject: Re: [Cfrg] new authenticated encryption draft

Hi Dan,

On Sep 14, 2006, at 6:58 AM, D. J. Bernstein wrote:

> David McGrew writes:
>> When a single key is used by multiple encryptors, a unique IV needs
>> to have a distinct IV contribution for each encryptor.  In some
>> cases, it may not be convenient for the encryptors to coordinate
>> among themselves to agree on the values of the IV contribution.
>
> Specific references, please. What are those cases?

from my earlier mail: "For example, consider the case in which there 
is a cluster of devices that share an encryption key in order to 
provide a load balancing or failover capability."  For that matter, 
any protocol which uses a long-term shared secret key, and which is 
not explicitly designed to support a distributed implementation, but 
which ends up being implemented in a distributed manner anyway.

> Why can't the key
> generator hand out a counter along with the key?

You're assuming that there is a central entity distributing the key; 
why should we enforce that limitation on our systems?  Distributed 
systems are non-trivial, and forcing the use of unique IVs on them 
would create a need for coordination that could otherwise be 
avoided.  If a central authority coordinates all of the counters, 
this would force a single point of failure on the system.  If the 
counters are managed in a distributed manner (e.g. a VRRP like 
election), there is a chance of failure due to a network partition 
that bifurcates a cluster.

> Who exactly is sharing
> a single secret key among a large number of parties without having a
> list of the parties? What's the name of the software or hardware? How
> exactly does the promiscuous key sharing work? Is it secure? If it 
> isn't
> actually secure, why should we even consider screwing up our APIs to
> support it?

Allowing random IVs is screwing up our APIs?

Your final question neglects the first rationale that I gave for 
random IVs: with deterministic IVs, a provision must be made in order 
to ensure that the IV maintains its uniqueness across reboots, and it 
is not always convenient or desirable to do so.  That reason alone is 
sufficient.

David

>
> ---D. J. Bernstein, Professor, Mathematics, Statistics,
> and Computer Science, University of Illinois at Chicago
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg