Re: AES performance vs. security

2006-08-02 Thread Andy Polyakov

Latest development snapshot has updated AES x86 assember module,


As it turns out there is a breakage point. As you might have noticed the 
module expects S-box tables to be aligned with 1024 byte granularity. 
While it doesn't seem to be a problem to ensure such alignment on ELF 
platforms, others seem to fail to arrange it. For example a.out-based 
OpenBSD 3.2 allows you to specify up to 32K alignment, but it's 
apparently ignored somewhere, as it doesn't seem to have effect on 
symbol alignment in final executable. Win32 is complete mess. Microsoft 
PECOFF specification allows for alignment up to 8KB, but Microsoft 
assembler does not allow alignment statements over 256 bytes [even if I 
specify TEXT$ SEGMENT PAGE]. nasm refuses segment alignment larger than 
64 bytes claiming that the specification does not allow for more. yasm 
seem to be the only one doing right thing, and good news is that even 
elder Microsoft linker, version 6 to be specific, respects the alignment 
specified by yasm and the table turns out properly aligned in final 
executable. Cygwin and Mingw binutils don't seem to be helpful at all 
silently assuming 16 byte alignment on everything. Well, they use align 
statement for padding, but not for actual alignment. Bottom line, some 
further consideration and work is required... A.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]


AES performance vs. security

2006-08-01 Thread Andy Polyakov
Latest development snapshot has updated AES x86 assember module, which 
trades performance for security for all encryption modes, but CBC. 
Encrypt performance is about 1/2 original assembler and decrypt - about 
1/3. Note that you won't notice performance degradation in 'openssl 
speed aes' output, use 'openssl speed -evp aes-128-ecb [-decrypt]' to 
benchmark new code. CBC procedure needs further work and shall switch to 
slower block routine when asked to process smaller amount of data or 
when executed on hyper-threading CPU. Detecting hyper-threading CPU 
presents a challenge as it can't be done by looking at CPUID output. One 
can identify HT-capable P4, but not if it's actually hyper-threading. 
I'm open for suggestions... A.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]