netdev - Re: Support for ECDH P-192 and P-256

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>] [day] [month] [year] [list]

Message-ID: <20140226220333.GA28414@gondor.apana.org.au>
Date:	Thu, 27 Feb 2014 06:03:33 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: Support for ECDH P-192 and P-256

Marcel Holtmann <marcel@...tmann.org> wrote:
> Hello,
> 
> we are looking at adding support for Bluetooth Secure Connections to the Security Manager of the Bluetooth subsystem. For that we would need support for ECDH P-256 and eventually also P-192.
> 
> Right now we are bit lost on how this could be achieved best. I saw that the symmetric_keys feature has support for public_keys, but as far as I can tell that requires that userspace loads the public keys into the kernel and the private keys stay in userspace.
> 
> What we need is to generate private/public key pairs using elliptic curve with P-192 and P-256. We only need the private/public key pair for the Bluetooth pairing. After successful pairing, we derive link keys or long term keys and we can throw the private/public key pair away. Any further authentication between Bluetooth devices is done via their link keys or long term keys.
> 
> Has anybody looked into extending the kernel crypto framework to support ECDH P-192 and P-256. If nobody has, what are the best starting points to do so.

Normally key exchange is conducted in user-space because it isn't
performance-critical so as not to bloat the kernel.  For example,
only the data-path of IPsec is implemented in the kernel, while
the key exchange protocol IKE Is done in user-space.  That's why
there is no current support for key exchange-related algorithms
in the kernel crypto API.

If there is agreement that Bluetooth's key exchange must be done
in the kernel, then we certainly start adding these algorithms.

I haven't been following this but is there a consensus from the
networking folks regarding Bluetooth's key exchange code?

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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