On Tue, Mar 02, 2010 at 10:10:49PM +0800, Herbert Xu wrote:
>
> Hmm, I just noticed that both before and after the patch we're
> only including the hash request size for the encrypt case, and
> not the givencrypt case. Is there a reason for this?
>
Hm, for the moment I don't see what's missing.
Hi,
I am trying to write a hmac(sha1) algorithm and I have a few questions.
I have a HW crypto accelerator that does the actual crypto work. I have
already successfully implemented sha1 by creating a
CRYPTO_ALG_TYPE_DIGEST algorithm.
1) Can I implement hmac(sha1) as a CRYPTO_ALG_TYPE_DIGEST
Because ghash needs setkey, the setkey and keysize template support
for test_hash_speed is added.
v2:
- Move klen into struct hash_speed.
Signed-off-by: Huang Ying
---
crypto/tcrypt.c |7 +++
crypto/tcrypt.h | 29 +
2 files changed, 36 insertions(+)
---
Szilveszter Ordog wrote:
>> When we get an unaligned buffer, we first process the bit from the
>> start to the first aligned address. Once we get to the aligned
>> address everything happens as usual.
>>
>> So where this code is, we're trying to move to the next aligned
>> address, and as ALIGN r
> When we get an unaligned buffer, we first process the bit from the
> start to the first aligned address. Once we get to the aligned
> address everything happens as usual.
>
> So where this code is, we're trying to move to the next aligned
> address, and as ALIGN rounds down, we need to add align
On Tue, Feb 23, 2010 at 11:50:01AM +, Szilveszter Ordog wrote:
> The correct way to calculate the start of the aligned part of an
> unaligned buffer is:
>
> offset = ALIGN(offset, alignmask + 1);
>
> However, crypto_hash_walk_done() has:
>
> offset += alignmask - 1;
> offset = ALIGN(of
Uri Simchoni wrote:
> Hi,
>
> I'd like to add sha1/hmac-sha1 support to the Marvell CESA driver. I couldn't
> see an ahash driver that I can use as a reference. Is there such a driver?
We did have an implementation but it had to be removed because
it wasn't reentrant so it's not a good model fo
On Tue, Feb 23, 2010 at 07:22:37AM +0100, Steffen Klassert wrote:
>
> @@ -558,13 +556,18 @@ static int crypto_authenc_init_tfm(struct crypto_tfm
> *tfm)
> ctx->auth = auth;
> ctx->enc = enc;
>
> - tfm->crt_aead.reqsize = max_t(unsigned int,
> - crypto_
On Tue, Feb 23, 2010 at 07:21:09AM +0100, Steffen Klassert wrote:
> We accidentally assigned the ahash update complete function to
> the wrong function pointer in crypto_authenc_verify.
> This patch fixes this.
>
> Signed-off-by: Steffen Klassert
Patch applied. Thanks!
--
Visit Openswan at htt
On Mon, Feb 22, 2010 at 11:21:04AM +0800, Wang, Shane wrote:
>
> @@ -474,7 +475,10 @@ static u64 vmac(unsigned char m[], unsig
> }
> p = be64_to_cpup(out_p + i);
> h = vhash(m, mbytes, (u64 *)0, &ctx->__vmac_ctx);
> - return p + h;
> + r = p + h;
> + r = le64_to_cpup(&
>
> >> +#define ARRAY_PREVENT_DSE(p, n)
> >
> > Who says the Intel compiler doesn't need this?
>
> There was a comment in include/linux/compiler-intel.h that it's not supported.
That's true for the ia64 version, but not for the x86 version which supports
gcc compatible inline assembler. So on x
> > + do {\
> > + struct __scrub { typeof(*p) c[n]; };\
>
> The typeof(*p) suggestion doesn't work. It would require p to always be
> a pointer type with an accurate (for memset) sizeof(*p). In general however
> we'll memset some array de
On Mon, Mar 01, 2010 at 04:06:44PM +0800, Huang Ying wrote:
> Because ghash needs setkey, the setkey and keysize template support
> for test_hash_speed is added.
>
> Signed-off-by: Huang Ying
> ---
> crypto/tcrypt.c | 122
> +++-
> crypto/tcr
13 matches
Mail list logo
