lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 24 Jan 2013 10:45:18 +0200
From:	Jussi Kivilinna <jussi.kivilinna@...et.fi>
To:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Cc:	Tom St Denis <tstdenis@...iptictech.com>,
	linux-kernel@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>,
	linux-crypto@...r.kernel.org,
	Steffen Klassert <steffen.klassert@...unet.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH] CMAC support for CryptoAPI, fixed patch issues,
 indent, and testmgr build issues

Quoting YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>:

> YOSHIFUJI Hideaki wrote:
>> Jussi Kivilinna wrote:
>>
>>>>>> diff --git a/include/uapi/linux/pfkeyv2.h
>>>>>> b/include/uapi/linux/pfkeyv2.h
>>>>>> index 0b80c80..d61898e 100644
>>>>>> --- a/include/uapi/linux/pfkeyv2.h
>>>>>> +++ b/include/uapi/linux/pfkeyv2.h
>>>>>> @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
>>>>>>  #define SADB_X_AALG_SHA2_512HMAC    7
>>>>>>  #define SADB_X_AALG_RIPEMD160HMAC    8
>>>>>>  #define SADB_X_AALG_AES_XCBC_MAC    9
>>>>>> +#define SADB_X_AALG_AES_CMAC_MAC    10
>>>>>>  #define SADB_X_AALG_NULL        251    /* kame */
>>>>>>  #define SADB_AALG_MAX            251
>>>>>
>>>>> Should these values be based on IANA assigned IPSEC AH transform
>>>>> identifiers?
>>>>>
>>>>> https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6
>>>>
>>>> There is no CMAC entry apparently ... despite the fact that CMAC  
>>>> is a proposed RFC standard for IPsec.
>>>>
>>>> It might be safer to move that to 14 since it's currently  
>>>> unassigned and then go through whatever channels are required to  
>>>> allocate it.  Mostly this affects key setting.  So this means my  
>>>> patch would break AH_RSA setkey calls (which the kernel doesn't  
>>>> support anyways).
>>>>
>>>
>>> Problem seems to be that PFKEYv2 does not quite work with IKEv2,  
>>> and XFRM API should be used instead. There is new numbers assigned  
>>> for IKEv2:  
>>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
>>>
>>> For new SADB_X_AALG_*, I'd think you should use value from  
>>> "Reserved for private use" range. Maybe 250?
>>
>> We can choose any value unless we do not break existing
>> binaries.  When IKE used, the daemon is responsible
>> for translation.
>
> I meant, we can choose any values "if" we do not break ...
>

Ok, so giving '10' to AES-CMAC is fine after all?

And if I'd want to add Camellia-CTR and Camellia-CCM support, I can  
choose next free numbers from SADB_X_EALG_*?

-Jussi


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ