[lkml]   [2004]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Crypto API and keyed non-HMAC digest algorithms / Michael MIC
On Mon, Mar 08, 2004 at 09:45:39AM -0500, James Morris wrote:

> On Sat, 6 Mar 2004, Jouni Malinen wrote:
> > One straightforward way of adding support for Michael MIC is to add an
> > optional setkey operation for digest algorithms. The included patch
> > (against Linux 2.6.4-rc2) does exactly this and also includes an
> > implementation of Michael MIC. Another option would be to add a new
> > algorithm type for keyed hash algorithms, but that seemed unnecessary
> > for this purpose.

> I think it would be better to do the latter, add another mode for
> simple keyed digest processing (KMAC?), where a function called something
> like kmac_init() takes the tfm/key/kelen paramters. The kmac_update() and
> kmac_final() methods are just wrappers around the digest methods, and we
> also kmac_kmac() similar to the HMAC method.

Hmm.. HMAC can do this easily, since that construction uses plain digest
functions and just hashes the key with them. Michael MIC initializes
some of the internal state (L and R in the implementation) with the key.
This would mean that the kmac_init() would need to know something about
the used digest algorithm or we would need to have setkey handler for
the digests (which is actually the way I implemented Michael MIC in the
original patch).

crypto_kmac() can be implemented, if that is considered useful wrapper
for Michael MIC. However, I'm not sure whether the other part of this
would work very well with Michael MIC. In addition, I'm not sure whether
there would be another algorithm using this new keyed has method. HMAC
and CBC-MAC (which, btw, is also on my list of crypto API things to do
for IEEE 802.11i) are using more generic mechanism and can be used with
multiple algorithms and are probably prefered for anything that requires
real security.

If you prefer, I can make a new type crypto alg type
(CRYPTO_ALG_TYPE_KEYED_DIGEST) and make it a clone of the
CRYPTO_ALG_TYPE_DIGEST with the only change of adding a new callback,
setkey, in the way I added in the patch for CRYPTO_ALG_TYPE_DIGEST. This
would leave the digest type unmodified, but would result in copying most
of the digest code. I do not see much benefit of this because the
dia_setkey function pointer does not seem to change the old digest
functionality at all since it is optional and since this function
pointer does not even enlarge struct crypto_alg due to the cra_u union
already being a bit larger than the current struct digest_alg.

> Is there an 802.11i spec available? It seems like there are only drafts
> available which require payment. I'd like to see the Micheal MIC
> algorithm description & know of any potential IP rights issues.

IEEE 802.11i draft is not freely available. The finalized standard is
likely to become freely available six month after its publications (I
would guess this would be about early 2005 or so). However, the proposal
for Michael MIC is available from
This includes full description of the algorithm, analysis of it and
reasoning for the compromises needed for TKIP. I haven't verified, but I
would assume that this matches with the algorithm as defined in the
current IEEE 802.11i draft.

As far as IP rights (I would assume you mean patents, in this case) are
concerned, IEEE has a policy* of requiring a statement about potential
patent application on the algorithms used in the standards. I do not
remember seeing such a statement about Michael MIC (of course this does
not mean that there is not one, but at least I haven't seen one) and
could not find such a statement in the IEEE 802.11 patent statements**.
In addition, the author of Michael MIC proposal has put the reference
implementation code in the public domain.


> Also, is there any mainline kernel code which would use this feature?

Well, the main goal for me here is to get Host AP driver in shape for
mainline inclusion.. ;-)

The only use for Michael MIC seems to be in implementing TKIP since it
is not very secure (due to compromises needed to support old legacy wlan
hardware). This is needed for wireless LAN cards that cannot or at least
do not implement TKIP in hardware/firmware. It may also be useful, if
the hardware implementation does not support all needed modes (e.g., AP)
or is considered too slow. Some of the current IEEE 802.11b drivers in
the mainline kernel would be likely canditates for using this when
WPA/IEEE 802.11i support is added.

Jouni Malinen PGP id EFC895FA
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.138 / U:5.452 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site