Re: [openssl.org #2175] [PATCH] Optimization for 1024 bit RSA on x86_64 platform
The performance benchmark with openssl speed show about 50% performance gain for 1024 bit private RSA. The optimization is implemented as an engine named RSAX. Because x86_64 assembly is used in implementation, the optimization is only available on x86_64. More information about the algorithm used can be found in following URL. http://www.cse.buffalo.edu/srds2009/escs2009_submission_Gopal.pdf It appears that nobody cares about this patch. Is there something fundamentally wrong with this patch? Or I should send to someone other too? Appearance can be and in this case is deceiving. What is wrong is lack of time. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
sha-256 support in openssl 0.9.8g
Thanks Rafiq and Jason, I did run the openssl dgst -sha256 filename command, and it didnt complain ! So I know at least the simple sha-256 hashing operation is supported in openssl 0.9.8g. Just wasn't sure if it was also fully supported in the context of certificate verification, etc. Sounds like it is... I also need to make sure SHA-256 will work with SSH and SFTP on my machine. So was reading up some OPENSSH posts online. And came across this. Any thoughts ? Thanks a lot To implement the SHA256 support in OpenSSH, the platform must support libcSHA256 or OpenSSLEVP_sha256 SHA256 KEX. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Rafiqul Ahsan Sent: Tuesday, March 09, 2010 12:13 PM To: openssl-us...@openssl.org Cc: openssl-dev@openssl.org Subject: Re: OpenSSL server problems Yes, openssl 098g supports SHA256. I built Freeradius 1.1.7 with openssl 098g, and we have been using EAP-TLS with SHA256 signed certs for quite sometimes. Thanks On Tue, Mar 9, 2010 at 11:28 AM, Hasan Rezaul-CHR010 chr...@motorola.com wrote: Hi All, I am somewhat of a newbie to openssl, so apologize in advance for my ignorance :-) I have openssl version 0.9.8g on my custom Linux 2.6.27 distro. I need to make sure that SHA-2 (specifically SHA-256 algorithm) is supported with this version of openssl. The sha-256 algorithm will be used during IPSec link establishment, Certificates Verification, and for general TLS/SSL Cipher suites. From the quick online reading, I am getting mixed messages of whether sha-2 algorithms (specifically sha-256) is truly supported or not ?!? Supposedly things might still be hard-coded to sha-1 even when sha-2 algorithms are 'supported' ?... 1. Would you kindly clarify if openssl version 0.9.8g does infact meet my needs ? That is, does it in fact support sha-256 to be used in IPSec, Certificate verification, and general TLS/SSL. 2. If 0.9.8g is not adequate, what version of openssl does infact support my needs described above ? Thanks soo much in advance. __ OpenSSL Project http://www.openssl.org http://www.openssl.org/ User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org -- Rafiqul Ahsan
Re: [openssl-dev] [openssl.org #1951] [patch] verification of X.509 certificates that contain an RSASSA-PSS signature
Hodie VII Id. Mar. MMX, Dr. Stephen Henson scripsit: On Tue, Mar 09, 2010, Erwann ABALEA wrote: I can't verify ecdsa-with-SHA256 certificates, the ones transmitted a few days ago (German passports), with the same error (d2i_ECPKParameters function). The verification of the root against itself is OK, though. Well that doesn't check the signature any more unless you include -check_ss_sig Hmmm... Thanks, this option doesn't appear in the help text. Of course, the verification of a subordinate certificate against the root is/was OK with the Feb 7 version, without the RSASSA-PSS patch. That's odd they both verify fine here. Do you have any of the old patch code in place? I ended up using a completely different technique in HEAD. You were right, I certainly still had some of the old patch. With a new version freshly exported and compiled, everything's fine, both RSASSA-PSS and ecdsa-with-SHA256. Thanks. -- Erwann ABALEA erwann.aba...@keynectis.com - When uncertain, or in doubt, run in circles and scream. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2162] Updated CMAC, CCM, GCM code
As already mentioned programming SSEn+1 is not self-goal, all-round performance is. The only thing that can make me consider SSE2 at this point is performance numbers from Core2, which would be not worse than say 16 cycles per byte, preferably with 256B table. So could you *please* find possibility to run your benchmark on Core2? If you really can't, as last resort send binary compiled *without* /MD to me (zip it first). To give you the best to test it on machines you are familiar with, I have done a small GhashBench.exe which outputs results similar to the previous benchmarks. Thanks. Two things. For me it printed 0.0 and 0.1 in Ctr columns. I didn't try to figure out why, but MB/s columns appear sane, so I used them to obtain cycles per byte. I was also running it in VMware and values are not as monotone. This is one of reason for which I picked just 20 and 512 blocks lines as representative for 256B and 4KB tables. They were not abnormal in comparison to rest of table and it's safe to assume that corresponding table setup overhead is just few percent. On 2.4GHz Core2 I get: Blks Bytes XMM Ctr I32 Ctr XMM MB/s I32 MB/s - --- --- 20 320 0.0 0.0 70.8 48.0 512 8192 0.0 0.0 88.6 69.9 Or 32 cycles per byte for 256B and 27 for 4KB tables. On 2.0GHz AMD64 I get: Blks Bytes XMM Ctr I32 Ctr XMM MB/s I32 MB/s - --- --- 20 320 0.1 0.1 63.1 44.5 512 8192 0.0 0.1 83.2 58.6 Or virtually same result as above: 32/24 cycles per byte... I was expecting bigger difference between Core2 and AMD64 than none, because Core2 SSE2 *is* faster than AMD's... Should note, that the results include the whole GHASH processing, including the block loop, xor between blocks, and an optional zero-padding on the last block if the input size does not fold into block-length. My results are obtained as difference between GCM and vanilla counter mode. So that they also cover block loop and xor between blocks. They don't account for table setup nor final calculations, *but* they are obtained for 1KB input or 64 blocks. So that if they shouldn't be different from your by more than just few percent. On additional note. Newly committed http://cvs.openssl.org/rlog?f=openssl/crypto/modes/asm/ghash-x86_64.pl, i.e. 64-bit counterpart of ghash-x86.pl, was observed to process one byte in 10.2 cycles on AMD64 and in 16.4 on Core2. Pure integer code, 256B table. I have no data for P4/EMT64, but results won't be as impressive, because its shifter is very slw. Cheers. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Crash in BIO_set_fp(): Windows esp SL VC9?
-dev added, I think this is actually a bug
From: owner-openssl-us...@openssl.org On Behalf Of Michael Boman
Sent: Monday, 01 March, 2010 11:40
re: crash in BIO_set_fp, on Windows, could it be faq#PROG2?
I am using OpenSSL 0.9.8l from
http://www.slproweb.com/products/Win32OpenSSL.html
I link to these libraries for debugging:
C:\OpenSSL\lib\VC\ssleay32MTd.lib
C:\OpenSSL\lib\VC\libeay32MTd.lib
And these ones for release:
C:\OpenSSL\lib\VC\ssleay32MT.lib
C:\OpenSSL\lib\VC\libeay32MT.lib
I compile the program using the /MT (Release) and /MTd (Debug) flag
under C/C++ - Code Generation
Aside: all 4 pairs of .lib's in lib\VC (and one in lib) are
exportlibs for the one pair of DLL's, which are actually /MD
but use the applink mechanism, as mentioned in the FAQ, to get
the right CRT -- assuming the EXE correctly compiles applink.c,
and the code you referenced does.
So this should work. And using the corresponding files from
my (DLL) build of 0.9.8m it sort of does (see below), but using
the SL distro I also get a crash. Stepping in the debugger I see
code in SL that is similar but not identical. It appears to be
built with VC++08 or possibly later, in particular for MSVCR90,
while I use (elderly but still functional) VC++6.0 and MSVCRT[d],
and the exit 0xC417 occurs in MSVCR90 appparently below _setmode.
You didn't say what version of VC++ (and CRT) you are using.
I believe this is a bug:
bss_file.c file_ctrl() case for SET_FILE_PTR uses UP_fsetmode
not UP_fsetmod so it doesn't uplink when it apparently should;
instead uses direct _fileno and _setmode which faults in MSVCR90.
On (old) VC++6.0/MSVCRT _fileno is inlined and works, and _setmode
sets an error (EBADF) which is ignored, and the mode (bin/text)
set by the app at fopen is apparently left intact (and works OK).
Also looking in the same area:
bss_file.c BIO_new_file() calls *ctrl BIO_C_SET_FILE_PTR with
flags not including BIO_FP_TEXT, which sets binary even if the
call said e.g. w or wt; on Windows this gives poor results
if the output actually is text and needs \n=CRLF translation.
Similarly BIO_{read,rw,write,append}_filename do SET_FILENAME
with flags not containing TEXT. Explicitly calling BIO_ctrl
SET_FILENAME with e.g. BIO_FP_WRITE|BIO_FP_TEXT does work.
And BIO_new_fp() although prototyped as 'close_flag' actually
honors TEXT as well, as documented.
Some other things I noticed in working on this app:
Personally I would do each formatting op once to a membio or
string, and then duplicate the result to stdout and xmlOutput.
That would also avoid this problem, since then the app wouldn't
be using an fpbio for xmlOutput; everything else seems to work.
And I wouldn't indent SO deeply. And I would handle long
serials, as apps/x509.c does, since bigger than 32b are pretty
common and (often spurious) negatives shouldn't be misleading.
And officially WSAStartup should be once per process,
although since about W2k as I recall repeats are benign.
And unextended (insecure) client-initiated renegotiation is
probably -- we hope! -- going to stop working soon.
Logically I think it should work to compile the app /MD with a
new(er) compiler that uses MSVCR90 and thus doesn't need uplink,
or any supported mode(s) and static link (lib\VC\STATIC\various.lib)
against a new-enough library to be compatible (old MSVCRT is not,
it apparently doesn't have some _cookie stuff the SL build wants).
But I'm not in a position to try those out for now.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
