> Hi, > > 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. 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. 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. So I'll probably patch the padlock engine to always have AES_ASM defined in Debian. PS: #2728 is about the same issue. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
