Re: tcrypt: hmac test with keys blocksize fail
Adrian-Ken R??egsegger [EMAIL PROTECTED] wrote:
using the cryptodev-2.6 tree I noticed that the hmac tests that have
keys larger than blocksize for md5 and the various sha algorithms all
fail (tcrypt mode=10[0-5]). The other tests seem to pass just fine.
The issue seems to have come from commit
de224c309b5631bdaae3fcd6880cfb93b52f5a53.
I have tested 48c8949ea8460216783dd33640121187b9531b60 which does not
contain this bug. It's just before the various tcrypt-changes from
Sebastian Siewior.
Actually this just exposed an ancient bug in hmac. It relied
on the key to be in identity-mapped memory which has never been
guaranteed.
This patch fixes the problem for me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/hmac.c b/crypto/hmac.c
index b60c3c7..14c6351 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -57,14 +57,35 @@ static int hmac_setkey(struct crypto_hash *parent,
if (keylen bs) {
struct hash_desc desc;
struct scatterlist tmp;
+ int tmplen;
int err;
desc.tfm = tfm;
desc.flags = crypto_hash_get_flags(parent);
desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
- sg_init_one(tmp, inkey, keylen);
- err = crypto_hash_digest(desc, tmp, keylen, digest);
+ err = crypto_hash_init(desc);
+ if (err)
+ return err;
+
+ tmplen = bs * 2 + ds;
+ sg_init_one(tmp, ipad, tmplen);
+
+ for (; keylen tmplen; inkey += tmplen, keylen -= tmplen) {
+ memcpy(ipad, inkey, tmplen);
+ err = crypto_hash_update(desc, tmp, tmplen);
+ if (err)
+ return err;
+ }
+
+ if (keylen) {
+ memcpy(ipad, inkey, keylen);
+ err = crypto_hash_update(desc, tmp, keylen);
+ if (err)
+ return err;
+ }
+
+ err = crypto_hash_final(desc, digest);
if (err)
return err;
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcrypt: hmac test with keys blocksize fail
Herbert Xu wrote: Actually this just exposed an ancient bug in hmac. It relied on the key to be in identity-mapped memory which has never been guaranteed. This patch fixes the problem for me. I have tested the patch and it resolves the issue indeed. It also let's the same RIPEMD hmac tests (see my submitted patches) run correctly. Thanks alot! -Adrian -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] Desynchronizing dm-raid1
On Tue, 6 May 2008, Herbert Xu wrote: Mikulas Patocka [EMAIL PROTECTED] wrote: BTW: is it guaranteed for crypto functions that they read the source data only once? There is no such guarantee. Cheers, So we'll have to copy the sector to temporary space before encrypting it. I'll look at it. Mikulas -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -mm crypto] AES: x86_64 asm implementation optimization
Hi, On Sat, 2008-05-03 at 23:25 -0700, dean gaudet wrote: one of the more important details in evaluating these changes would be the family/model/stepping of the processors being microbenchmarked... could you folks include /proc/cpuinfo with the results? The file attached is /proc/cpuinfo of my testing machine. Best Regards, Huang Ying also -- please drop the #define for R16 to %rsp ... it obfuscates more than it helps anything. thanks -dean On Wed, 30 Apr 2008, Sebastian Siewior wrote: * Huang, Ying | 2008-04-25 11:11:17 [+0800]: Hi, Sebastian, Hi Huang, sorry for the delay. I changed the patches to group the read or write together instead of interleaving. Can you help me to test these new patches? The new patches is attached with the mail. The new results are attached. Best Regards, Huang Ying Sebastian processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz stepping: 2 cpu MHz : 2128.006 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 4259.15 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz stepping: 2 cpu MHz : 2128.006 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 4256.08 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Re: [PATCH -mm crypto] AES: x86_64 asm implementation optimization
Hi, Sebastian, On Wed, 2008-04-30 at 00:12 +0200, Sebastian Siewior wrote: * Huang, Ying | 2008-04-25 11:11:17 [+0800]: Hi, Sebastian, Hi Huang, sorry for the delay. I changed the patches to group the read or write together instead of interleaving. Can you help me to test these new patches? The new patches is attached with the mail. The new results are attached. It seems that the performance degradation between step4 to step5 is decreased. But the overall performance degradation between step0 to step7 is still about 5%. I also test the patches on Pentium 4 CPUs, and the performance decreased too. So I think this optimization is CPU micro-architecture dependent. While the dependency between instructions are reduced, more registers (at most 3) are saved/restored before/after encryption/decryption. If the CPU has no extra execution unit for newly independent instructions but more registers are saved/restored, the performance will decrease. We maybe should select different implementation based on micro-architecture. Best Regards, Huang Ying -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
