[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Design] some comments on Linux CryptoAPI - this "atomic" cipherbusiness
-----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/