Re: Crypto API and keyed non-HMAC digest algorithms / Michael MIC
From: James Morris
Date: Mon Mar 08 2004 - 09:46:10 EST
On Sat, 6 Mar 2004, Jouni Malinen wrote:
> Current Linux crypto API does not seem to have generic mechanism for
> adding keyed digest algorithms that are not using HMAC construction.
> IEEE 802.11i/WPA uses such an algorithm in TKIP and getting this to
> crypto API would be useful in order to be able to share more code of
> TKIP implementation.
>
> 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. Is the modification of digest type acceptable way of
> adding support for a keyed digest algorithm that does not use HMAC?
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.
This would be a config option.
> The patch includes test vectors for Michael MIC and I have tested this
> with the Host AP driver and TKIP. Getting this into crypto API is one of
> the first steps in replacing the internal crypto algorithm
> implementation in the Host AP driver code and I would appreciate it if
> this would be applied to Linux 2.6 tree.
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.
Also, is there any mainline kernel code which would use this feature?
- James
--
James Morris
<jmorris@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/