Re: d80211: current TKIP hwcrypto implementation seems to be broken

["Jouni Malinen" <jkm@devicescape.com>]

On Tue, Feb 13, 2007 at 02:19:15AM +0200, Tomas Winkler wrote:

> For past packets you've already computed it so why do  it again? So
> you keep 2 phas1 keys one old and one current. When sequence numbers
> advance sufficiently you discard the old one and compute the new one
> in a spare time. Something like double buffer.

Well, you can, but how likely is this case to really happen? If someone
can show this happening frequently, I could consider adding support for
it, but I see not much point in adding the extra complexity without a
clear case where this would be of benefit. P1K is not really that slow
after all and figuring out when the kernel code has "spare time" and all
the extra handling of pre-calculation and storing the values is not
really something I would like to add into d80211 unless this can really
be shown to provide noticeable throughput improvement.

> I didn't measured performance but I thought  it can be precomputed by
> the supplicant rather then by kernel code.    I might be wrong.

P1K is calculated by whoever is using the TKIP TK and in case of all the
implementations that I'm aware of, this is not done in the supplicant.
Sure, it could be done there, but I think the current design of doing
all TKIP encryption/decryption (including phase 1 and 2 key derivation)
in the kernel is better.

-- 
Jouni Malinen                                            PGP id EFC895FA