Hi,
Linux Crypto User Space Interface Requirement:
1. Support crypto and hashing/digest
2. Flexible to support compression in the future
3. Flexible to support PKA (public key acceleration) in the future
4. A file descriptor per algorithms
5. Key and algorithm attributes provided by user space application
(caller)
6. Support non-blocking and blocking mode
7. Support multiple operation requests concurrently
8. Support cancel a pending operation for user space caller
9. Flexible to avoid double memory copy for future
10. scalable - meaning can operate on large amount of data if the
underlying algorithm support it. Hardware algorithm (such as HMAC
hashing) have a limit. This requirement complicate the interface. May
not support initially.
Linux Crypto User Space Interface Proposal:
1. Use file descriptor named '/dev/crypto'
2. Each opened file creates a new 'crypto' context that represents a
crypto algorithms - crypto, hash, compression, PKA, and etc
3. The type of algorithm, key, and other attributes are selected via IO
control call. This will be a single call.
4. Algorithm name maps directly into Linux CryptoAPI algorithm name
5. Interface for per operation (such as encrypt, decrypt, compress, PKA,
and hashing)
5a. Read and write functions
5a.1. Read and write functions are stream based. We are
packet based. Using this interface isn't quite appropriate. In addition,
the input data also has an output data. Read and write doesn't quite
correlate properly. This can be a problem as the output buffer isn't
available until the read operation is performed. In addition, the caller
will have to correlate between the write and read. If it is AIO, then
this would be simpler to correlate but still doesn't solve the problem
with an output buffer requirement. For crypto, the output can be the
input buffer. But what about hashing operation. This model just does fit
well. In addition, for PKA, input operands are bundled into a single
byte array. This makes it difficults to understand.
5b. I/O control calls
5b.1. The objection to this is 'I/O control hell'. This
isn't that bad. To handle asynchronous I/O, once can implement
asynchronous I/O control.
5c. System calls
5c.1. This can be used if majority of the community
don't like to use I/O control. The first input will be the file
descriptor.
Any comments or objection?
Herbert,
I haven't heard your comment. What do you think?
-Loc
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
