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

Counter Mode: Proposed Way Forward



I want to thank David McGrew for his detailed analysis.  I wish that David
had been able to generate his document sooner, but now that we have the
information, we can plot a way forward.

David has proposed the use of additional secret random material to salt the
counter block.  Further discussions have shown that this is not needed.
Rather, unpredictability is the only property that is needed.  If the value
cannot be know in advance, then the attacker cannot start the computation of
the very huge table until the value is learned.  If the value is
predictable, then the attacker can mount the attack using the likely value.
This is the situation in the current draft.  Since many implementations use
the SPI as an index into a table of security associations, the truncated SPI
value is too predictable.

I propose the replacement of the truncated SPI with the 24 most significant
bits form the IKE nonces.  I propose that the initiator use 24 bits from its
own nonce, and the responder use 24 bits from its own nonce.  In this way,
we can accommodate any future key establishment techniques that might use
the same key in both directions,  Even with the same key, the initiator and
responder will have different counter block values, and thus different key
streams.

Based on the analysis of storage system technology posted by David Black,
the additional 24 unpredictable bits in the counter block should thwart the
precomputation attack for several decades, even if the attacker were able to
discover the values that would be used a long time prior to their use,  Use
of the IKE nonces makes this impossible (assuming reasonable random number
generation capabilities), thus completely thwarting the attack.

Unless I hear an uproar on the list, I will update the draft to reflect this
way forward.

Russ