[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: analysis thus far
Steve,
Thanks for providing the table. It looks like a useful
way of comparing the various options.
I have on or two suggestions to add to the table.
On the column side, there should be two extra columns showing
the additional overhead of the solution, both in terms of packet
and CPU overhead.
On the row side (the counter-measures), I would like
to add another option, which for lack of a better word I'll
call "sequenced packet re-key". Essentially, the ESP packet
contains a sliding sequence #, in addition to the information it
currently contains. Each packet is encrypted in a key (call it Kp)
derived from the current session key (call it Ks) and the
sequence # ("n") as follows.
Kp = h(Ks, n), where h is a pseudo-random function (e.g. MD5)
This means that each packet is encrypted in a unique key, and
it is also sequenced. The only packet space overhead that this
entails is that of the sequence # (say 32 bits). Also, this
naturally sequences the packets. The additional CPU overhead
that this entails is that of computing the hash function over
(Ks + n).
By proper padding to MD5 block size, the hash of Ks can be
pre-computed. This means that at run time, only a hash over
the sequence # needs to be computed. By contrast, for integrity
with sequencing, one needs to compute a hash over the entire
packet plus sequence number, as well as carry the MAC and the
sequence # in every packet.
The sequenced packet re-key option does as well as the "integrity +
sequence #" option in terms of defending against both the CBC cut-and-paste
and replay attacks, at less cost in packet space, and far less
computational cost. (The usual caveat of key-setup times applies).
Of course, if the service needs AH functionality, then the
integrity plus sequence # is the natural answer.
Just something else to consider.
Regards,
Ashar.