Re: [Design] some comments on Linux CryptoAPI - this "atomic" cipher business

[Jean-Luc Cooke <jlcooke@certainkey.com>]

WR hardware interfaces, has anyonelooked into a PKCS#11 interface for all
this?  It _is_ the standard.  If a cryptoapi impl'n of pkcs11 is attractive,
I'll do it.

JLC

On Mon, Jul 22, 2002 at 08:42:25AM -0400, Martin Gadbois wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael Richardson wrote:
> |     Martin> How about a in-between application that want to use
> hardware, but in an
> |     Martin> atomic fashion? This is how I started doing things before
> using a callback.
> |     Martin> In some occasions, it might be good to be able to wait for
> the hardware
> |     Martin> to finish encrypting by busy-looping. It is still more
> efficient to do
> |     Martin> that then to wait for 3DES to finish in S/W.
> |
> |   That would require some new interface into the device driver.
> |   One could busy wait on some flag in the struct transform_command
> perhaps.
> |   I'd like to understand the reason for this.
> 
> If, like FreeS/WAN now, you want to replace crypto operations to use
> hardware but FreeS/WAN cannot wait while the hardware encrypts the
> packet, what do you do? What I did first is I replaced
> des_ede3_cbc_encrypt() with the one that does hardware, and wait for it
> to complete. YOu win, because time(HW) < time(SW).
> This is a drop-in replacement for existing applications that uses
> functions like des_ede3_cbc_encrypt(). Those application will benefits
> immedialtly from hardware acceleration.
> 
> 
> 
> |
> |     Martin> I therefore suggest to leave the hardware specification to
> the library.
> |
> |   What do you mean by this?
> |
> |     Martin> You want to say " I want this done ASAP, with those
> limitation (SYNC or
> |     Martin> ASYN)". That way, the library chooses the best available
> hardware (or
> |     Martin> software) to execute the request, according to specified
> |     Martin> limitations.
> |
> |   Sure, but users have to have a way to override things.
> 
> Ok. "aes-cbc/hardware" would do that.
> 
> 
> |
> |     Martin> Something is missing: the start of the operation, and size
> of the
> |     Martin> operation. Is that included in tc_cmdqueue?
> |
> |     Martin> Example: on packet pointer at tc_in, do HMAC from in+4 for
> size1, and
> |     Martin> then do 3DES from in+16 for size2.
> |
> |   My feeling is that one opens the "esp/3DES/HMAC-MD5" cipher if one
> wants it
> | done in one operation and ESP knows this stuff.
> 
> Isn't that complicating the "Naming of ciphers"?
> In the FreeS/WAN hardware acceleration patch
> (http://sources.colubris.com) I use a structure for the request, and a
> list of transform (algorithm, offset, len) to do on the request. I
> though that is what you meant with the tc_cmdqueue member.
> 
> 
> |
> |     Martin> We also need some kind of open_session()/close_session().
> H/W can
> |     Martin> remember keys (no need to transfer them with every
> command) but we need
> |     Martin> to manage that either explicitly, on implicitly (use a LRU
> algo). On the
> |     Martin> Hifn 7811 and 7901, there is a limited number of H/W
> session available,
> |     Martin> due to memory constrains.
> |
> |   That's handled by the driver by reference to the per-SA
> | 	 struct cipher_context *tc_context;
> |
> |   If you want to handle keys explicitely, I presume that this means
> locking
> | certain keys into the hardware, while cycling others? (For instance,
> VPN keys
> | stay in the hardware, while RW or OE get LRU). I would think that perhaps
> | this stuff goes into to initialization code for creating the
> cipher_context
> | ("open_session" as you call it).
> 
> Possibly, but in any case, software need to oversee the hardware key
> management.
> 
> The FreeS/WAN acceleration patch does not use H/W keys, as our
> application does not have extra memory to store keys.
> 
> - --
> ==============
> Martin Gadbois
> S/W Developper
> Colubris Networks Inc.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAj07/bAACgkQ9Y3/iTTCEDlJdgCffGlxR7thVUjnfwnsrQy3q6Ox
> bd8An2FslAfq36FVA+GqdLKbDzdu/Llg
> =4MC5
> -----END PGP SIGNATURE-----
> 
> -
> Linux-crypto:  cryptography in and on the Linux system
> Archive:       http://mail.nl.linux.org/linux-crypto/

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
C: 613.263.2983
-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/