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

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----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/