On Wed, May 14, 2008 at 01:57:30PM +0200, Sebastian Siewior (linux-crypto@xxxxxxxxxxxxxxxx) wrote: > 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() Above but without special device, but syscall instead, which will have all needed parameters like mode string, key, iv and sizes. > - 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. Well, it might be time to start :) I'm not sure virtual filesystem is needed though, but as well can be a good idea. At least not ioctl hell with /dev/crypto -- Evgeniy Polyakov -- 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
