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

["Tomas Winkler" <tomasw@gmail.com>]

On 2/13/07, Jouni Malinen <jkm@devicescape.com> wrote:
> 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.

There are real cases when this happens. Try to two different AC for
example  VoIP and have FTP in parallel.  Packets for low priority AC
can be stalled encrypted and scheduled in a AP TX queue while high
priority packets are already sent with the new key.
Maybe the new key can be computed on demand but it's good thing to
preserve the old key for while.


>
> > 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.
>
You might be correct here.
> --
> Jouni Malinen                                            PGP id EFC895FA
>