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 - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
