> Quoting Arun Murthy :
>
> > 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 th
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:
>
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
MV88F628
Quoting Arun Murthy :
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
Quoting Herbert Xu :
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/e
> -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
> S
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:
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
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 i
