Re: Elliptic Curve Cryptography in OpenSSL
Deryck Henson wrote: Any ideas on the implementation of ECC into the OpenSSL releases any time soon? If so, when? Thanks, hmm, there's some ecc crypto in 0.9.8-dev. Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Elliptic Curve Cryptography in OpenSSL
Any ideas on the implementation of ECC into the OpenSSL releases any time soon? If so, when? Thanks, -- Deryck Henson __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH: p2q (or rather q2p) 'RSA' option (also "TSU NOTIFICATION")
Since my patch doesn't seem to excite anyone, i'll try again and point out the obvious and less obvious. I tightened up a few lose ends but here's the gist: - 'openssl speed rsa1024 q2p1024' shows the improvement - option to generate RSA key of the form q*q*p with 'openssl genrsa -q2p 1024' - This is a high-level, algorithmic change. Any low-level speed improvements (SSE, EM64T) compound nicely. - To SSL clients this looks and smells like a normal key. They should not be able to tell the difference ;-) In practice, this could help double the number of SSL handshakes your server box can handle. The factoring effort security boundary is slightly lower but at current state of the art still in the vincinity of 2^80 for 1024 bit moduli afaik. Yes, i did add a member to rsa_st, there seems to be no way to add a field to an opaque member to avoid changing rsa_st. Can we please change this in the future with another level of indirection to an opague struct for instance? I seem to run into this a lot with my type of patches. Also, i used a crappy way to pass the fact a q2p key is to be generated by adding 1 to the public exponent argument to RSA_generate_key(). Again, just to not change the existing API. IANAL but afaik, this math is not patented, i heard the slower p*q*r might be. suggestions, comments really welcome, marius PS: SUBMISSION TYPE: TSU SUBMITTED BY: Marius Schilder SUBMITTED FOR: openssl.org POINT OF CONTACT: [EMAIL PROTECTED] PHONE and/or FAX: (email) PRODUCT NAME/MODEL #: openssl-0.9.7g q2p patch ECCN: 5D002 NOTIFICATION: (see attached .patch) --- Marius Schilder <[EMAIL PROTECTED]> wrote: > Find attached a patch I wrote to evaluate p^2q type > moduli, using Hensel lifting etc. > I see ~90% speedup for 1024 bit decrypts. Not > stellar, > probably due lots of constant overhead (e.g. decrypt > verification). > I added a -q2p parameter to genrsa. Either type > private key (pq and q^2p) can be loaded and used. A > run-once check switches which decryption routine to > use deep down in the bowels of crypto/rsa/ > This should coexist nicely with regular RSA, the > code > auto-detects what type of key we're dealing with. > Also, 1024 bit isn't the most optimal modulus size > with 3 factors. > > marius q2p-0.9.7g.patch Description: q2p-0.9.7g.patch
Re: SSL_read+SSL_ERROR_WANT_READ --> repeated with same argument
On Thu, 21 Apr 2005, Ka Fai Lau wrote: If it is absolutely necssary, a quick pointer to the libssl source code will be very appreciated. Any exceptional case? Hmm. I do not know about SSL_read but in case of SSL_write there is unnecessary check in the code that checks that the write must be repeated with same parameters. This can be turned off using one options (something about moving write buffer, cannot remember exactly). I did not have this problem with SSL_read, but then again, I did not do rehandshake in my code. regards, Arne __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL_read+SSL_ERROR_WANT_READ --> repeated with same argument
I saw the warning in man SSL_read: "When an SSL_read() operation has to be repeated because of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments" I have been browsing around the s2_lib.c, s2_pkt.c, s3_lib.c and s3_pkt.c. 'SSL *ssl' should be the same in order to read from the same socket is obvious. However, is it necessary to read from the same 'void *buf' pointing to the same memory location and even the 'int num' must be the same? (BTW, I am reading from a socket. FIXME: I suppose it doesn't matter.) If it is absolutely necssary, a quick pointer to the libssl source code will be very appreciated. Any exceptional case? --KaFai __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: AES+OpenSsl+ubsec hardware accelerator
Frederic, Thank you so much your help. I found that the problem was with the Broadcom library. They were overwriting the first 8 bytes of the key with the last 8 bytes of IV!. So now I have AES128_SHA and AES256_SHA working with UBSEC. Regards, Prashant.Frédéric Donnat <[EMAIL PROTECTED]> wrote: Hi Prashant,With added AES to our ENGINE without any problem for now.We have made tests with AES256-SHA, an AES128-SHA ciphers under openssl 0.9.7d and 0.9.7e.We have not tested the new release for now...Did your ENGINE was working fine in the older release?Regards,FredPS: the most part of the time a "fatal bad_record_mac" error was due to an invalid symmetric computation (IV settings or things like that) in our ENGINE-Original Message-From: [EMAIL PROTECTED] on behalf of Prashant KumarSent: Wed 4/20/2005 7:58 PMTo: openssl-dev@openssl.orgCc: Subject: AES+OpenSsl+ubsec hardware acceleratorHello All,I am using OpenSsl9.7e version. I have added code to do RC4, DES, 3DES and AES with ubsec engine (BCM5823). All the ciphers work fine except for AES ciphers. I see that op enssl gives me "fatal bad_record_mac" when I use AES. I verified with an example code that ubsec engine does the encrypt/decrypt using AES right. Is there any known problem in the OpenSsl AES implementation (I was using the ciphers AES128-SHA and AES256-SHA).Thank you all for your help.Regards,Prashant.-Do you Yahoo!?Yahoo! Small Business - Try our new resources site! __OpenSSL Project http://www.openssl.orgDevelopment Mailing List openssl-dev@openssl.orgAutomated List Manager [EMAIL PROTECTED]__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
RE: AES+OpenSsl+ubsec hardware accelerator
Hi Prashant, With added AES to our ENGINE without any problem for now. We have made tests with AES256-SHA, an AES128-SHA ciphers under openssl 0.9.7d and 0.9.7e. We have not tested the new release for now... Did your ENGINE was working fine in the older release? Regards, Fred PS: the most part of the time a "fatal bad_record_mac" error was due to an invalid symmetric computation (IV settings or things like that) in our ENGINE -Original Message- From: [EMAIL PROTECTED] on behalf of Prashant Kumar Sent: Wed 4/20/2005 7:58 PM To: openssl-dev@openssl.org Cc: Subject:AES+OpenSsl+ubsec hardware accelerator Hello All, I am using OpenSsl9.7e version. I have added code to do RC4, DES, 3DES and AES with ubsec engine (BCM5823). All the ciphers work fine except for AES ciphers. I see that openssl gives me "fatal bad_record_mac" when I use AES. I verified with an example code that ubsec engine does the encrypt/decrypt using AES right. Is there any known problem in the OpenSsl AES implementation (I was using the ciphers AES128-SHA and AES256-SHA). Thank you all for your help. Regards, Prashant. - Do you Yahoo!? Yahoo! Small Business - Try our new resources site! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Openssl application fails when using hardware random number generator.
I have motherboard with hardware number generator on AMD768 chip. It's a genuine random numbers source, and I would like to use it instead of pseudo-random /dev/urandom. In my Linux there is a working /dev/hw_random device [EMAIL PROTECTED] ~]# LANG= ll /dev/hw_random crw-r--r-- 1 sas root 10, 183 Feb 18 14:46 /dev/hw_random And I have some applications in this system using openssl library: cyrus-imapd with SSL support. I've tried either to simlink # ln -sf hw_random /dev/urandom or create corresponding device : # mknod /dev/urandom c 10 183 Whatever I tried, cyrus-imapd immediately fails to accept SSL connections. Since cyrus-imapd by itself does not use any RAND_* functions, and completely relies on openssl for this, I conclude this is openssl fault. May be this is because /dev/hw_random is slower than openssl expects ? How should I cope with this, and force openssl to use hardware ? -- Konstantin Andreev. mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
