On Wed, May 14, 2008 at 01:57:30PM +0200, Sebastian Siewior ([EMAIL PROTECTED])
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
