-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Martin" == Martin Gadbois <martin.gadbois@colubris.com> writes:
Martin> Michael Richardson wrote:
{seems that the message got stuck in my outbox...}
Martin> | This permits one to VERY specifically attach to the implementation
Martin> that one
Martin> | wants, while still permitting "aes-cbc" to get something useful. This all
Martin> | would occur at registration and lookup of cipher_implementation time.
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.
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.
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.
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).
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPTh/f4qHRg3pndX9AQFSCQQA1mcbbZOXKWpXWe5wuFdXvo5yMzXzlb5l
ixqMR+/29zS7vLfnXwiSWYMf5jXki47ft1IkdmHbkST+6EEuB5vxr204dXcAtort
znu32Ydo1tfDRKI188ZHdkQRTRdK/Q5C0yb0DcvSDrmSxz9nQgOJ+oKGZoHY1XpJ
O8RURez+LWE=
=QPU3
-----END PGP SIGNATURE-----
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
