[openssl.org #1158] missing options in ca.pod and req.pod
committed. Thanks, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1161] Bug report
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
SHA-512 and long long - does SHA-512 depend on it?
Hello openssl-dev, Does SHA-512 depend on int64 support in the tool-chain? If so, are there any plans to make in a bit more portable? Thank you in advance. -- Best regards, Anthony mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: unrolled RC4 for ia64
Hi, David! Long time, no see:-) From: David Mosberger To: openssl-dev@openssl.org Cc: [EMAIL PROTECTED] First of all, note that openssl-dev is subscribers-only list, meaning that you have to be subscribed to post to it. But no harm is done, as you've sent a copy to my personal address and the submission will be cosidered. I apologize for inconvenience. Attached below is a patch that is based on the RC4 code recently released by HP Labs (http://www.hpl.hp.com/research/linux/crypto/). Compared to the HP Labs code, I just changed things to generate the code via a perl-script since that seems to be the standard way for OpenSSL. There is no requirement for expressing it in perl. All IA-64 OSes share same procedure calling convention and assembler syntax, which are two most common reasons for why most of other assembler modules are [required to be] written in perl. But never mind:-) Compared to the existing RC4 code for ia64 (which is very good already), this version has two improvements: it unrolls the loop to avoid the 1-cycle penalty that McKinley-type cores exhibit when a byte-store to the same word occurs faster than once per 4 cycles For my future reference regarding this issue. In commentary section you mention McKinley/Madison can issue st1 to the same bank at a rate of at most one per 4 cycles. I wonder how large is the bank? (RC4 would like to do it once per 3 cycles). Additionally, the code carefully prefetches the data and the key table. This was measured to achieve real speedup in complex workloads and also lets RC4 run at basically the same speed no matter whether the data is in memory or in the cache. With the patch applied, make tests still succeeds. Performance looks like this (openssl speed rc4): type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes rc4 original146981.83k 178195.65k 187632.68k 190110.93k 190661.86k rc4 revised134713.29k 185199.72k 248433.36k 265739.02k 271370.10k This was on a (lowly) 900MHz McKinley. Currently available version is already second one [original was not playing well with OpenSSH], and it's a tad slower than the original one. This is explanation to the discrepancy in OpenSSL results mentioned above [190MBps] and in our current source code [~210MBps]. Just for reference... If the 16-byte speed regression is considered serious, I suspect we could avoid that by not prefetching the table for small data sizes. Not really a concern. Please consider this code for inclusion into the next OpenSSL release. I'll look into it shortly and for now I'd like to thank you for your submission. A. P.S. I omit the original copy of patch to spare the public bandwidth, as the code is available at referred URL, if anybody is anxious to examine it now. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
Does SHA-512 depend on int64 support in the tool-chain? Yes, it's explicitly mentioned in FAQ. If so, are there any plans to make in a bit more portable? Not really. As support for platforms narrower than 32-bit is discontinued, I'd rather recommend to disable algorithm in question with no-sha512 at configure stage or switch to more feature-rich compiler. How wide-spread the target platform? Is SHA512 really required in the context and/or does it really worth it? These are kind of question behind reasoning behind not really. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Building on DG-UX x86 4.20 MU07
I'm trying to build openssl for the purpose of getting openssh build
for DG-UX 4.20MU07 . I tried to to build 0.97 and 0.98 with the
exact same result and I am getting nowhere. Could anybody point out
what I'm missing ?
The output of make report is in the following:
OpenSSL self-test report:
OpenSSL version: 0.9.8
Last change: Add libcrypto.pc and libssl.pc for those who feel
they ...
Options: no-gmp no-krb5 no-mdc2 no-rc5 no-shared no-zlib
no-zlib-dynamic
OS (uname): dgux bed36a R4.20MU07 generic AViiON PentiumPro
OS (config): AViiON-dg-dgux
Target (default): dgux
Target: dist
Compiler:
Failure!
-
making all in crypto...
making all in crypto/objects...
making all in crypto/md2...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all in crypto/rc4...
making all in crypto/idea...
making all in crypto/bf...
making all in crypto/cast...
making all in crypto/bn...
making all in crypto/ec...
making all in crypto/rsa...
making all in crypto/dsa...
making all in crypto/ecdsa...
making all in crypto/dh...
making all in crypto/ecdh...
making all in crypto/dso...
making all in crypto/engine...
making all in crypto/buffer...
making all in crypto/bio...
making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/store...
making all in crypto/pqueue...
if [ -n "" ]; then \
(cd ..; make libcrypto); \
fi
making all in ssl...
if [ -n "" ]; then \
(cd ..; make libssl); \
fi
making all in engines...
making all in apps...
rm -f openssl
shlib_target=; if [ -n "" ]; then \
shlib_target=""; \
fi; \
if [ "${shlib_target}" = "darwin-shared" ] ; then \
LIBRARIES="../libssl.a ../libcrypto.a" ; \
else \
LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \
fi; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o
dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o
crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o" \
LIBDEPS=" $LIBRARIES " \
link_app.${shlib_target}
( :; \
LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto }"; \
LDCMD="${LDCMD:-cc}"; LDFLAGS="${LDFLAGS:--O}"; \
LIBPATH=`for x in $LIBDEPS; do if echo $x | grep '^ *-L'
/dev/null 21; then echo $x | sed -e 's/^ *-L//'; fi; done |
uniq`; \
LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; \
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH \
${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o
asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o
ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o
ecparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o
s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o
ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o
ocsp.o prime.o ${LIBDEPS} )
Undefined first referenced
symbol in file
accept s_socket.o
socket s_socket.o
send ../libcrypto.a(bss_dgram.o)
connect s_socket.o
gethostbyname s_socket.o
getservbyname s_socket.o
setsockopt s_socket.o
getsockname s_client.o
bind s_socket.o
recvfrom ../libcrypto.a(bss_dgram.o)
gethostbyaddr s_socket.o
shutdown s_server.o
getsockopt ../libcrypto.a(b_sock.o)
sendto ../libcrypto.a(bss_dgram.o)
UX:ld: ERROR: openssl: fatal error: Symbol referencing errors. No
output written to openssl
Fatal error in /usr/bin/ld
Exit status 01
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
-
Doing certs
UX:sh (opensslwrap.sh): ERROR:
/opt/shareware/openssl-0.9.8/util/../apps/openssl: Not found
argena.pem = .0
UX:sh (opensslwrap.sh): ERROR:
/opt/shareware/openssl-0.9.8/util/../apps/openssl: Not found
WARNING: Skipping duplicate certificate argeng.pem
UX:sh (opensslwrap.sh): ERROR:
/opt/shareware/openssl-0.9.8/util/../apps/openssl: Not found
WARNING: Skipping duplicate certificate eng1.pem
UX:sh (opensslwrap.sh): ERROR:
/opt/shareware/openssl-0.9.8/util/../apps/openssl: Not found
WARNING: Skipping duplicate certificate eng2.pem
UX:sh (opensslwrap.sh): ERROR:
/opt/shareware/openssl-0.9.8/util/../apps/openssl: Not found
WARNING: Skipping duplicate
Re[2]: SHA-512 and long long - does SHA-512 depend on it?
AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! As the more code in the OpenSSL gets updated - the more I'll disable in ./configure? Quite sad... AP How wide-spread the target platform? It is QNX4. Not as usual as windoze, but still very popular for robotics... AP Is SHA512 really required in the context and/or does it really AP worth it? To ensure the interoperability with modern clients on other platforms (SSH.com, OpenSSH) - yes. AP These are kind of question behind reasoning behind not AP really. :( -- Best regards, Anthony mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! Once again, platforms *narrower* than 32-bits are discontinued, in other words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) As the more code in the OpenSSL gets updated - the more I'll disable in ./configure? Quite sad... Life is not fair, never was, never will be:-) AP How wide-spread the target platform? It is QNX4. Not as usual as windoze, but still very popular for robotics... As far as I understand there is gcc for QNX, so why not use it as more feature-rich compiler? AP Is SHA512 really required in the context and/or does it really AP worth it? To ensure the interoperability with modern clients on other platforms (SSH.com, OpenSSH) - yes. Is there evidence that there will be applications emerging that will refuse to negotiate anything else but SHA-512? I find it hard to believe. I reckon that disabling SHA-512 does not impose risk of reduced interoperability in the time-frame of release-span of any particular platform/compiler. Meanwhile ask your vendor to implement long long support:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
On Friday 15 July 2005 13:32, Andy Polyakov wrote: AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! Once again, platforms *narrower* than 32-bits are discontinued, in other words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) What's so hard to believe about a 16 bit embedded system (or even an 8 bit embedded system) that may need some kind of secure network access? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
AP As support for platforms narrower than 32-bit is discontinued... Do I face the prospect of not being able to update at all (past some 0.9.9)?! Once again, platforms *narrower* than 32-bits are discontinued, in other words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) What's so hard to believe about a 16 bit embedded system (or even an 8 bit embedded system) that may need some kind of secure network access? I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
On Fri, 15 Jul 2005, Andy Polyakov wrote: I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. Lots of embedded work is still on 8-bit processors- 8051s, 68HC11s, etc. The 16 bits are being replaced by low-end 32-bit processors. But 8-bits are going to be here for a long time. I'm not sure that OpenSSL is a good code base to be used on 8-bit embedded systems, and at 200K, it's probably iffy for 16-bit systems. So I could easily see OpenSSL going We don't support small systems (sub 32-bit). But that doesn't mean they aren't out there. Brian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
Actually, my point about embedded systems wasn't that they'd necessarily have the full suite of OpenSSL, but that a pared-down version would be desirable. If all I want to do is triple DES with anonymous DH for key exchange on an embedded platform (for example), OpenSSL is probably a good place to start. By explicitly abandoning sub-32 bit systems, this may not be an option going forward. On Friday 15 July 2005 14:05, Brian Hurt wrote: On Fri, 15 Jul 2005, Andy Polyakov wrote: I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. Lots of embedded work is still on 8-bit processors- 8051s, 68HC11s, etc. The 16 bits are being replaced by low-end 32-bit processors. But 8-bits are going to be here for a long time. I'm not sure that OpenSSL is a good code base to be used on 8-bit embedded systems, and at 200K, it's probably iffy for 16-bit systems. So I could easily see OpenSSL going We don't support small systems (sub 32-bit). But that doesn't mean they aren't out there. Brian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re[2]: SHA-512 and long long - does SHA-512 depend on it?
Hello Andy, Friday, July 15, 2005, 9:32:10 PM, you wrote: AP Once again, platforms *narrower* than 32-bits are discontinued, in other AP words 16-bit one[s]. Is your platform 16-bit? I find it hard to believe:-) Oh! Yes, now I see the point - *NARROWER*! QNX4 is 32bit OS. The only problem is in the tool-chain (Watcom C v10.6B does not support int64)... AP As far as I understand there is gcc for QNX, so why not use it as more AP feature-rich compiler? I'm afraid it becomes an off-topic here... gcc v2.8 or something, roumors are it is quite buggy... And stale... :( AP Meanwhile ask your vendor to implement long long support :-) :) Indeed! :)) :( OK. Thank you! -- Best regards, Anthonymailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
On Fri, 15 Jul 2005, Jim Schneider wrote: Actually, my point about embedded systems wasn't that they'd necessarily have the full suite of OpenSSL, but that a pared-down version would be desirable. If all I want to do is triple DES with anonymous DH for key exchange on an embedded platform (for example), OpenSSL is probably a good place to start. By explicitly abandoning sub-32 bit systems, this may not be an option going forward. The 8-bit system I have experience on (Cypress EZ-USB 8051) had like 8K of ROM, and 256 bytes- not kilobytes, not megabytes, *bytes*- of RAM. Now, you can implement triple-des and DH in this space, but it basically requires a dedicated implementations. You can't afford to waste a byte. The gray area is 16-bit systems, with hundreds of K to say a meg of memory. The problem is that there is increasingly less cost difference between the 16-bit CPUs and the low end 32-bit ARM and PPC cpus. Which means the 16-bit market is going away, from what I've seen. Brian __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SHA-512 and long long - does SHA-512 depend on it?
What's so hard to believe about a 16 bit embedded system (or even an 8 bit embedded system) that may need some kind of secure network access? Nothing at all. What's hard to imagine is that a free development effort must support all the latest and greatest crypto techniques for such a platform. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
