> 1. This CrytoDev (user space) interface needs to support multiple
> operations at once
I think this would be naturally solved by providing the async interface.
[Loc Ho]
Async only support a single operation at a time. HW are quite fast. The ability
to submit multiple payload for a sin
Hi Miloslav,
I had read or glance over the patch from "
http://people.redhat.com/mitr/cryptodev-ncr/0002";. We have post a version of
the CryptoDev over a year ago. Unfortunately, we did not got a chance to pick
up again. In that process, Herbert Xu provides a number of comments. You can
searc
tx);
> };
I'd like to see a name field. It's better to have user-space
pass through a string for the type instead of an ID.
The reason you want user-space to pass that through is so that
you can locate the crypto_type object and then call crypto_alloc_tfm
on it..
[Loc Ho]
The name fi
Hi,
Sorry for the late response... See inline...
-Loc
-Original Message-
From: Pierre Habouzit [mailto:madco...@debian.org]
Sent: Saturday, January 31, 2009 2:35 PM
To: Loc Ho
Cc: Herbert Xu; linux-crypto@vger.kernel.org
Subject: Re: [RFC] MPI module
On Fri, Jan 30, 2009 at 06:54:16PM
l still be
handled
by CryptoDev driver. This avoids creating a bunch of complication for each type
of
CryptoAPI type of algorithms.
-Loc
-Original Message-
From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
Sent: Tuesday, January 27, 2009 8:47 PM
To: Shasi Pulijala
Cc: Loc Ho
Subject: R
Hi,
I would like to add that you can even handle the TLS/DTLS/SSL packet formation
in the kernel as well if you provide an algorithms that does just that. Right
now, most user just use the kernel for the hashing and cipher parts. There is
no reason that the current framework cannot handle proce
ctions) will return immediately (with
>-EINPROGRESS return value in case of HIFN driver for example),
>but your code will wait for request completion at
>wait_for_completion_interruptible() point.
[Loc Ho]
Yes... This is the exact behavior that we wanted for synchronous user space
applica
Hi Evgenly,
See inline...
-Original Message-
From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2008 2:08 PM
To: Shasi Pulijala
Cc: Herbert Xu; linux-crypto@vger.kernel.org; Loc Ho
Subject: Re: [PATCH 1/1 v7] Add Crypto API User Interface Support
Hi.
On Fri
Hi,
>
>You do not need to pass multiple pointers, but instead a multiple data.
>You can do that via single area provided to the kernel and multiple size
>fields, where each
> one corresponds to the size of the contiguous sectors in the provided data.
[Loc Ho]
It sounds like the
08, 2008 2:10 PM
To: Shasi Pulijala
Cc: linux-crypto@vger.kernel.org; Loc Ho
Subject: Re: OpenSSL patch to support Linux CryptoAPI.
Hi.
On Fri, Aug 08, 2008 at 11:31:58AM -0700, Shasi Pulijala ([EMAIL PROTECTED])
wrote:
> struct crypt_op {
> - u_int32_t ses;
> - u_int16_t
Hi,
>
>What does prevent from simultaneous command execution? Or setkey() vs.
>run() race? Do you rely on BKL which 'guards' ioctl execution? How is
>->write() protected from ioctl()?
>
We wasn't plan on protecting this. It is the caller responsibity to call in the
proper order. If the caller wa
version.
Signed-off-by: Shasi Pulijala <[EMAIL PROTECTED]>
Acked-by: Loc Ho <[EMAIL PROTECTED]>
---
crypto/Kconfig|8 +
crypto/Makefile |2 +
crypto/cryptodev.c| 1833 +
include/linux/cryptodev.h | 85
here is no 'aio_read', 'write', and 'read' functions.
This would allow striaght map to the current implementation.
-Loc
-Original Message-----
From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2008 5:01 AM
To: Loc Ho
Cc: Herbert Xu; linux
call
Signed-off-by: Shasi Pulijala <[EMAIL PROTECTED]>
Acked-by: Loc Ho <[EMAIL PROTECTED]>
---
crypto/Kconfig|7 +
crypto/Makefile |1 +
crypto/cryptodev.c| 1293
+
include/linux/cryptodev.h | 74
PROTECTED]
Sent: Monday, May 19, 2008 9:01 PM
To: Loc Ho
Cc: Evgeniy Polyakov; Sebastian Siewior; Shasi Pulijala;
linux-crypto@vger.kernel.org
Subject: Re: Linux CryptoAPI Userspace API proposal
On Thu, May 15, 2008 at 01:16:03PM -0700, Loc Ho wrote:
>
> Linux Crypto User Space Int
Hi,
See inline...
-Original Message-
From: Herbert Xu [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 29, 2008 12:02 AM
To: Loc Ho
Cc: linux-crypto@vger.kernel.org
Subject: Re: IPSec ESP Authenc Offload
On Wed, May 28, 2008 at 04:02:11PM -0700, Loc Ho wrote:
>>
>> It doesn&
en if the hardware rewrites the SPI and SEQ again, it is all
handled by hardware offload and will not be a problem for IPSEC ESP.
-Loc
-Original Message-
From: Herbert Xu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2008 3:23 PM
To: Loc Ho
Cc: linux-crypto@vger.kernel.org
Subjec
008 11:35 PM
To: Loc Ho
Cc: linux-crypto@vger.kernel.org
Subject: Re: IPSec ESP Authenc Offload
On Tue, May 27, 2008 at 11:29:22AM -0700, Loc Ho wrote:
>
> For authenc hardware offload outbound, we need to know the whole ESP
> header length - IP header + UDP header + ESP header + IV. I
Hi Herbert,
For authenc hardware offload outbound, we need to know the whole ESP
header length - IP header + UDP header + ESP header + IV. I am thinking
adding a field in struct aead_givcrypt_request as below:
/**
* struct aead_givcrypt_request - AEAD request with IV generation
* @seq
Hi,
Linux Crypto User Space Interface Requirement:
1. Support crypto and hashing/digest
2. Flexible to support compression in the future
3. Flexible to support PKA (public key acceleration) in the future
4. A file descriptor per algorithms
5. Key and algorithm attributes provided by user space ap
Hi,
We here would like to create an user space interface that can be
accepted into Linux CryptoAPI. Therefore, let me summary the current
suggestion:
Option #1:
1. Use file descriptor named '/dev/crypto' or use syscall
2. Each opened file creates a new 'crypto' context that represents a
crypto al
Hi,
Yes... It is intended not to patch OpenSSL twice. Besides the interface
API, the internal does NOT resemble OCF in anyway.
-Loc
-Original Message-
From: Herbert Xu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 14, 2008 4:03 AM
To: Sebastian Siewior
Cc: Loc Ho; Shasi Pulijala
Hi Herbert,
I am re-sending this email as I don't believe it got to the mailing
list. Due to email problem, I am forward this patch on behalf of Shasi
Pulijala who worked on this user space interface for Linux CryptoAPI.
This should add support for OpenSSL. Please note that user of this patch
must
Hi,
Patch 2/3 attached. I still can't get the line wrap problem solved.
Therefore it is attached instead inline.
-Loc
0002-CRYPTO-cryptd-Add-asynchronous-hash-support.patch
Description: 0002-CRYPTO-cryptd-Add-asynchronous-hash-support.patch
Hi,
Patch 3/3 attached. I still can't get the line wrap problem solved.
Therefore it is attached instead inline.
-Loc
0003-CRYPTO-tcrypt-Add-asynchronous-hash-support.patch
Description: 0003-CRYPTO-tcrypt-Add-asynchronous-hash-support.patch
_init_ahash_ops - This would be an error check for digest if some
caller called setkey function for digest algorithm.
-Loc
-Original Message-
From: Herbert Xu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 07, 2008 6:01 AM
To: Loc Ho
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH
Hi,
I am trying to test AES-CCM mode via IPSec. Setkey doesn't seem to support
"aes-ccm" mode. Anyone try this yet? Or should I checkout OpenSwan or
racoon?
-Loc
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordom
Hi Herbert,
I just want to check on the status of Linux NETKEY change to support
asynchronous Linux CryptoAPI interface. Have ESP, AH, and AEAD changes to
make use of async API?
In addition, I submitted async HASH and DIGEST patch over a week ago. Any
comments and whether it will be accepted?
Th
Add asynchronous digest support using asynchronous hash interface.
---
crypto/ahash.c|9 -
crypto/api.c |9 +++-
crypto/digest.c | 83
-
crypto/internal.h |1 +
crypto/tcrypt.c
>From e5d67c3670f1ec15339a92cc291027c0a059aaed Mon Sep 17 00:00:00 2001
From: Loc Ho <[EMAIL PROTECTED]>
Date: Thu, 24 Jan 2008 18:13:28 -0800
Subject: [PATCH] Add Async Hash Support
---
crypto/Makefile |1 +
crypto/ahash.c| 151
Hi,
I have a working version of async hash support. It is attached. This follows
ablkciper implementation.
It looks like crypto async dispatch to kernel thread isn't been use anymore
(cryptd.c). Am I correct?
Is there a particular format for submitting patch?
-Loc
cryptodev_ahash.patch
Des
ace.
-Loc
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Siewior
Sent: Tuesday, January 22, 2008 3:18 PM
To: Loc Ho
Cc: 'Sebastian Siewior'; Herbert Xu; linux-crypto@vger.kernel.org
Subject: Re: New Crypto Hardware
* Loc Ho | 2008-0
called, then it
is hash.
-Loc
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Siewior
Sent: Friday, January 18, 2008 3:07 PM
To: Loc Ho
Cc: Herbert Xu; linux-crypto@vger.kernel.org
Subject: Re: New Crypto Hardware
* Loc Ho | 2008-01-17 13:25:38
o the request
just like ablkcipher.
-Loc
-Original Message-
From: Herbert Xu [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 3:23 AM
To: Loc Ho
Cc: linux-crypto@vger.kernel.org
Subject: Re: New Crypto Hardware
On Wed, Jan 16, 2008 at 10:19:04AM -0800, Loc Ho wrote:
> Hi,
Hi,
I am about to start developing a new device driver for new crypto hardware.
I am thinking of starting with Linux CryptoAPI interface. But I have the
following requirement:
1. Asynchronous encrypt/decrypt
2. Asynchronous hashing
3. Asynchronous combined mode (GCM, CCM, and GMAC) 4.
Asynchronou
35 matches
Mail list logo
