Re: [Cfrg] new authenticated encryption draft

[David McGrew <[e-mail]>]

Hi Doug,

On Sep 14, 2006, at 7:17 PM, Doug Whiting wrote:

> 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.

I'm not sure that ESP does needs to have random IVs. A better example  
of an application that would benefit from their use of would be an  
one that uses long-term shared secrets, especially a challenge/ 
response protocol.  Perhaps the draft didn't make it clear that it  
was intended for use in this sort of protocol as well.

In a C/R application, in order to use a sequence number as a nonce,  
there will be a need to have those values checkpointed into non- 
volatile memory, and there will be a need for the application to  
coordinate an "IV contribution" among the devices that share the  
secret.  If we require this sort of coordination, it makes it harder  
to distribute the application across multiple nodes.  In particular,  
there are existing applications (like mirrored servers) that don't do  
this sort of coordination because they don't currently need it.  If  
we require additional coordination, we'll give those applications a  
motivation to not use our spec, even if it is theoretically possible  
to provide that coordination.

David

>
> Doug Whiting
>
> From: David McGrew [mailto:[e-mail]]
> Sent: Thu 9/14/2006 5:01 PM
> To: D. J. Bernstein
> Cc: [e-mail]
> 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg
>

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg