Hi ,
Since openssl.1.0.1c doesn't support ECDHE-ECDSA-AES128-CCM cipher suite,
I added this support in the openssl code.
It works fine with ECC certificates which are not self-signed.
When I process my ECC self-signed certificate, my webserver throughing X5*
Hi ,
If there are no v3 extensions in the certificate, verify goes fine ,
If I add keyUsage , I get the below error .
*X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE*
But as per standard which I have follow for certficate generation , I have
to create the certificate with these extensions .
is
Hello,
I apologise if this is the wrong list.
I have cross compiled openssl to ARM (using gcc-4.6 on Ubuntu) - both
versions 0.9.8y and versions 1.0.1e. When using objdump to view the result,
I see that sha512_block_data_order takes ~3k (2744 in 0.9.8y, and 3464 in
1.0.1e) of stack space.
Since
After digging deeper I realized that the |Sha1_Update()| crypto function
zeroes the registers.
More specifically - the code zeroing the registers is in
the |HASH_BLOCK_DATA_ORDER| macro (translated
to |sha1_block_data_order_avx()| function):
sha1_block_data_order_avx()
movaps xmmword
Mike Inman via RT wrote:
crypto/bn/asm/x86_64-gf2m.pl was not finishing code generation before the
assembler started, resulting in errors that looked like:
set ASM=ml64 /c /Cp /Cx /Zi
perl crypto\bn\asm\x86_64-gf2m.pl tmp32\x86_64-gf2m.asm
ml64 /c /Cp /Cx /Zi
I did a quick test, and found that 'make test' succeeds for -O0, -O1,
-Os, and -Oz, but fails for -O2 and -O3. This is using Apple's cc
which is based on clang-3.3 (it describes itself as clang-500.1.58
based on LLVM 3.3svn) and openssl-1.0.1e.
It fails in the NIST test vectors stage of
