Jouni Malinen <[EMAIL PROTECTED]> wrote:
>
> However, at least for some time, there are two different TKIP
> implementations (net/ieee80211 and net/d80211) so this would mean
> duplicating Michael MIC implementation and I would rather not do that.
Good point, let's keep it for now.
Cheers,
--
Vi
On Thu, Jul 20, 2006 at 01:39:05AM +1000, Herbert Xu wrote:
> Michael Wu <[EMAIL PROTECTED]> wrote:
> > Simplicity and consistency. Whereas the relatively simple mic part of the
> > TKIP
> > algorithm is in crypto API, the (more important, more complicated) key
> > mixing
> > part is not in cry
Michael Wu <[EMAIL PROTECTED]> wrote:
>
> Simplicity and consistency. Whereas the relatively simple mic part of the
> TKIP
> algorithm is in crypto API, the (more important, more complicated) key mixing
> part is not in crypto api. It is unlikely that either the mic or key mixing
> part would b
On Saturday 15 July 2006 03:37, Herbert Xu wrote:
> I suppose the question is that what do you gain by moving it out?
> If all else being equal then it's better to have a standardised
> interface for accessing it.
>
Simplicity and consistency. Whereas the relatively simple mic part of the TKIP
alg
Michael Wu <[EMAIL PROTECTED]> wrote:
>
> Is there really a point to having michael_mic in crypto api? The only users
> are 802.11 stacks. I can imagine arc4 being used for other purposes, but
> michael_mic is very much wireless only. The only advantage of keeping
> michae
On Thursday 13 July 2006 23:50, Michael Wu wrote:
> Is there really a point to having michael_mic in crypto api? The only users
> are 802.11 stacks. I can imagine arc4 being used for other purposes, but
> michael_mic is very much wireless only. The only advantage of keeping
> michael_m
Is there really a point to having michael_mic in crypto api? The only users
are 802.11 stacks. I can imagine arc4 being used for other purposes, but
michael_mic is very much wireless only. The only advantage of keeping
michael_mic in crypto seems to be the testing code.
-Michael Wu
