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/
