[RFC][PATCH 4/4] AES assembler implementation for x86_64

[RFC][PATCH 4/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

The attached patch contains the required changes for the crypto Kconfig
to enable the usage of the x86_64 AES assembler implementation.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

[-- Attachment #2: aes-crypto.diff --]
[-- Type: text/plain, Size: 1572 bytes --]

diff -rNu linux-2.6.11.2.orig/crypto/Kconfig linux-2.6.11.2/crypto/Kconfig
--- linux-2.6.11.2.orig/crypto/Kconfig	2005-03-09 09:12:53.000000000 +0100
+++ linux-2.6.11.2/crypto/Kconfig	2005-04-17 13:10:51.000000000 +0200
@@ -133,7 +133,7 @@
 
 config CRYPTO_AES
 	tristate "AES cipher algorithms"
-	depends on CRYPTO && !(X86 && !X86_64)
+	depends on CRYPTO && !X86 && !X86_64
 	help
 	  AES cipher algorithms (FIPS-197). AES uses the Rijndael 
 	  algorithm.
@@ -153,7 +153,27 @@
 
 config CRYPTO_AES_586
 	tristate "AES cipher algorithms (i586)"
-	depends on CRYPTO && (X86 && !X86_64)
+	depends on CRYPTO && X86 && !X86_64
+	help
+	  AES cipher algorithms (FIPS-197). AES uses the Rijndael 
+	  algorithm.
+
+	  Rijndael appears to be consistently a very good performer in
+	  both hardware and software across a wide range of computing 
+	  environments regardless of its use in feedback or non-feedback 
+	  modes. Its key setup time is excellent, and its key agility is 
+	  good. Rijndael's very low memory requirements make it very well 
+	  suited for restricted-space environments, in which it also 
+	  demonstrates excellent performance. Rijndael's operations are 
+	  among the easiest to defend against power and timing attacks.	
+
+	  The AES specifies three key sizes: 128, 192 and 256 bits	  
+
+	  See <http://csrc.nist.gov/encryption/aes/> for more information.
+
+config CRYPTO_AES_X86_64
+	tristate "AES cipher algorithms (x86_64)"
+	depends on CRYPTO && X86 && X86_64
 	help
 	  AES cipher algorithms (FIPS-197). AES uses the Rijndael 
 	  algorithm.

Re: [RFC][PATCH 4/4] AES assembler implementation for x86_64

[Adrian Bunk]

On Sun, Apr 17, 2005 at 09:20:21PM +0200, Andreas Steinmetz wrote:

> The attached patch contains the required changes for the crypto Kconfig
> to enable the usage of the x86_64 AES assembler implementation.


That is not specifically against this patch, but before we add another 
AES implementation, I'd like to find a better solution for the general 
AES selection.

My original thoughts on this issue are in [1], but this didn't attack 
the problem of CRYPTO_DEV_PADLOCK_AES where it might not be known at 
compile time whether the hardware will be present.


> Andreas Steinmetz

> diff -rNu linux-2.6.11.2.orig/crypto/Kconfig linux-2.6.11.2/crypto/Kconfig
> --- linux-2.6.11.2.orig/crypto/Kconfig	2005-03-09 09:12:53.000000000 +0100
> +++ linux-2.6.11.2/crypto/Kconfig	2005-04-17 13:10:51.000000000 +0200
>...
>  config CRYPTO_AES_586
>  	tristate "AES cipher algorithms (i586)"
> -	depends on CRYPTO && (X86 && !X86_64)
> +	depends on CRYPTO && X86 && !X86_64
>...

This doesn't make any difference.

I think the former version was better readable, but that's no strong 
opinion.

cu
Adrian

[1] http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [RFC][PATCH 4/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

Adrian Bunk wrote:
> That is not specifically against this patch, but before we add another 
> AES implementation, I'd like to find a better solution for the general 
> AES selection.

That would be nice as I didn't like having to duplicate a whole Kconfig
entry which in fact means that it is triplicated now.
I'm fine with any solution here but I do believe whatever solution is
for the crypto maintainers to decide.

[snip]

>>+	depends on CRYPTO && (X86 && !X86_64)
>>+	depends on CRYPTO && X86 && !X86_64
>>...
> 
> 
> This doesn't make any difference.
> 
> I think the former version was better readable, but that's no strong 
> opinion.

This was only personal preference during development and actually you're
right, the former version is better readable.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de