Re: The new subject hash algorithm
Hi Steve and Krzysztof, I have not been able to reproduce the same output as openssl. Can you be more specific how you achieved it? So x509_name_canon generates the CANONICAL representation of the subject name, right? If I understand correctly, after generating the canon encoding I would only have to pass it to EVP_Digest, correct? Exposing x509_name_canon() to x509_cmp.c first. unsigned long X509_NAME_hash(X509_NAME *x): x509_name_canon() EVP_Digest(x-canon_enc, x-canon_enclen, md, NULL, EVP_sha1(), NULL) -- View this message in context: http://openssl.6102.n7.nabble.com/The-new-subject-hash-algorithm-tp44844p46720.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3135] Not all items displayed by list-cipher-commands are in OBJ_sn2nid()
There are ciphers listed in the output of 'openssl list-cipher-commands' that are not listed in OBJ_sn2nid(), eg 'rmd160'. It would be Really Nice if the list of ciphers in OBJ_sn2nid() included these aliases as well. http://bugs.ntp.org/show_bug.cgi?id=2463 If there is a better way to handle this please let me know, and we're telling people that if you link with openssl, you can use any cipher listed by 'openssl list-cipher-commands' and for some of these aliases that's just not true and we're not finding another way to validate these aliases. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3136] [PATCH] get rid of extra space when printing -subject and -issuer in x509
Openssl behaves differently when printing subject or issuer from request
or from existing certificate in x509. If using x509 there is an extra
space after '=' character.
It can affect scripts that checks whether these fields in request and
certificate match. Moreover when printing serial, the in x509 there was
no extra space, so the behavior was kind of unpredictable. The attached
patch deletes the extra space in x509 output.
Jiri Horky
--- apps/x509.c 2013-10-03 13:42:39.504547535 +0200
+++ apps/x509.c.orig 2013-10-03 13:42:25.784301201 +0200
@@ -728,12 +728,12 @@ bad:
{
if (issuer == i)
{
-print_name(STDout, issuer=,
+print_name(STDout, issuer= ,
X509_get_issuer_name(x), nmflag);
}
else if (subject == i)
{
-print_name(STDout, subject=,
+print_name(STDout, subject= ,
X509_get_subject_name(x), nmflag);
}
else if (serial == i)
[openssl.org #2958] [PATCH] Fix for #2958: DTLS connect limbo
In DTLS with peer authentication, cipher-spec can be changed before the CertificateVerify message is processed leaving the connection in an unrecoverable state. This situation happens if the CertificateVerify message is lost or reordered -Dan dtls_2958.patch Description: Binary data
[openssl.org #3137] The behavior of CRYPTO_set_mem_functions() in FIPS mode
Hi, It looks like CRYPTO_set_mem_functions() of OpenSSL 1.0.1e does not work in FIPS 2.0.5: CRYPTO_set_mem_functions() calls indirectly CRYPTO_malloc() which sets allow_customize = 0; and so CRYPTO_set_mem_functions() does nothing (just return 0, instead of 1). Gdb trace with a modified _ssl module: #0 0x003803463100 in CRYPTO_malloc () from /lib64/libcrypto.so.10 #1 0x003803542fae in FIPS_drbg_new () from /lib64/libcrypto.so.10 #2 0x0038035448e1 in FIPS_drbg_health_check () from /lib64/libcrypto.so.10 #3 0x003803542e88 in FIPS_drbg_init () from /lib64/libcrypto.so.10 #4 0x0038034cf9d1 in RAND_init_fips () from /lib64/libcrypto.so.10 #5 0x003803465764 in OPENSSL_init_library () from /lib64/libcrypto.so.10 #6 0x003803462c61 in CRYPTO_set_mem_functions () from /lib64/libcrypto.so.10 #7 0x7135bc6c in PyInit__ssl () at /home/haypo/prog/python/default/Modules/_ssl.c:3180 My question - is this behavior expected or not? Thanks a lot, Qun From: qun.w...@sap.com Sent: Saturday, October 05, 2013 10:30 PM To: 'openssl-n...@openssl.org' Subject: The behavior of CRYPTO_set_mem_functions() in FIPS mode Hi, It looks like CRYPTO_set_mem_functions() of OpenSSL 1.0.1e-4.fc18 does not work: CRYPTO_set_mem_functions() calls indirectly CRYPTO_malloc() which sets allow_customize = 0; and so CRYPTO_set_mem_functions() does nothing (just return 0, instead of 1). Gdb trace with a modified _ssl module: #0 0x003803463100 in CRYPTO_malloc () from /lib64/libcrypto.so.10 #1 0x003803542fae in FIPS_drbg_new () from /lib64/libcrypto.so.10 #2 0x0038035448e1 in FIPS_drbg_health_check () from /lib64/libcrypto.so.10 #3 0x003803542e88 in FIPS_drbg_init () from /lib64/libcrypto.so.10 #4 0x0038034cf9d1 in RAND_init_fips () from /lib64/libcrypto.so.10 #5 0x003803465764 in OPENSSL_init_library () from /lib64/libcrypto.so.10 #6 0x003803462c61 in CRYPTO_set_mem_functions () from /lib64/libcrypto.so.10 #7 0x7135bc6c in PyInit__ssl () at /home/haypo/prog/python/default/Modules/_ssl.c:3180 My question - is this behavior expected or not? Thanks a lot, Qun __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
