AES-XCBC-MAC support in OpenSSL
Hi, I need some help, I've dug around trying to find out if OpenSSL support AES-XCBC-MAC as described in RFC 3566. I can't find any reference to this anywhere and I have come to the conclusion that it is not supported. Can someone please confirm this? I know these things can end up being named something else so I may have missed it. Thanks, Chris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: how to enable ony AES,DES/3DES, RSA algorithm by using MACRO
Dear All, Thank you Ger Hobbelt for your help. Actually I tried using your suggestion. I have doubt it is necessary to use HASH Algorithm(SHA and MD5) for SSL connection. We can not use only DES, 3DES and AES, RSA Algorithms. Please clarify doubt. Thanks allot. Thank you. Regards, --Ajeet Kumar Singh image002.jpg
Re: how to enable ony AES,DES/3DES, RSA algorithm by using MACRO
On Thu, Nov 20, 2008, Ajeet kumar.S wrote: Dear All, Thank you Ger Hobbelt for your help. Actually I tried using your suggestion. I have doubt it is necessary to use HASH Algorithm(SHA and MD5) for SSL connection. We can not use only DES, 3DES and AES, RSA Algorithms. MD5 is also used for the certificate hash links and the traditional private key encryption key derivation algorithm. It is possible to avoid the latter though by using PKCS#8 format. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Encrypted Passwords via Sockets?
Hi - We are trying to exchange encrypted passwords via a socket based VPN connection. Does anyone know if we can exchange digital certificates via socket connections, Thanks, Savithri
How to revoke certificates
Hi, Using OpenSSL API 1. How to find that a certificate is expired? Which API deals with this? 2. How to move an expired certificate to revocation list? Is it done automatically? 3. How certificates are verified at server side? If a bunch of certificates available (inside a pem file), all these are verified to match the client certificate? Your suggestions are valuable. If examples are provided that would be a great help. Regards, Ravikanth
encrypting a DER format private key
Hi, I generated a private key in PEM format and want to convert it to DER format with the following command: openssl rsa -in mykey.pem -outform DER -out mykey.der It works OK, but the resulting mykey.der is unencrypted... I can verify this by issuing openssl rsa -in mykey.der -inform DER -text -noout and getting the output without it asking me for a passphrase. Now I tried all of the following without getting the mykey.der encrypted: openssl rsa -in mykey.pem -passout file:mykey.pass outform DER -out mykey.der openssl rsa -in mykey.pem -passout pass:this_is_my_passphrase -outform DER -out mykey.der openssl rsa -in mykey.pem -des3 -passout pass:this_is_my_passphrase -outform DER -out mykey.der But the result is always the same... mykey.der is completely open... is there a way to encrypt with a passphrase a DER format private key? TIA -- Mariano Absatz - El Baby www.clueless.com.ar # If you're going to tell people the truth, be funny or they'll kill you. - Billy Wilder __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: encrypting a DER format private key
On Thu, Nov 20, 2008 at 10:03:07AM -0200, Mariano Absatz wrote: Hi, I generated a private key in PEM format and want to convert it to DER format with the following command: openssl rsa -in mykey.pem -outform DER -out mykey.der It works OK, but the resulting mykey.der is unencrypted... I can verify this by issuing openssl rsa -in mykey.der -inform DER -text -noout and getting the output without it asking me for a passphrase. Now I tried all of the following without getting the mykey.der encrypted: openssl rsa -in mykey.pem -passout file:mykey.pass outform DER -out mykey.der openssl rsa -in mykey.pem -passout pass:this_is_my_passphrase -outform DER -out mykey.der openssl rsa -in mykey.pem -des3 -passout pass:this_is_my_passphrase -outform DER -out mykey.der But the result is always the same... mykey.der is completely open... is there a way to encrypt with a passphrase a DER format private key? The most common format for ASN.1 (DER) encrypted keys also bundles in the associated cert and trust chain, and is called PKCS#12. Microsoft has a proprietary (now reverse-engineered) format for (just RSA) password-protected private keys. The 0.9.9 snapshots support this format via the (not yet documented) -inform PVK option. What application is expected to read these password-protected DER keys??? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: encrypting a DER format private key
On Thu, Nov 20, 2008, Victor Duchovni wrote: On Thu, Nov 20, 2008 at 10:03:07AM -0200, Mariano Absatz wrote: The most common format for ASN.1 (DER) encrypted keys also bundles in the associated cert and trust chain, and is called PKCS#12. PKCS#8 is also usable. Some utility functions work in a similar way to the PEM versions, see d2i_PKCS8PrivateKey_bio() and i2d_PKCS8PrivateKey_bio(). Microsoft has a proprietary (now reverse-engineered) format for (just RSA) password-protected private keys. The 0.9.9 snapshots support this format via the (not yet documented) -inform PVK option. Use of that for anything other than interoperability purposes is discouraged. It has some security issues, such as the use of RC4 and some small key sizes. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Client verify failing - continued
From: [EMAIL PROTECTED] On Behalf Of Michael Simms Sent: Wednesday, 19 November, 2008 11:05 OK, as requested, I'm going to give a detailed breakdown of what the client and server does with this error As a note: The certificates are *fine* I have used them successfully with s_client and s_server tests. They verify perfectly well. The one you've attached, yes; the one you are generating in code, maybe not, because s_client (and s_server) never does that. So, the conversation goes as follows. I am abbreviating some of it, but only the unimportant bits (like the low level socket negotiation, and the values we pass into the generated keys which arent being verified). SERVER: SERVER: socket() // Create socket SERVER: fcntl() // Nonblocking fcntl SERVER: bind()// Bind to port SERVER: listen() // Listen on port SERVER: SSL_library_init() SERVER: SSL_load_error_strings() SERVER: ssl_meth=SSLv23_server_method() SERVER: sctx=SSL_CTX_new(ssl_meth) SERVER: bio = memory_buf_BIO(private_key, -1) SERVER: if (private_key_password) SERVER: key=PEM_read_bio_PrivateKey(bio,NULL, ssl_key_password_callback, private_key_password) SERVER: else SERVER: key=PEM_read_bio_PrivateKey(bio,NULL,NULL,NULL,NULL) SERVER: BIO_free(bio) SERVER: bio = memory_buf_BIO(public_key, -1) SERVER: cert=PEM_read_bio_X509(bio,NULL,NULL,NULL) SERVER: SSL_CTX_use_PrivateKey(sctx,key) SERVER: SSL_CTX_use_certificate(sctx,cert) SERVER: SSL_CTX_check_private_key(sctx)// PASSES It seems overwhelmingly likely, but just to be absolutely clear, I presume private_key and public_key are buffers containing the servercert.pem and serverkey.pem files you posted. You could read the files directly with _use_certificate_file and _use_PrivateKey_file, which is usually more convenient. Also, you don't show BIO_free for second bio (mem leak). CLIENT: socket() CLIENT: fcntl() // Nonblocking fcntl CLIENT: connect() //WAIT for connect to succeed SERVER: accept() SERVER: fcntl() // Nonblocking fcntl on new socket SERVER: sssl=SSL_new(sctx) SERVER: SSL_set_fd(sssl,newly_accepted_fd) SERVER: SSL_accept(sssl) //Keep on doing this until WANT_READ stops Server didn't do (SSL_CTX|SSL)_set_verify ? If so (as previously noted) it shouldn't be requesting client to authenticate at all. //CLIENT DOES **NOT** run SSL_library_init, as this is a unit test //run with the server and client in one process, and so it does not //initialise twice. CLIENT: ssl_meth=SSLv23_client_method() CLIENT: cctx = SSL_CTX_new(ssl_meth) CLIENT: SSL_CTX_load_verify_locations(cctx, ca_filename,NULL) CLIENT: SSL_CTX_set_verify(cctx,SSL_VERIFY_PEER,NULL) CLIENT: SSL_CTX_set_verify_depth(cctx,10); //THIS SECTION is all just generating a new keypair CLIENT: rsakey=RSA_generate_key(1024,RSA_F4,NULL,NULL) CLIENT: ckey = EVP_PKEY_new() CLIENT: EVP_PKEY_assign_RSA(ckey, rsakey) CLIENT: required_size = i2d_RSAPublicKey(rsakey,NULL) CLIENT: len=i2d_RSAPublicKey(rsakey,correct_sized_buf) //Move correct_sized_buf back to its start CLIENT: pubrsa=d2i_RSAPublicKey(NULL,correct_sized_buf,len) CLIENT: tmp_pkey = EVP_PKEY_new(); CLIENT: EVP_PKEY_assign_RSA(tmp_pkey, pubrsa); Aside: I THINK you don't actually need this i2d-d2i conversion, if you just set a (tagged) RSA* that happens to be a privatekey it can be encoded as a publickey (because of how RSA works). CLIENT: ccert=X509_new(); CLIENT: X509_set_pubkey(ccert,tmp_pkey); CLIENT: X509_set_version(ccert,3); Aside: I'm pretty sure that should be 2. X.509 version 3 is the version of the standard but the certs actually have a version field value of 2. In fact you apparently aren't using extensions, so a value of 0 meaning version 1 would work. CLIENT: X509_set_serialNumber(ccert, serial); CLIENT: X509_set_notBefore(ccert,timebound); CLIENT: X509_set_notAfter(ccert,timebound); Aside: the same time? Normally you want notBefore=some_time and notAfter=some_later_time (typically +3mo/2yr/10yr, etc.) CLIENT: X509_set_subject_name(ccert,subject); CLIENT: X509_set_issuer_name(ccert,subject); CLIENT: X509_sign(ccert, ckey, EVP_md5()); //THIS FINISHES the creation CLIENT: SSL_CTX_use_PrivateKey(cctx,ckey); CLIENT: SSL_CTX_use_certificate(cctx,ckey) I hope that's a typo and you meant ccert there. So your client has created its own selfsigned cert, using (and for) a key the server knows nothing about. If this was actually used for authentication it should fail, because the server has no reason to trust it. But per above the server is probably not requesting it, and per below you are getting an error before client auth anyway. CLIENT: SSL_CTX_check_private_key(cctx)//PASS CLIENT: cssl=SSL_new(cctx); CLIENT:
Re: Engine Issue: nShield 500
Hi Sander,
yep the order is correct - the thread callbacks (pthread) init function
is before the Engine initialization (which happens before the spawning
of the threads).
The error you are describing sounds definitely familiar - although my
magic number is 12 (if I use 13 threads then... crash...). The backtrace
is not really useful as well - unless you have the source code:
0xb7fe5410 in ?? ()
(gdb) backtrace
#0 0xb7fe5410 in ?? ()
#1 0xb5a3e3f8 in ?? ()
#2 0x0006 in ?? ()
#3 0x27a0 in ?? ()
#4 0xb7cd8811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7cd9fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7cd1fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#7 0xb7adbada in receive (conn=0x8086380, cctx=0xb5a3ebf0, replyp=0xb5a3e86c,
tctx_r=0x0, nonblocking=0, functionname=0xb7b41ce0 Wait)
at ../client.c:945
#8 0xb7adc3eb in NFastApp_Wait (conn=0x8086380, cctx=0xb5a3ebf0, replyp=0x0,
tctx_r=0x0) at ../client.c:982
#9 0xb7adaa1b in NFastApp_Transact (conn=0x8086380, cctx=0xb5a3ebf0,
command=0x0, reply=0xb5a3e9e0, tctx=0x0) at ../client.c:211
#10 0xb7ab40e9 in nfast_hwch_command (upc=0xb5a3ebf0, conn=0x0, remember=0,
command=0xb5a3eaa0, reply=0xb5a3e9e0, status_r=0x0, ebuf=0x0, ebuflen=0)
at ../command.c:15
#11 0xb7ab42a1 in nfast_hwch_command_chk (upc=0xb5a3ebf0, conn=0x0,
remember=0, command=0x0, reply=0x0, what=0x0) at ../command.c:59
#12 0xb7aaf338 in nfast_hwch_raw_rsa (upc=0xb5a3ebf0, conn=0x0, remember=0,
key=0, msg=
{buf = 0x808ba68 \210E\032��\234�6�ED*\220�h��2Bʸ\217, size = 128},
result=0x0) at ../keys.c:260
#13 0xb7aaf214 in HWCryptoHook_RSA (msg=
{buf = 0x808ba68 \210E\032��\234�6�ED*\220�h��2Bʸ\217, size = 128},
k=0x806c858, result=0x0, errors=0xb5a3f0c0) at ../keys.c:260
#14 0xb7b7bc1f in bind_engine () from /usr/lib/ssl/engines/libchil.so
#15 0xb7ee7736 in RSA_PKCS1_SSLeay ()
from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#16 0x0808bf10 in ?? ()
#17 0x0808bee8 in ?? ()
#18 0x08072078 in ?? ()
#19 0x0808be30 in ?? ()
#20 0xce86bb62 in ?? ()
#21 0x03d508e8 in ?? ()
#22 0x0021 in ?? ()
#23 0xb7f8d830 in ?? () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#24 0xb7f7c048 in CAST_S_table7 () from /usr/lib/i686/cmov/libcrypto.so.0.9.8
#25 0x0080 in ?? ()
#26 0x0808bee8 in ?? ()
#27 0x0808bf10 in ?? ()
#28 0x0808befc in ?? ()
#29 0x0807eed8 in ?? ()
#30 0x08085558 in ?? ()
#31 0x0010 in ?? ()
#32 0x in ?? ()
Any Idea ???
Later,
Max
Sander Temme wrote:
On Nov 19, 2008, at 11:24 PM, Max Pala wrote:
The software that I am writing is a multi-threaded OCSP responder.
Please make sure you initialize the engine correctly, and set up your
locking callbacks before you actually initialize the engine. If you
look at Apache:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup
the invocation of ssl_init_Engine() and ssl_util_thread_setup() used to
be in the wrong order, which led to Apache children crashing on an
assert() from within the Hardware Crypto Hook library (libnfhwcrhk)
whenever more than five threads were used. Sounds familiar?
If that is all in order, perhaps you can trap that assert() in gdb and
take a backtrace.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi all, it seems that I am missing the usage of the set of obscure functions: CRYPTO_set_dynlock_create_callback() CRYPTO_set_dynlock_lock_callback() CRYPTO_set_dynlock_destroy_callback() but I have no idea how to initialize those functions - is there any example on how to do that by using pthreads ? Ciao, Max Sander Temme wrote: On Nov 19, 2008, at 11:24 PM, Max Pala wrote: The software that I am writing is a multi-threaded OCSP responder. Please make sure you initialize the engine correctly, and set up your locking callbacks before you actually initialize the engine. If you look at Apache: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup the invocation of ssl_init_Engine() and ssl_util_thread_setup() used to be in the wrong order, which led to Apache children crashing on an assert() from within the Hardware Crypto Hook library (libnfhwcrhk) whenever more than five threads were used. Sounds familiar? If that is all in order, perhaps you can trap that assert() in gdb and take a backtrace. S. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
Hi all,
it seems that I am missing the usage of the set of obscure functions:
CRYPTO_set_dynlock_create_callback()
CRYPTO_set_dynlock_lock_callback()
CRYPTO_set_dynlock_destroy_callback()
but I have no idea how to initialize those functions - is there
any example
on how to do that by using pthreads ?
Ciao,
Max
Off the top of my head, and untested, but it should give you the idea:
struct CRYPTO_dynlock_value
{
pthread_rwlock_t lock;
};
#ifndef CRYPTO_LOCK
#define CRYPTO_LOCK 0x01
#define CRYPTO_UNLOCK 0x02
#define CRYPTO_READ 0x04
#define CRYPTO_WRITE0x08
#endif
void locking_callback(int mode, struct CRYPTO_dynlock_value *l,
const char *, int)
{
if(mode==(CRYPTO_LOCK|CRYPTO_READ))
pthread_rwlock_rdlock(l-lock);
else if(mode==(CRYPTO_LOCK|CRYPTO_WRITE))
pthread_rwlock_wrlock(l-lock);
else if(mode==(CRYPTO_UNLOCK|CRYPTO_READ))
pthread_rwlock_unlock(l-lock);
else if(mode==(CRYPTO_UNLOCK|CRYPTO_WRITE))
pthread_rwlock_unlock(l-lock);
}
struct CRYPTO_dynlock_value *create_callback(const char *, int)
{
CRYPTO_dynlock_value *l=(CRYPTO_dynlock_value *)
malloc(sizeof(CRYPTO_dynlock_value));
pthread_rwlock_init(l-lock, NULL);
return l;
}
void destroy_callback(struct CRYPTO_dynlock_value *l, const char *, int)
{
pthread_rwlock_destroy(l-lock);
free(l);
}
void InitDynLocks(void)
{
CRYPTO_set_dynlock_create_callback(create_callback);
CRYPTO_set_dynlock_lock_callback(locking_callback);
CRYPTO_set_dynlock_destroy_callback(destroy_callback);
}
DS
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: CRYPTO_set_dynlock_* mystery ... (was: Engine Issue: nShield 500)
On Thursday 20 November 2008 20:57:10 Max Pala wrote: it seems that I am missing the usage of the set of obscure functions: CRYPTO_set_dynlock_create_callback() CRYPTO_set_dynlock_lock_callback() CRYPTO_set_dynlock_destroy_callback() but I have no idea how to initialize those functions - is there any example on how to do that by using pthreads ? You might find the following of some help; http://www.openssl.org/docs/crypto/threads.html Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
