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
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
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.
-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
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
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
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
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
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
