On Mon, Jun 29, 2009 at 03:52:57PM +0200, Steffen Klassert wrote:
On Mon, Jun 29, 2009 at 07:59:50PM +0800, Herbert Xu wrote:
OK. Can you send me the patches you used against the current
cryptodev tree (I only just pushed so give it an hour or so)?
I'll see if I can reproduce it here.
On Thu, Jun 25, 2009 at 02:51:12PM +0800, Herbert Xu wrote:
OK, the patch I just posted to the list should fix the problem.
I was able to test it suing
modprobe tcrypt alg='pcrypt(authenc(hmac(sha1-generic),cbc(aes-generic)))'
type=3
I applied your patch on top of the last pcrypt
On Mon, Jun 08, 2009 at 08:45:18AM +0200, Steffen Klassert wrote:
Yes, I will send the full patchset including the tcrypt changes to
instantiate pcrypt.
OK, the patch I just posted to the list should fix the problem.
I was able to test it suing
modprobe tcrypt
On Mon, Jun 08, 2009 at 03:28:08PM +1000, Herbert Xu wrote:
On Fri, Jun 05, 2009 at 11:34:30AM +0200, Steffen Klassert wrote:
In pcrypt_alloc_instance() I do
inst-alg.cra_priority = alg-cra_priority + 100;
So, in my case authenc has priority 2000 and pcrypt has priority 2100.
In this
On Fri, Jun 05, 2009 at 11:34:30AM +0200, Steffen Klassert wrote:
In pcrypt_alloc_instance() I do
inst-alg.cra_priority = alg-cra_priority + 100;
So, in my case authenc has priority 2000 and pcrypt has priority 2100.
In this case pcrypt is not instantiated if I use %s for pcrypt as
On Wed, Jun 03, 2009 at 09:59:31PM +1000, Herbert Xu wrote:
When pcrypt instantiates an algorithm, it should set cra_name to
%s and cra_driver_name to pcrypt(%s). So as long as the pcrypt
priority is higher than the underlying algorithm, it should all
work.
As it is, I can instantiate
On Fri, Jun 05, 2009 at 11:20:30AM +0200, Steffen Klassert wrote:
As it is, I can instantiate pcrypt if the priority of pcrypt is lower
than the priority of the underlying algorithm. If I do the priority
check in crypto_alg_tested() the other way arround, I get it to work if
pcrypt has a
On Tue, Jun 02, 2009 at 07:28:15PM +1000, Herbert Xu wrote:
On Tue, Jun 02, 2009 at 11:21:51AM +0200, Steffen Klassert wrote:
The reason for the wrap work is to have a possibility to choose a
certain version of an algorithm as the system default. The advantage
e.g. for pcrypt is that we
On Wed, Jun 03, 2009 at 07:40:50PM +1000, Herbert Xu wrote:
I see. How about if we let tcrypt test algorithms by name, e.g.,
something like
modprobe tcrypt alg='pcrypt(authenc(hmac(sha1),cbc(aes))'
I'm not that sure whether this does what I want.
If pcrypt has cra_name =
On Wed, Jun 03, 2009 at 01:23:53PM +0200, Steffen Klassert wrote:
On Wed, Jun 03, 2009 at 07:40:50PM +1000, Herbert Xu wrote:
I see. How about if we let tcrypt test algorithms by name, e.g.,
something like
modprobe tcrypt alg='pcrypt(authenc(hmac(sha1),cbc(aes))'
I'm not
On Tue, Jun 02, 2009 at 01:50:41PM +1000, Herbert Xu wrote:
Hmm, it seems that this patch is completely intertwined into the
rest of the patches so we can't just kill it. Can you elaborate
on the rationale behind this wrap work? I'm curious to find out
what we gain by this over the much
On Tue, Jun 02, 2009 at 11:21:51AM +0200, Steffen Klassert wrote:
The reason for the wrap work is to have a possibility to choose a
certain version of an algorithm as the system default. The advantage
e.g. for pcrypt is that we can turn over the whole system to pcrypt,
or we can choose for
On Wed, May 13, 2009 at 03:08:18PM +0200, Steffen Klassert wrote:
This patch adds an interface to wrap aead algorithms with an
arbitrary crypto template. This is useful to make a certain
version of an aead algorithm the system default of that algorithm.
Signed-off-by: Steffen Klassert
13 matches
Mail list logo
