As already mentioned programming SSEn+1 is not self-goal, all-round
performance is. The only thing that can make me consider SSE2 at this
point is performance numbers from Core2, which would be not worse than
say 16 cycles per byte, preferably with 256B table. So could you
*please* find
Could you also collect and submit results for say 512 blocks?
With a small change in the enrolled version, (bswap-load four
source bytes at once and extract each with a =8), the results
have slightly changed. (Though the results were taken form a
x1000 test loop, running 100 times with
Could you also collect and submit results for say 512 blocks?
512 8192 83378* 120096* 173951*98.3*68.2*47.1*
1024 16384 168677* 243279* 349622*97.1*67.3*46.9*
I.e. 20KB code, which is larger than I-cache, processes one byte in
32.5 cycles with 4KB table. OpenSSL
Blk Byte MXe µs MXu µs I32 µS MXe MB/s MXu MB/s I32 MB/s
¯¯¯ ¯¯¯ ¯¯¯ ¯¯¯
00 56 55 81
1 16 268 320 538 59.7 50.0 29.7
21 336473864398455*70.9 52.2 39.7
Could you also collect
- versions with SSE2/SSE3 support (if OPENSSL_ia32cap signals a valid
processor), reducing the number of asm instructions within a loop to
16 with a 4k table, and to 26 with a 256byte table (w/o: 34 and 62),
Are these numbers really per loop spin, i.e. per every 8 and 4 bits
respectively, or
.ibm.com
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2162] Updated CMAC, CCM, GCM code
This is an update to the sources (only) for the CMAC, CCM and GCM code we
donated previously.
Just to denote that alternative GCM implementation is available now,
see http://cvs.openssl.org/rlog?f
On Wed, Mar 03, 2010, PMHager wrote:
- EVP support for the CTR128 modes *1) (AES and Camellia), as these
are required in the GCTR [SP800-38D] function of the GCM (instead of
a block-wise use of the ECB mode),
Andy has added EVP support for CTR128 already.
- redesign of the EVP
Hi,
Due to the complete missing of an optimization in the IBM proposal
I am currently working on a GCM version as well. My current work
includes:
- EVP support for the CTR128 modes *1) (AES and Camellia),
AES counter was recently added, see
http://cvs.openssl.org/chngview?cn=19314.
- EVP support for the CTR128 modes *1) (AES and Camellia), as these
are required in the GCTR [SP800-38D] function of the GCM (instead of
a block-wise use of the ECB mode),
Andy has added EVP support for CTR128 already.
Unfortunately, I do not have access to the CVS. So, as I had needed
On Wed, Mar 03, 2010, PMHager wrote:
I don't see why the existing EVP_CIPHER interface isn't suitable. You add a
new flag for GCM/CCM mode and pass or retrieve additional information via
standardized ctrls.
The difficulties I see are the restricted parameters at EVP_CipherInit_ex(),
On Wed, Mar 03, 2010 at 02:56:07PM +0100, Dr. Stephen Henson wrote:
I'm thinking here that we should have a standardised technique for handling
encrypt+mac which will also cover possible future needs.
As far as I can tell, there isn't even working support for plain old
MAC in the engine
In case you consider submitting assembler code there is couple of
requirements that has to be met. Inline assembler (or exotic intrinsics)
is not considered as viable option for MMX/SSE (or any code bigger than
couple of instructions), perlasm code is.
As it is available in the MSC,
This is an update to the sources (only) for the CMAC, CCM and GCM code we
donated previously.
Just to denote that alternative GCM implementation is available now,
see http://cvs.openssl.org/rlog?f=openssl/crypto/modes/gcm128.c. It's
initial version and interface is still subject to change.
Cc: openssl-dev@openssl.org
Subject: [openssl.org #2162] Updated CMAC, CCM, GCM code
[pwal...@au1.ibm.com - Thu Feb 04 12:08:40 2010]:
CMAC we have test failures on several platforms - looks like a real
bug but
I havn't had time to investigate in detail yet, again it could be the test
code
[pwal...@au1.ibm.com - Thu Feb 04 12:08:40 2010]:
CMAC we have test failures on several platforms - looks like a real
bug but
I havn't had time to investigate in detail yet, again it could be the test
code or the implementation.
I've reimplemented CMAC now in HEAD. It passes all the test
(See attached file: ibmupdate1.tgz)
This is an update to the sources (only) for the CMAC, CCM and GCM code we
donated previously.
It rolls up various bug fixes for those who need them collected in one
place, but isn't a full patch to OpenSSL.
Current status.
GCM appears solid now with a 96 bit
16 matches
Mail list logo
