GCM counter inc
Hi According to the GCM NIST publication, the counter increment should be module 32 bit. Looking into the crypto code, I can see that when using gcm(aes) the gcm will use the ctr over aes, ctr.c is using the crypto_inc with size of blocksize, which is 16 for AES. in case crypto_inc will overflow in 32bit it will inc the next 32bit... Is this a bug or am I missing something? Regards -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Generic crypto counters
On Fri, Jun 15, 2012 at 09:14:33AM +0200, Jan Glauber wrote: Simple counters for the number of processed bytes per algorithm is something which I wanted to have for some time now. The reason is that its not obvious to tell if the hardware or software implementation was used. The only way to determine this currently is to look at the speed of the operation or add debug output, both methods kind of suck. You can query /proc/crypto and look at the ref count to see which algorithm is in use. However, I'm certainly not against having usage counters since they would be quite useful in their own right. BTW, we now have a user- space interface in crypto/crypto_user.c. So when you add stuff to /proc/crypto please consider adding it to crypto_user as well. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: tcrypt - Add mode 500 for ablkcipher test
The existing mode 200 performs ecb(aes), cbc(aes), ctr(aes), ecb(des), cbc(des)
ecb(des3_ede), cbc(des3_ede) for synchronous block cihper. For crypto hardware
drivers ablkcipher's are used and hence add new mode 500 and its variants to
perform the tests in asynchronous block cipher.
Signed-off-by: Arun Murthy arun.mur...@stericsson.com
Signed-off-by: Berne Hebark berne.heb...@stericsson.com
Acked-by: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
crypto/tcrypt.c | 265 +++
1 files changed, 249 insertions(+), 16 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 617..75f0747 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -67,6 +67,87 @@ static char *check[] = {
lzo, cts, zlib, NULL
};
+struct tcrypt_result {
+ struct completion completion;
+ int err;
+};
+
+static int test_ablkcipher_jiffies(struct ablkcipher_request *req, int enc,
+ int blen, int sec)
+{
+ unsigned long start, end;
+ int bcount;
+ int ret;
+
+ for (start = jiffies, end = start + sec * HZ, bcount = 0;
+time_before(jiffies, end); bcount++) {
+ if (enc)
+ ret = crypto_ablkcipher_encrypt(req);
+ else
+ ret = crypto_ablkcipher_decrypt(req);
+
+ if (ret) {
+ printk(\n [test_cipher_jiffies]
+ crypto_ablkcipher_encrypt/decrypt: enc: %d,
+ ret = %x \n, enc, ret);
+ return ret;
+ }
+ }
+
+ printk(%d operations in %d seconds (%ld bytes)\n,
+ bcount, sec, (long)bcount * blen);
+ return 0;
+}
+
+static int test_ablkcipher_cycles(struct ablkcipher_request *req,
+ int enc, int blen)
+{
+ unsigned long cycles = 0;
+ int ret = 0;
+ int i;
+
+ local_bh_disable();
+ local_irq_disable();
+
+ /* Warm-up run. */
+ for (i = 0; i 4; i++) {
+ if (enc)
+ ret = crypto_ablkcipher_encrypt(req);
+ else
+ ret = crypto_ablkcipher_decrypt(req);
+
+ if (ret)
+ goto out;
+ }
+
+ /* The real thing. */
+ for (i = 0; i 8; i++) {
+ cycles_t start, end;
+
+ start = get_cycles();
+ if (enc)
+ ret = crypto_ablkcipher_encrypt(req);
+ else
+ ret = crypto_ablkcipher_decrypt(req);
+ end = get_cycles();
+
+ if (ret)
+ goto out;
+
+ cycles += end - start;
+ }
+
+out:
+ local_irq_enable();
+ local_bh_enable();
+
+ if (ret == 0)
+ printk(1 operation in %lu cycles (%d bytes)\n,
+ (cycles + 4) / 8, blen);
+
+ return ret;
+}
+
static int test_cipher_jiffies(struct blkcipher_desc *desc, int enc,
struct scatterlist *sg, int blen, int sec)
{
@@ -139,8 +220,130 @@ out:
return ret;
}
+static u32 ablock_sizes[] = { 16, 32, 64, 128, 256, 512, 1024, 2048, 4096,
8192, 16384, 24576, 0 };
static u32 block_sizes[] = { 16, 64, 256, 1024, 8192, 0 };
+static void tcrypt_complete(struct crypto_async_request *req, int err)
+{
+ struct tcrypt_result *res = req-data;
+
+ if (err == -EINPROGRESS)
+ return;
+
+ res-err = err;
+ complete(res-completion);
+}
+
+static void test_ablkcipher_speed(const char *algo, int enc, unsigned int sec,
+ struct cipher_speed_template *template,
+ unsigned int tcount, u8 *keysize)
+{
+ unsigned int ret, i, j, iv_len;
+ const char *key;
+ char iv[128];
+ const char *e;
+ u32 *b_size;
+ struct tcrypt_result result;
+ struct crypto_ablkcipher *tfm;
+ struct ablkcipher_request *req;
+
+ if (enc == ENCRYPT)
+ e = encryption;
+ else
+ e = decryption;
+
+ printk(\ntesting speed of %s %s\n, algo, e);
+ init_completion(result.completion);
+
+ tfm = crypto_alloc_ablkcipher(algo, 0, 0);
+ if (IS_ERR(tfm)) {
+ printk(failed to load transform for %s: %ld\n, algo,
+ PTR_ERR(tfm));
+ return;
+ }
+ req = ablkcipher_request_alloc(tfm, GFP_KERNEL);
+ if (!req) {
+ printk(KERN_ERR alg: cipher_speed: Failed to allocate request
+ for %s\n, algo);
+ return;
+ }
+
+ ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ tcrypt_complete, result);
+
+ i = 0;
+ do {
+
+ b_size =
RE: [PATCH] crypto: tcrypt - Add mode 500 for ablkcipher test
-Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- ow...@vger.kernel.org] On Behalf Of Arun Murthy Sent: Wednesday, June 20, 2012 2:12 PM To: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au Cc: arun.mur...@stericsson.com; Berne Hebark Subject: [PATCH] crypto: tcrypt - Add mode 500 for ablkcipher test The existing mode 200 performs ecb(aes), cbc(aes), ctr(aes), ecb(des), cbc(des) ecb(des3_ede), cbc(des3_ede) for synchronous block cihper. For crypto hardware drivers ablkcipher's are used and hence add new mode 500 and its variants to perform the tests in asynchronous block cipher. Signed-off-by: Arun Murthy arun.mur...@stericsson.com Signed-off-by: Berne Hebark berne.heb...@stericsson.com Acked-by: Srinidhi Kasagar srinidhi.kasa...@stericsson.com Acked-by: Linus Walleij linus.wall...@linaro.org --- You are using a deprecated tree (github ?). Current crypto is located at git.kernel.org Horia -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: aes - make assembler implementation default for i386 and x86-64
Quoting Herbert Xu herb...@gondor.apana.org.au: On Tue, Jun 12, 2012 at 09:25:18PM +0300, Jussi Kivilinna wrote: Well, how about letting arch specific assembler implementations replace aes-generic completely.. in this case add depends on !X86 on CRYPTO_AES_GENERIC. Hardware modules get autoloaded (cpuid/pci/platform/etc) but generic assembler implementation might as well be replacement as it cannot autoload depending on hardware support (or it can, but will be always loaded). Perhaps we can just force a modprobe of a given algorithm at least once for each boot (when requested for the first time). I think that should be easy to implement and should solve your problem scenario. What do you think? Well, that could work. -Jussi Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: tcrypt - Add mode 500 for ablkcipher test
Quoting Arun Murthy arun.mur...@stericsson.com: The existing mode 200 performs ecb(aes), cbc(aes), ctr(aes), ecb(des), cbc(des) ecb(des3_ede), cbc(des3_ede) for synchronous block cihper. For crypto hardware drivers ablkcipher's are used and hence add new mode 500 and its variants to perform the tests in asynchronous block cipher. Signed-off-by: Arun Murthy arun.mur...@stericsson.com Signed-off-by: Berne Hebark berne.heb...@stericsson.com Acked-by: Srinidhi Kasagar srinidhi.kasa...@stericsson.com Acked-by: Linus Walleij linus.wall...@linaro.org Which tree are you using? Commit 3f3baf359dd3cc56fbaf9a2fb1a425ce7c18dbff added async cipher speed tests for v3.3. -Jussi -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA
Hi Phil On 2012-6-19 4:12, Simon Baatz wrote: I see one effect that I don't fully understand. Similar to the previous implementation, the system is mostly in kernel space when accessing an encrypted dm-crypt device: Today I also compiled the patched 3.5.0-rc3 for another NAS box with MV88F6282-Rev-A0 (LS-WVL), I noticed one thing that when the CESA engine was used, the interrupt number of mv_crypto kept rising, but the interrupt number of mv_tdma was always zero. $ cat /proc/interrupts CPU0 1: 31296 orion_irq orion_tick 5: 2 orion_irq mv_xor.0 6: 2 orion_irq mv_xor.1 7: 2 orion_irq mv_xor.2 8: 2 orion_irq mv_xor.3 11: 23763 orion_irq eth0 19: 0 orion_irq ehci_hcd:usb1 21: 4696 orion_irq sata_mv 22: 64907 orion_irq mv_crypto 33:432 orion_irq serial 46: 51 orion_irq mv643xx_eth 49: 0 orion_irq mv_tdma 53: 0 orion_irq rtc-mv 107: 0 - GPIO fan alarm 109: 0 - function 110: 0 - power-on 111: 0 - power-auto Err: 0 Is this normal? Regards Cloudy -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA
Hi Cloudy, On Wed, Jun 20, 2012 at 09:31:10PM +0800, cloudy.linux wrote: On 2012-6-19 4:12, Simon Baatz wrote: I see one effect that I don't fully understand. Similar to the previous implementation, the system is mostly in kernel space when accessing an encrypted dm-crypt device: Today I also compiled the patched 3.5.0-rc3 for another NAS box with MV88F6282-Rev-A0 (LS-WVL), I noticed one thing that when the CESA engine was used, the interrupt number of mv_crypto kept rising, but the interrupt number of mv_tdma was always zero. Yes, that is exactly how it should be: the DMA engine is configured to run attached to CESA, meaning that when CESA is triggered from mv_cesa.c, it first enables the DMA engine. Using a special descriptor in the chain, the DMA engine knows when to stop and signals CESA again so it can start the crypto operation. Afterwards, CESA triggers the DMA engine again for copying back the results (or more specific: process the remaining descriptors in the chain after the special one). After a descriptor with it's next descriptor field being zero has been handled, CESA is signaled again which in turn generates the interrupt to signal the software. So no DMA interrupt needed, and no software interaction in between data copying and crypto operation, of course. :) Greetings, Phil PS: I am currently working at the address decoding problem, will get back to in a few days when I have something to test. So stay tuned! Phil Sutter Software Engineer -- Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49-6721-49030-0 Direct line/Durchwahl: +49-6721-49030-134 Fax:+49-6721-49030-209 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein Commercial register/Handelsregister: Amtsgericht Mainz HRB40380 CEO/Geschäftsführer: Simon Kissel -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] crypto: tcrypt - Add mode 500 for ablkcipher test
Quoting Arun Murthy arun.mur...@stericsson.com: The existing mode 200 performs ecb(aes), cbc(aes), ctr(aes), ecb(des), cbc(des) ecb(des3_ede), cbc(des3_ede) for synchronous block cihper. For crypto hardware drivers ablkcipher's are used and hence add new mode 500 and its variants to perform the tests in asynchronous block cipher. Signed-off-by: Arun Murthy arun.mur...@stericsson.com Signed-off-by: Berne Hebark berne.heb...@stericsson.com Acked-by: Srinidhi Kasagar srinidhi.kasa...@stericsson.com Acked-by: Linus Walleij linus.wall...@linaro.org Which tree are you using? Commit 3f3baf359dd3cc56fbaf9a2fb1a425ce7c18dbff added async cipher speed tests for v3.3. Sorry for spamming, unknowingly I was working on a different branch. Thanks and Regards, Arun R Murthy - -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
