> On Wed, Sep 27, 2000 at 01:38:31PM +0000, Marc Mutz wrote: > I think there are some interesting issues to be solved when we want to > get hardware crypto cards running under Linux. For one, we want to > have a queue of processing requests for the device instead of having a > synchronous interface like most crypto libraries offer. We also > probably want to use the CPU if the queue starts to have too many > entries, or load-balance between several cards, so we need a > "crypto-provider" concept. Also, for programmable crypto-cards we > might want to consider the cost of switching ciphers on the card when > choosing which requests should be done by which cards/CPU. This will > be interesting to look at when the first drivers emerge. A queuing concept is definately needed if this is to be done right the first time (so to speak). The configuration of this interface, however, would be the interesting challenge here. How to present to the user (the sysadmin, most likely) the options for dealing with crypto on a per-system, perhaps per-app basis. Prioritising certain applications over others, perhaps, would end up being an issue as well. For example: OpenSSL uses the "crypto accel api" for web serving. FreeS/WAN uses it for VPN traffic. GPG uses it to encrypt E-mails or generate signatures. I would probably set the FreeS/WAN requests to have a slightly lower priority than the OpenSSL requests because we host E-commerce sites ... and the GPG traffic would be lowest, but I wouldn't want it to get swamped out of the picture if the crypto card were at full use. Having it send a suitable? number of requests to the software crypto system would be necessary as well. It becomes quite interestingly complex ;-). Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
