RE: RFC: Crypto API User-interface

2014-05-30 Thread Jitendra Lulla
Hi, http://lwn.net/Articles/410848/ The following code is taken from the above page: int main(void) { int opfd; int tfmfd; struct sockaddr_alg sa = { .salg_family = AF_ALG, .salg_type = skcipher, .salg_name = cbc(aes) }; struct msghdr msg = {}; struct cmsghdr *cmsg; char cbuf[CMSG_SPACE(4) +

RE: RFC: Crypto API User-interface

2014-04-23 Thread Jitendra Lulla
Hi, This is regarding the hash computation over a file with AF_ALG from user space. [without OpenSSL] The following link has the mail from Herbert with subject : RFC: Crypto API User-interface http://lwn.net/Articles/410848/ I was trying to take help from the code snippet he has put in his mail

Re: RFC: Crypto API User-interface

2010-11-04 Thread Herbert Xu
On Tue, Oct 19, 2010 at 09:44:18PM +0800, Herbert Xu wrote: OK I've gone ahead and implemented the user-space API for hashes and ciphers. Here is a revised series with bug fixes and improvements. The main change is that hashes can now be finalised by recvmsg instead of requiring a preceding

Re: RFC: Crypto API User-interface

2010-11-04 Thread Herbert Xu
On Thu, Nov 04, 2010 at 01:43:16PM -0400, Miloslav Trmac wrote: shash_async_import() - it assumes that the struct shash_desc placed in ahash_request_ctx() of the struct ahash_request was initialized to point to the tfm, which is only done in shash_async_init(). Thanks for catching this.

Re: RFC: Crypto API User-interface

2010-10-20 Thread Nikos Mavrogiannopoulos
On Tue, Oct 19, 2010 at 3:44 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: OK I've gone ahead and implemented the user-space API for hashes and ciphers. To recap this interface is designed to allow user-space programs to access hardware cryptographic accelerators that we have added to

Re: RFC: Crypto API User-interface

2010-10-19 Thread Herbert Xu
On Tue, Sep 07, 2010 at 04:42:13PM +0800, Herbert Xu wrote: This is what I am proposing for the Crypto API user-interface. Note that this is the interface for operations. There will be a separate interface (most likely netlink) for configuring crypto algorithms, e.g., picking a specific

RFC: Crypto API User-interface

2010-09-07 Thread Herbert Xu
Hi: This is what I am proposing for the Crypto API user-interface. Note that this is the interface for operations. There will be a separate interface (most likely netlink) for configuring crypto algorithms, e.g., picking a specific AES implementation as the system default. First of all let's

Re: RFC: Crypto API User-interface

2010-09-07 Thread Tomas Mraz
On Tue, 2010-09-07 at 16:42 +0800, Herbert Xu wrote: Hi: This is what I am proposing for the Crypto API user-interface. Note that this is the interface for operations. There will be a separate interface (most likely netlink) for configuring crypto algorithms, e.g., picking a specific

Re: RFC: Crypto API User-interface

2010-09-07 Thread Miloslav Trmac
Hello, - Herbert Xu herb...@gondor.hengli.com.au wrote: First of all let's have a quick look at what the user-space side looks like for AEAD: /* Each listen call generates one or more fds for input/output * that behave like pipes. */ listen(tfmfd, 0);

Re: RFC: Crypto API User-interface

2010-09-07 Thread Christoph Hellwig
On Tue, Sep 07, 2010 at 04:42:13PM +0800, Herbert Xu wrote: Hi: This is what I am proposing for the Crypto API user-interface. Can you explain why we would ever want a userspace interface to it? doing crypto in kernel for userspace consumers sis simply insane. It's computational intensive

Re: RFC: Crypto API User-interface

2010-09-07 Thread Herbert Xu
On Tue, Sep 07, 2010 at 07:27:47AM -0400, Miloslav Trmac wrote: Hello, - Herbert Xu herb...@gondor.hengli.com.au wrote: First of all let's have a quick look at what the user-space side looks like for AEAD: /* Each listen call generates one or more fds for input/output *

Re: RFC: Crypto API User-interface

2010-09-07 Thread Herbert Xu
On Tue, Sep 07, 2010 at 10:06:46AM -0400, Christoph Hellwig wrote: On Tue, Sep 07, 2010 at 04:42:13PM +0800, Herbert Xu wrote: Hi: This is what I am proposing for the Crypto API user-interface. Can you explain why we would ever want a userspace interface to it? doing crypto in kernel

Re: RFC: Crypto API User-interface

2010-09-07 Thread Christoph Hellwig
On Tue, Sep 07, 2010 at 10:11:12PM +0800, Herbert Xu wrote: FWIW I don't care about user-space using kernel software crypto at all. It's the security people that do. And since when did we care about their crack pipe dreams? The purpose of the user-space API is to export the hardware crypto

Re: RFC: Crypto API User-interface

2010-09-07 Thread Herbert Xu
On Tue, Sep 07, 2010 at 10:24:27AM -0400, Christoph Hellwig wrote: I don't think they matter in practice. We have less than a handfull of drivers for them, and with CPUs gaining proper instructions they are even less useful. In addition any sane PCI card should just allow userspace mapping

Re: RFC: Crypto API User-interface

2010-09-07 Thread Herbert Xu
On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote: /* These may also be set through sendmsg(2) cmsgs. */ op = ALG_AEAD_OP_ENCRYPT; setsockopt(opfd, SOL_ALG, ALG_AEAD_OP, op, sizeof(op)); setsockopt(opfd, SOL_ALG, ALG_AEAD_SET_IV, iv,

Re: RFC: Crypto API User-interface

2010-09-07 Thread Nikos Mavrogiannopoulos
On Tue, Sep 7, 2010 at 4:11 PM, Herbert Xu herb...@gondor.hengli.com.au wrote: This is what I am proposing for the Crypto API user-interface. Can you explain why we would ever want a userspace interface to it? doing crypto in kernel for userspace consumers sis simply insane. It's

Re: RFC: Crypto API User-interface

2010-09-07 Thread Christoph Hellwig
On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote: - Don't use a FD for associated data that is limited to 16? bytes - Don't use file descriptors for input data at all, if it makes the interface so complex. Calling into the kernel for 16 bytes of crypto is a braindead idea to

Re: RFC: Crypto API User-interface

2010-09-07 Thread Miloslav Trmac
- Herbert Xu herb...@gondor.hengli.com.au wrote: On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote: /* These may also be set through sendmsg(2) cmsgs. */ op = ALG_AEAD_OP_ENCRYPT; setsockopt(opfd, SOL_ALG, ALG_AEAD_OP, op, sizeof(op));

Re: RFC: Crypto API User-interface

2010-09-07 Thread Miloslav Trmac
- Christoph Hellwig h...@infradead.org wrote: On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote: - Don't use a FD for associated data that is limited to 16? bytes - Don't use file descriptors for input data at all, if it makes the interface so complex. Calling into

Re: RFC: Crypto API User-interface

2010-09-07 Thread Christoph Hellwig
On Tue, Sep 07, 2010 at 10:52:03AM -0400, Miloslav Trmac wrote: Because in the real world people want both certification, features _and_ performance. If all they cared about is certification they could just as well buy a pencil. Okay Mr Smartass. Please put away your crackpipe and get down

Re: RFC: Crypto API User-interface

2010-09-07 Thread Nikos Mavrogiannopoulos
On Tue, Sep 7, 2010 at 4:06 PM, Christoph Hellwig h...@infradead.org wrote: This is what I am proposing for the Crypto API user-interface. Can you explain why we would ever want a userspace interface to it? doing crypto in kernel for userspace consumers sis simply insane. It's computational

Re: RFC: Crypto API User-interface

2010-09-07 Thread Christoph Hellwig
On Tue, Sep 07, 2010 at 04:57:04PM +0200, Nikos Mavrogiannopoulos wrote: Or that someone is not really aware of some cryptographic uses. Embedded systems have crypto accelerators in hardware available through kernel device drivers. In the systems I worked the accelerators via a crypto device