From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 21 13:15:28 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2303106566C for ; Mon, 21 Jul 2008 13:15:28 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045140.chello.pl [87.206.45.140]) by mx1.freebsd.org (Postfix) with ESMTP id 29E0C8FC26 for ; Mon, 21 Jul 2008 13:15:27 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5826445C9B; Mon, 21 Jul 2008 15:15:26 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5E0CA456B1; Mon, 21 Jul 2008 15:15:20 +0200 (CEST) Date: Mon, 21 Jul 2008 15:15:25 +0200 From: Pawel Jakub Dawidek To: Patrick Lamaizi?re Message-ID: <20080721131525.GC2953@garage.freebsd.pl> References: <20080719005813.3a995c71@baby-jane-lamaiziere-net.local> <20080720193955.GA2193@garage.freebsd.pl> <20080721141000.03127887@baby-jane-lamaiziere-net.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qbvjkv9qwOGw/5Fx" Content-Disposition: inline In-Reply-To: <20080721141000.03127887@baby-jane-lamaiziere-net.local> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-hackers@freebsd.org Subject: Re: crypto(9) and maxoplen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 13:15:28 -0000 --Qbvjkv9qwOGw/5Fx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 02:10:00PM +0200, Patrick Lamaizi?re wrote: > Le Sun, 20 Jul 2008 21:39:55 +0200, > Pawel Jakub Dawidek a =E9crit : >=20 > Hello, >=20 > > > In the "opencrypto framework" the function crypto_register() has an > > > argument 'maxoplen'. > > >=20 > > > http://fxr.watson.org/fxr/source/opencrypto/crypto.c#L625 > > >=20 > > > Does somebody know what was the goal of this parameter? It is not > > > used by the framework. > > >=20 > > > The man page of crypto(9) says : > > > For each algorithm the driver supports, it must then call > > > crypto_register(). The first two arguments are the driver and > > > algorithm identifiers. The next two arguments specify the largest > > > possible operator length (in bits, important for public key > > > operations) and flags for this algorithm. > > >=20 > > > I'm asking if it can help for this problem: the glxsb driver can > > > perform AES-CBC algorithm only with 128 bits key and may be > > > 'maxoplen' was intended for this case.=20 > > >=20 > > > Without something to specify the key's length, the driver is > > > selected by the framework even with keys !=3D 128 bits. So it fails > > > when the session is opened. This prevents setkey/ipsec to work with > > > key length !=3D 128 bits if the driver is loaded. > >=20 > > If I read code properly, there is currently no way for a driver to say > > to the opencrypto framework that only AES-CBC with 128bit key is > > supported. A driver can only state that it supports AES-CBC, that's > > all. As a workaround the driver should implement AES-CBC-192 and > > AES-CBC-256 in software. >=20 > Yes, but my question is about the maxoplen parameter. Was it intended > for this case? Why we keep this parameter? Can't help here, no idea. Eventhough it isn't something I'd like to see implemented. 'maxoplen' is just a little better than what we have now. And what if a driver supports 192 or 256 bits only? > IMHO, It is far easier to hack the OCF to use this parameter than > to implement a workaround. It would be a better solution, by > sample we may want to use the driver for AES-128 and another > hardware that provides AES 192/256. >=20 > Another (the best?) solution would be for the crypto framework to select > another driver if the driver's newsession() fails. There are many improvements that could be done in opencrypto framework, believe me. One of the things that annoys me a lot is that if you want to use IPsec with a driver that support only encryption, you have to implement hash functions in software for the given driver. Feel free to work on this, but be sure to avoid solutions like this maxoplen thing, which bascially isn't really a step further. Choosing another driver on newsession failure sounds reasonable, although we may lose informations like 'the caller wanted hardware crypto only'. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Qbvjkv9qwOGw/5Fx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIhIvsForvXbEpPzQRAqvUAJ4puGaLH1tiR2lPb9ataSgMzqKK9wCcD+SD wy7ZpTsuj1ckv6ClhEQuDMU= =/f0d -----END PGP SIGNATURE----- --Qbvjkv9qwOGw/5Fx--