If your intention is performance optimization you could even replace
if((*p 0x80) == 0)
with
if((signed char)(*p) = 0)
as you cannot assume that all compilers will do it correctly themselves.
-Original Message-
From: owner-openssl-...@openssl.org
Could you please count the 1-bits in each exponent (e and d).
This might give an explanation.
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of
Georgi Guninski
Sent: Sunday, August 29, 2010 10:51 AM
To: openssl-dev@openssl.org
Neither EVP_PKEY_CTX_new_id() nor EVP_PKEY_keygen_init()
do initialize the EVP_PKEY_CTX member pkey_gencb. (It might
be, other initialisers like EVP_PKEY_new() behave similar.)
As default, the callback should be disabled. In either of
the functions, preferably EVP_PKEY_CTX_new_id(),
At [http://carnivore.it/2010/03/30/openssl_1.0_benchmark] there is a
comparison chart between 0.9.8g and 1.0.0 where most AES results are
even slower now.
__
OpenSSL Project
Though I am not a member of the OpenSSL team, I totally agree with you.
As for the AES, the Westmere CPUs have also a new instruction for the
GHASH (pclmulqdq / _mm_clmulepi64_si128). This as well is only available
as intrinsic or in native assembler.
So, when I offered some weeks ago a
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
Martin Boßlet wrote on March 05, 2010:
At first I thought the second implementation was wrong, but then again I read
the ITU
specification for DER encodings,
http://www.itu.int/rec/T-REC-X.690-200207-S/en.
The latest version is at: [http://www.itu.int/rec/T-REC-X.690-200811-I/en]
In
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), as these
are required in the GCTR [SP800-38D] function of the GCM (instead of
a block-wise
- 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
The doc/crypto/OPENSSL_ia32cap.pod documentation at
[http://www.openssl.org/docs/crypto/OPENSSL_ia32cap.html]
defines the return of OPENSSL_ia32cap_loc() as a pointer
to a (32-bit) integer with a feature (AES Instr.) available
if bit 57 is set.
Before 2009/09/13 /crypto/cryptlib.c did define
There is still a bug in cmac_test.c, though disabled with
#if defined(DES_WORKS)
...
The DES test vectors you are using are from the faulty SP800-38B.pdf
which has been corrected by the NIST in Updated_CMAC_Examples.pdf.
Fortunately, your cmac_test.c will work well on the DES cases with
the
BTW aadenc should be unsigned, otherwise VC generates a warning:
unsigned int aadenc = 2;
Peter-Michael
On Dec 20, 2009 at 10:55 PM, Peter Waltenberg wrote:
I'll post a full patch at some point - but in the interim.
This isn't so much a bug as something I forgot to go back and fix when I
12 matches
Mail list logo
