[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fast re-keying



Ref:  Your note of Mon, 3 Apr 1995 18:24:00 -0700 (attached)


Phil,

 > In effect, I am using randomly-chosen SAIDs as nonces.  Random SAIDs
 > are a good idea for other reasons. For one, they make it harder for an
 > "off path" attacker to guess what SAIDs might be valid at a particular
 > destination.

I disagree with your approach here.
Especially disguising SPI's as nonces (or nonces as SPI's?)

This WG decided that SPI's are free for the implementation to choose.
If in your implementation you find useful to choose them random, fine with
me. But do not impose that on me (e.g., I may choose to have 16 bits
that are a fast index to a table and only 16 bits to prevent collisions of
the type you mention).

As for using the SPI's as nonces, in addition to putting the randomness
constraint on them, there at least two other problems.
1) They are shorter than usually recommended for nonces (64 bits the typical
recommended length). 32 bits create collisions after 2^16 uses.
In most cases you won't get to that, but still 65500 is not such a huge
number.
2) (more important for me) One should avoid (if possible) the use of an
element defined in one way for a completely different goal. Especially, if
the later has essential implications for security. This unnatural and hidden
binding is likely to create problems.

Now, if you have something great to gain from this binding then it is worth
considering it. There is nothing here. Clearly not space where you're willing
to spend 1000 bits where 64 will do. I do not see what other reason.
Simplicity is not the case, this binding projects simplicity to the surface
but actually complicates by creating unnecessary dependencies between the
SPIs and nonce functions.

Notice that my suggestion to use the field of DH public parts as nonces
(but only with 64 bits instead of 1024) is not the kind of hidden binding
mentioned above. Indeed, the DH-parts are already used in your design as
nonces for the freshness of signatures (I do the same in my Photuris variant).
(And even here things may be dangerous if two parties repeat their public
parts).

As for the issue of space, OK so you do not care much about it.
One thing is to try to optimize each bit, another is to
waste unnecessarily (that's the way I see the repeated sending of g^x,etc)

On the need for cookies during fast re-key:

 > Every Photuris function that involves a modular exponentiation (i.e.,
 > most of them) requires a cookie to guard against off-path swamping attacks.

I agree, but fast re-keying does *not* involve exponentiation.

 > To summarize my design philosophy for Photuris: a small and general
 > purpose message set is more interesting to me than one that is overly
 > optimized with lots of ad-hoc messages to save bits on the wire,

I agree here, too. That's the way I see the "Photuris variant" I propose.
Adding important functionality to Photuris without paying with additional
protocols or fancy messages.

 > What effort I can expend on optimization I'd rather invest in speeding up
 > the modular exponentation and symmetric encryption functions and in
 > implementing per-packet data compression.

That's fine but orthogonal to all the issues discussed here (except if you
talk about how to invest your own time).

 > I can explain all this in more detail after I arrive in Danvers
 > tomorrow night.

I'll be glad to do that (on Wed or Thu).

Hugo