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.
> 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.
> 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.
-- 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
