On 2/13/07, Michael Buesch <mb@xxxxxxxxx> wrote:
On Tuesday 13 February 2007 00:54, Tomas Winkler wrote: > On 2/13/07, Michael Buesch <mb@xxxxxxxxx> wrote: > > On Tuesday 13 February 2007 00:15, Tomas Winkler wrote: > > > I fetching this from my "dusty" memory so I hope I'm right about it. > > > TKIP phase1 one can be precomputed in advance. There's no runtime > > > > Phase1 key changes on iv32 wrap. > > That's correct, this depends on packet sequence counter, but you can > compute next TKIP phase1 even before iv32 wrap has occurred. You can > compute 100 of them in advance. Actually it should be "iv32 changes" instead of "iv32 wraps". Typo. But my point still remains. I see no point in precomputing it. > > > dependency after key exchange. > > > Cached keys can be provided by supplicant. Usually u want to keep 2 or > > > 3 cached TKIP phase1 for smooth decryption. As in QoS sequence > > > > Hardware (bcm43xx at least) can only have one key at a time. > > There's no point in caching, as phase1 key calculation is cheap > > and can be done on-the-run. The expensive part it uploading it to HW. > > True, but when there is a packet from past with tkip phase1 that > doesn't match currently configured phase1 tkip you might be able to > decrypt it, of course f hardware doesn't scramble it with wrong key. HW doesn't scramble it. So when d80211 receives the packet it can _then_ generate the key. There's no point in precomputing it.
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.
> > > counters are kept per AC, you might get into gentle state of receiving > > > packets for the old key. If you hold more then one phase1 you might > > > be able decrypt the packets that doesn't match current phase1 in > > > software. > > > > You can generate the new key then. There is no point in wasting memory > > by precomputation of the keys. > > These few bytes doesn't hurt you even if you're running on a cell phone. But they don't gain you anything too, IMO. So better not waste the memory and not have the extra complexity in code.
I didn't measured performance but I thought it can be precomputed by the supplicant rather then by kernel code. I might be wrong.
-- Greetings Michael.
- 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
