>> It seems that the padlock engine does something wrong for >> aes192 and aes256. Things work perfectly with aes128. >> >> If I use "openssl enc -aes256 -nosalt" to encrypt something >> it generates something different with and without the padlock >> engine loaded. >> >> Also, when the padlock engine is loaded, it can't decrypt >> anything with aes192 and aes256. >> >> This is using 0.9.8o, but I have every reason to believe >> 1.0.0g has the same problem. > > So I looked closer at this, and the problem is that the padlock > engine depends on the define AES_ASM changing the 192 and 256 > versions. It needs to do a byteswap for those.
Right. > In Debian we ship several versions of the shared libraries on i386. > One that's build the default instruction set of that architecture > (which is still i486 I think), and then 2 optimised versions, > one for 586 and one for 686. The 586 and 686 versions use the > assembler and so have AES_ASM defined. The dynamic linker picks > the proper shared library depending on the CPU. Why don't you compile assembler even in "default instruction set" build? Even though modules are called 586, they run even on 486 (and can be compiled for 386). 586 is merely a reference to the way instructions were scheduled at some point in time, now it effectively lost the meaning. Moreover, I'd argue that single assembler build is sufficient, because a) assembler code detects processor it executes on; b) potential performance losses/improvements resulting from targeting 586 or 686 are realtively small. It would be viable strategy to target 486, but instruct compiler to schedule instructions for 586. This is because instruction ordering doesn't matter on 486, while post-586 cores, being out-of-order, are capable of executing "586" code efficiently enough. > The engines that are shipped are for the default instruction set, > else I would need to ship those several times too, and I saw no > reason for this so far. > > So we ended up with a 686 shared library loaded (with AES_ASM > defined), and the padlock engine loaded that doesn't have it > defined, which of course means that they're not compatible > with each other. > > As far as I understand things, the padlock extention is only > available on 686 processors. What is 686 processor? One defined by -march=i686 gcc option? VIA C7 and Nano surely falls to this category, but I've never seen C3... > So I'll probably patch the padlock > engine to always have AES_ASM defined in Debian. Or compile even "486" build with assembler. It's really more appropriate. > PS: #2728 is about the same issue. Thanks. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
