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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100119.003041.193317921.davem@davemloft.net>
Date:	Tue, 19 Jan 2010 00:30:41 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	lyw@...fujitsu.com
Cc:	herbert@...dor.apana.org.au, netdev@...r.kernel.org
Subject: Re: [PATCH][XFRM] Use the simple name when adding SAD with ip xfrm
 state

From: Li Yewang <lyw@...fujitsu.com>
Date: Tue, 19 Jan 2010 16:25:22 +0800

> 
> 
> Herbert Xu wrote:
>> Li Yewang <lyw@...fujitsu.com> wrote:
>>> The encryption name such as "rfc3686(ctr(aes))" is too complex.
>>> I think simple name is better for user when using "ip xfrm state ..." command.
>>>
>>>
>>> Signed-off-by: Li Yewang <lyw@...fujitsu.com>
>> 
>> Nack.  If we want to support simple names such as these, they
>> should be done in the crypto layer.  Otherwise every crypto user
>> that wants this would have to reinvent it.
> 
>   But user sets SAD for ipsec with "ip xfrm state ..." must use the name such as "rfc3686(ctr(aes))".
>   Is that reasonable? Maybe user can not remember this complex name.
> 
>   There are some simple names for other encryptions, 
>   such as "cbc(blowfish)", you can use "ip xfrm state ... enc blowfish ...".

You're not reading what Herbert is saying.

He's fine with the shorter name, he just wants you to implement
is in the crypto layer core instead of the XFRM specific code.

That way all crypto users will benefit from the shorter naming.
--
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