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) +
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 mai
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.
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 precedin
On Tue, Oct 19, 2010 at 3:44 PM, Herbert Xu
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 the kernel.
> The intended
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 speci
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 devic
On Tue, Sep 7, 2010 at 4:06 PM, Christoph Hellwig 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 intensive co
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 do
- "Christoph Hellwig" 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 the kern
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 t
- "Herbert Xu" 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));
> > > > > se
On Tue, Sep 7, 2010 at 4:11 PM, Herbert Xu 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 intensive c
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 map
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_AEA
- "Herbert Xu" wrote:
> On Tue, Sep 07, 2010 at 07:27:47AM -0400, Miloslav Trmac wrote:
> > Hello,
> > - "Herbert Xu" 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 i
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
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
On Tue, Sep 07, 2010 at 07:27:47AM -0400, Miloslav Trmac wrote:
> Hello,
> - "Herbert Xu" 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
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
Hello,
- "Herbert Xu" 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);
> /* fd for encryption
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 speci
22 matches
Mail list logo
