While computations on averages can prove that a design will not work,
they obviously cannot prove that it will. I submit that the more
interesting data is how long trains of minimum-size packets are, and
how far behind an actual crypto engine can get before it runs out of buffers.
But in a certa
I should have added one further point to my note.
In one respect, my figures do support your position. The upstream traffic,
which was required a larger cache, was also a significantly slower stream,
both in packets and in bytes. That provides a lot more headroom for key
setup. And while th
In message <[EMAIL PROTECTED]>, Ron Rivest writes:
>
>Steve --
>
>Don't your statistics support the argument that key agility is
>*not* likely to be terribly important by itself?
>
>With a cache capable of storing only 5 key setups, you get at least a
>75% hit rate, by your statistics.
>
>This e
Steve --
Don't your statistics support the argument that key agility is
*not* likely to be terribly important by itself?
With a cache capable of storing only 5 key setups, you get at least a
75% hit rate, by your statistics.
This effectively reduces key setup time by a factor of *four*, maki
(Following earlier posting by Steve Bellovin and myself on the same subject.)
Steve --
I don't quite understand your argument yet, although it is certainly
good to have some data to look at!
We can have a simple model for encryption time wherein
c + d n
to encrypt a packet of n bytes
