* Herbert Xu | 2008-05-14 19:03:11 [+0800]:
>On Wed, May 14, 2008 at 12:32:24PM +0200, Sebastian Siewior wrote:
>>
>> >This should add support for OpenSSL. Please note that user of this patch
>> >musts patch OpenSSL. The OpenSSL patch can be found in OCF-Linux as this
>> >interface uses the same I/O control interface.
>> So this interface must stay as it in order not to patch openssl twice?
>
>I don't think compatibility with OCF is necessary at all. We
>should create an interface that is suitable for Linux first of
>all rather than concentrating on OCF.
Great. Here a few ideas for a new interface:
- /dev/crypto:
- open file, creates a new ctx which may be one of crypto/hash/...
- set type via ioctl / netlink
- set key / other attributes via ioctl
- put a block for encryption via write()
- wait until it is done. poll() could be used to determine this state
- read the result via read().
- ->final() (hash) could be executed on read()
- cryptofs attempt (somehow inspired by spufs):
- 1 syscall to create a special crypto device (that is aes(cbc),
hmac(sha1) or what ever the crypto api offers).
- returns a handle and creates a unique folder in cryptfs
- the folder is RW to the owner
- and contains properties of the algorithm. So we write in the file
keysize to specify the size of the key and write to the file key to
set the key. This properties are based on the class of the algorithm
(should be almost equal I guess).
- Every crypto request will be created once a file in the request
folder is created. Request is fed with data via the write().
- I'm not sure how we signalize that a request is done. Maybe another
file pops up and we can track this via inotify.
So I put this two for discussion :)
I came up with those two a while ago but never wrote code because I had
no use case.
>
>Cheers,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
