[16721] in cryptography@c2.net mail archive
Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time (fwd from clemens@endorphin.org)
daemon@ATHENA.MIT.EDU (Eugen Leitl)
Wed Jan 26 19:34:21 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sat, 15 Jan 2005 15:02:23 +0100
From: Eugen Leitl <eugen@leitl.org>
To: Cryptography List <cryptography@metzdowd.com>
--PYIYUqPwp6hDCm1g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Fruhwirth Clemens <clemens@endorphin.org>
Subject: Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers
at a time
To: Michal Ludvig <michal@logix.cz>
Cc: Andrew Morton <akpm@osdl.org>, James Morris <jmorris@redhat.com>,
cryptoapi@lists.logix.cz, "David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org
Date: Sat, 15 Jan 2005 13:45:37 +0100
On Fri, 2005-01-14 at 17:40 +0100, Michal Ludvig wrote:=20
> > Is there any connection to Evgeniy Polyakov's acrypto work? It appears,
> > that there are two project for one objective. Would be nice to see both
> > parties pulling on one string.
>=20
> These projects do not compete at all. Evgeniy's work is a complete=20
> replacement for current cryptoapi and brings the asynchronous=20
> operations at the first place. My patches are simple and straightforward=
=20
> extensions to current cryptoapi that enable offloading the chaining to=20
> hardware where possible.
Fine, I just saw in Evgeniy's reply, that he took your padlock
implementation. I thought both of you have been working on different
implementations.=20
But actually both aim for the same goal. Hardware crypto-offloading.
With padlock the need for a async interface isn't that big, because it's
not "off-loading" as it's done on the same chip and in the same thread.=20
However, developing two different APIs isn't particular efficient. I
know, at the moment there isn't much choice, as J.Morris hasn't commited
to acrypto in anyway. But I think it would be good to replace the
synchronized CryptoAPI implementation altogether, put the missing
internals of CryptoAPI into acrypto, and back the interfaces of
CryptoAPI with small stubs, that do like
somereturnvalue synchronized_interface(..) {
acrypto_kick_some_operation(acrypto_struct);
wait_for_completion(acrypto_struct);
return fetch_result(acrypto_struct);
}
The other way round, a asynchron interface using a synchronized
interface doesn't seem natural to me.
(That doesn't mean I oppose your patches, merely that we should start to
think in different directions)
> > > + void (*cia_ecb)(void *ctx, u8 *dst, const u8 *src, u8 *iv,
> > > + size_t nbytes, int encdec, int inplace);
> > > + void (*cia_cbc)(void *ctx, u8 *dst, const u8 *src, u8 *iv,
> > > + size_t nbytes, int encdec, int inplace);
> > > + void (*cia_cfb)(void *ctx, u8 *dst, const u8 *src, u8 *iv,
> > > + size_t nbytes, int encdec, int inplace);
> > > + void (*cia_ofb)(void *ctx, u8 *dst, const u8 *src, u8 *iv,
> > > + size_t nbytes, int encdec, int inplace);
> > > + void (*cia_ctr)(void *ctx, u8 *dst, const u8 *src, u8 *iv,
> > > + size_t nbytes, int encdec, int inplace);
> >=20
> > What's the use of adding mode specific functions to the tfm struct? And
> > why do they all have the same function type? For instance, the "iv" or
> > "inplace" argument is meaningless for ECB.
>=20
> The prototypes must be the same in my implementation, because in crypt()=
=20
> only a pointer to the appropriate mode function is taken and further used=
=20
> as "(func*)(arg, arg, ...)".
>=20
> BTW these functions are not added to "struct crypto_tfm", but to "struct=
=20
> crypto_alg" which describes what a particular module supports (i.e. along=
=20
> with the block size, algorithm name, etc). In this case it can say that=
=20
> e.g. padlock.ko supports encryption in CBC mode in addition to a common=
=20
> single-block processing.
Err, right. I overlooked that it's cia and not cit. However, I don't
like the idea of extending structs when there is a new cipher mode. I
think the API should not have to be extended for every addition, but
should be designed for such extension right from the start.
What about a "selector" function, which returns the appropriate
encryption function for a mode?
typedef void (procfn_t)(struct crypto_tfm *, u8 *,
u8*, cryptfn_t, int enc, void *, int);
put=20
procfn_t (*cia_modesel)(u32 function, int iface, int encdec);
into struct crypto_alg;
then in crypto_init_cipher_ops, instead of
switch (tfm->crt_cipher.cit_mode) {
=2E.
case CRYPTO_TFM_MODE_CFB:
ops->cit_encrypt =3D cfb_encrypt;
ops->cit_decrypt =3D cfb_decrypt;
=2E.
}
we do,
struct cipher_alg *cia =3D &tfm->__crt_alg->cra_cipher;
=09
switch (tfm->crt_cipher.cit_mode) {
=2E.
case CRYPTO_TFM_MODE_CFB:
ops->cit_encrypt =3D cia->cia_modesel(cit_mode, 0, IFACE_ECB);
ops->cit_decrypt =3D cia->cia_modesel(cit_mode, 1, IFACE_ECB);
ops->cit_encrypt_iv =3D cia->cia_modesel(cit_mode, 0, IFACE_IV);
ops->cit_decrypt_iv =3D cia->cia_modesel(cit_mode, 1, IFACE_IV);
=2E.
Alternatively, we could also add a lookup table. But I like this better,
since this is much easier to read for people, and tfm's aren't alloced
that often.
Probably, we can add a wrapper for cia_modesel, that when cia_modesel is
NULL, it falls back to the old behaviour. This way, we don't have to
patch all algorithm implementations to include cia_modesel.
How you like that idea?
--=20
Fruhwirth Clemens <clemens@endorphin.org> http://clemens.endorphin.org
_______________________________________________
Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
List archive: http://lists.logix.cz/pipermail/cryptoapi
----------
--=20
Eugen* Leitl <a href=3D"http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144 http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
http://moleculardevices.org http://nanomachines.net
--PYIYUqPwp6hDCm1g
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQFB6SJvdbAkQ4sp9r4RAtJsAJ9yr71bDpx/7Ix/MIajo5zCmUGRHACfc0Gf
rBsBKOQPHnkkk5FB063Tk6A=
=i8ZC
-----END PGP SIGNATURE-----
--PYIYUqPwp6hDCm1g--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
