Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux