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 be used
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 crypto api.
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,
--
Visit
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
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
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_mic in crypto
