Proposal: environment variable to disable SSLv2/v3/TLSv1.0/etc individually
This idea comes via https://bugzilla.mozilla.org/show_bug.cgi?id=1083767 (which I realize isn't on openssl's rt, but given the enormity of the security problem I hope you'll forgive me). The proposal at that bug is to create an environment variable for NSS to enforce disablement of particular versions of the protocols. What I'd like to see is a single environment variable that can do the same across NSS and OpenSSL and any other TLS library that chooses to look for the same variable. I realize that on embedded platforms, there is no such thing as a process environment. Obviously, this wouldn't have any effect in those platforms. But, it would reduce environment wastage across the two largest open-source TLS libraries and their clients, and would provide a single checklist item that could control OpenSSL clients (think Chrome) as well as NSS (think Firefox). Thoughts? -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
Re: Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve
Check for return code. If a given function doesn't support -1 for an
error return, at worst you've written some extra error-handling code.
If it does, then it's a truly bad idea to simply check for non-zero.
I probably shouldn't have mentioned the standard idiom in the first
place. It's only applicable in areas where there are no error returns.
(A lack of error returns is often cited as a security liability in any
case.)
-Kyle H
On 7/11/2014 6:22 AM, balaji marisetti wrote:
@Kyle Hamilton
So should all the new programs stick to the idiom or check for -1 return code?
On 11 July 2014 14:56, Ben Laurie b...@links.org wrote:
On 11 July 2014 09:53, Kyle Hamilton aerow...@gmail.com wrote:
EC_POINT_is_on_curve is documented to return -1 on error, 0 if it's not
on the curve, and 1 if it is on the curve.
However, this breaks the standard idiom if(!EC_POINT_is_on_curve()) {
return BAD_KEY; }, because it requires an additional test for an error
condition.
Plenty of OpenSSL functions return -1, 0, 1. Plenty also return 0, 1.
Its not optimal.
I don't know what the best outcome would be in this situation.
-Kyle H
On 7/11/2014 12:34 AM, balaji marisetti wrote:
Hi All,
I have a doubt. Shouldn't the `EC_POINT_...` methods be returning -1
instead of 0 on error conditions?
Thanks,
Balaji M
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve
EC_POINT_is_on_curve is documented to return -1 on error, 0 if it's not
on the curve, and 1 if it is on the curve.
However, this breaks the standard idiom if(!EC_POINT_is_on_curve()) {
return BAD_KEY; }, because it requires an additional test for an error
condition.
I don't know what the best outcome would be in this situation.
-Kyle H
On 7/11/2014 12:34 AM, balaji marisetti wrote:
Hi All,
I have a doubt. Shouldn't the `EC_POINT_...` methods be returning -1
instead of 0 on error conditions?
Thanks,
Balaji M
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
smime.p7s
Description: S/MIME Cryptographic Signature
Another security bug, this time in MAC verification...
http://opensslrampage.org/post/88383880093 I don't know if this has in fact been given to the OpenSSL team yet. I am not jsing, and I am not involved in the OpenBSD audit. However, this is important. If MD5 passes, but SHA1 fails, then the MAC verification will pass. This reduces the security of the handshake to MD5. I don't know where ssl3_final_finish_mac() is called from, if it's limited to SSLv3 or if it's also called from TLS. -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
Re: FIPS revalidation after openssl vulnerability fix
If you are using the same fipscanister (that was properly built), there is no need to revalidate. Any other situation that has a validation doesn't follow the supported validation, and the answer cannot be found here. -Kyle H On Jan 29, 2014 10:24 PM, sam1982 ajay_sonaw...@symantec.com wrote: Thanks Stevan for prompt reply. Just to confirm, you are saying that even if I upgrade openssl to 1.0.1f from 1.0.1c, fips validation which is done on older version of openssl libeay32.dll(1.0.1c) holds true. There is no change in FIPS object module and validation is already done around 4 months ago. Please confirm my understandings. Ajay -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-revalidation-after-openssl-vulnerability-fix-tp48343p48353.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
Re: Safe ECC curves
1.3.6.1.4.1.22232.15.0: Curve25519 (That's out of my arc) X coordinate is an OCTET STRING. Y coordinate is a 0-byte OCTET STRING (since it's not defined as optional in ASN.1, it must be present -- but how can you compress what doesn't exist?) When does the Point Compression patent expire, anyway? -Kyle H On Jan 2, 2014 6:28 AM, Dr. Stephen Henson st...@openssl.org wrote: On Thu, Jan 02, 2014, Salz, Rich wrote: So Curve25519 needs a standard OID and some notes on the format to use for ASN.1. Does such a thing exist? I don't think so. Perhaps the TLS list is the place to discuss this? Should we (I?) start a thread there on a proposal to fit Curve25519 into common TLS usage? Strawman proposal: The keys are OCTET STRING (or does BIGNUM fit better with existing code?) Y is fixed at zero An OID is assigned from the IETF arc Anything else missing? Well ideally it needs to be as close as possible to RFC5280 which is a PKIX document and the group has now closed... great timing. But that ends up with point compression rearing its ugly head. It's not much use though if it takes a glacial time scale to get an OID assigned (or preferably several OIDs AFAICS). I can ask djb but I bet he *really* doesn't care. :) Well if he doesn't that's fine. I'd otherwise feel a bit guilty ats appropriating his curve with an OID. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Safe ECC curves
Curve25519 public keys are 32-byte strings of digits. Private keys are 32-byte strings of digits. The agreement algorithm doesn't use the Y coordinate at all. djb has a fixed-clock-cycle algorithm he wrote in GNU assembly for Athlon. I am unhappy with his insistence that nobody should try to implement it for other platforms, as though Athlon is the only platform anyone would ever need. I agree that a platform-independent optimized arithmetic would be a good thing. I would also like to see (since I know nothing about x86, x86_64, or Athlon assembly language) its translation to a 64-bit ABI. But that's out of scope for this list. At this point, tls@ has been so thoroughly compromised by BULLRUN and well-meaning rank amateurs that no actual work can be forwarded without a preexisting implementation. Many of the issues cited with the curve25519 tls draft were spurious and irrelevant to its application and adoption; however, I have neither the knowledge to implement it myself or the funds to hire anyone to implement it. I'd throw what pittance I can at a Kickstarter for it, though. (To be clear: you need to know what digest you're feeding the 256 bits of curve25519 output through, and that might cause a curve25519-sha256, curve25519-sha384, etc ECDHE selection. It's also useful to note that the public key calculation is the output of the same curve25519 function with the specific public key parameter '9', and the function in djb's implementation is fast enough to generate on an Athlon a public key from a pseudorandom private key on connect().) -Kyle H On Jan 1, 2014 1:18 PM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jan 01, 2014, Daniel Kahn Gillmor wrote: On 01/01/2014 03:45 PM, Kurt Roeckx wrote: Hi, I recently ran into this: http://safecurves.cr.yp.to/ It seems that openssl doesn't support any of the curves that are listed there as safe. At least the curve 25519 is popular and has a draft for using it in TLS. Would it be possible to add at least support for that curve? I think you're referring to Simon Josefsson's draft: https://tools.ietf.org/html/draft-josefsson-tls-curve25519-01 IIRC, the discussion about that draft over on t...@ietf.org got a bit bogged down in the details of how to represent the points for this curve and other similar curves (e.g. curve3617): Yes that's a problem. Adding support for some curves just needs addition of the appropriate curve parameters, OIDs and in the case of TLS the Named Curve values. Unfortunately for others (curve 25519 is of this type I believe) the handling of the curve needs to be treated as a special case. We'd need a way of representing public keys in SubjectPublicKeyInfo (this the point representation discussion), private keys in PKCS#8 format and ideally optimised curve arithemetic to protect it from attack. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2993] Openssl manual pages
Sure, but you probably also didn't have them in /usr/local/ssl/man, instead of /usr/local/man or /usr/man. They need to go somewhere that the default man configuration on most Linuxes will get to them, if not the BSDs. -Kyle H On Sat, Feb 16, 2013 at 6:41 AM, Kurt Roeckx via RT r...@openssl.org wrote: On Sat, Feb 16, 2013 at 09:41:41AM +0100, Ivailo via RT wrote: The manual pages placement should use MANPREFIX instead of MANSUFFIX or the manual pages can not be read. The following patch does the job: http://pastebin.com/auK9EFSG. I don't understand what you're trying to fix. You seem to be renaming req.1 to openssl-req.1 and SSL_new.3 to openssl-SSL_new.3. man req, man 1 req, man SSL_new and man 3 SSL_new have always worked perfectly for me, I have no idea why you want to complicate it by needing to prefix it with openssl-. However, I do place the manpages in the 1ssl and 3ssl' sections instead or 1 and 3. However, it has to applied after the configuration step or the Makefile gets updated. So you mean you should have updated Makefile.org instead of Makefile. Note that your diff is between Makefile.org and Makefile. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: top 10 mistakes when using libopenssl?
Suggestions from my experience: -Failing to verify the certificate after calling SSL_accept() -Failing to verify minimum cipher strength for the application -Failing to understand that the NULL suites give nothing and only take extra bytes -Misunderstanding that DN=CN:CA1;DN=CN:you does NOT match DN=CN:CA2;DN=CN:you -Failing to support STARTTLS One I dread having to correct: -Using aNULL:eNULL solely for data stream compression -Kyle H On Wed, Oct 10, 2012 at 1:29 PM, travis+ml-openssl-...@subspacefield.org wrote: So, I'm curious, if anyone has compiled (or wants to volunteer pieces of) a list of mistakes that developers make when using libopenssl (for SSL/TLS). I mean source code issues, not operational/evironmental/PKI. If that's not available, I'm sure I can develop one from reading a well-written howto on how to use it... any subtleties that won't prevent it from working but will prevent it from being secure are valuable. But it'd be easier if I had the first list, not its complement. :-) -- http://www.subspacefield.org/~travis/ Any sufficiently advanced magic is indistinguishable from reality. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Generating randomness in userspace
See also http://egd.sourceforge.net/ (Entropy Gathering Daemon, written in perl) -Kyle H On Thu, Aug 11, 2011 at 12:33 PM, Vegard Nossum vegard.nos...@gmail.com wrote: Hi, I've written a small program that gathers randomness from the uncertainty of scheduling between threads/cores in a multithreaded program/system. The purpose of this is to generate random numbers entirely in userspace (in case the /dev/random traffic is somehow being watched, etc.). Attackers could still get their hands on the random numbers, but I'm guessing it would be a lot more work than simply tapping into the kernel/userspace interfaces -- they would have to peek into the address space of the process generating the numbers. One way to use this may be to seed a PRNG which runs in parallel with e.g. /dev/random; XORing them together should yield a bitstream with quality at least as good as the best of them, and will make it more difficult to predict the output simply having access to the kernel's secret state (or the numbers generated by it). Is this interesting for the OpenSSL project? Or do you have something like this already? (I could only find the use of certain things like the current time, pid, uid, etc., which I think an attacker would have much easier access to.) Or is it not really a concern in the first place? I attached my code -- it is not rigorous, but I think I avoided the worst pitfalls. I'm not sure what kind of entropy/quality the output has, but it should be better than nothing at all. $ g++ seed.cc -lpthread -lssl -lcrypto ./a.out b41c91f348638116 a165d0fac8b2304e 282d0d24311d7511 [...] The code works only on x86_64, and probably also only on Linux. Vegard Verify This Message with Penango.p7s Description: S/MIME Cryptographic Signature
Re: SSL/TLS: Revealing information about the trusted authorities
The names of the CAs accepted are already supposed to be sent as part of the negotiation. It wasn't until after TLSv1.0 that the spec permitted a wildcard CA name list. This kind of information-leakage being a vulnerability also depends on the application being authentication-naive. A web application using Apache's optional_no_ca, which looks in the environment for the client-provided certificate chain, could process the authentication as part of the application logic without sending an SSL/TLS alert. Ralf Engelschall and Eric Young are two of the main reasons why web security is stuck in the dark ages (RSE for saying optional_no_ca is actually against the idea of authentication in the mod_ssl documentation, and EAY for creating the SSLeay =BEGIN [WHATEVER]= header for PEM-encoded ASN.1 structures and enforcing that there was no single ASN.1 processing path). This is compounded by the fact that few people in TLS development will listen to anybody who isn't a mathematician or who isn't already indoctrinated into the X.509 PKI Priesthood. Those few who do aren't part of the PKI priesthood, and have shoehorned themselves in to OpenPGP as the only alternative. And, of course, since I'm part of neither group, nobody listens to me either. -Kyle H On Sun, Jul 31, 2011 at 7:06 AM, Martin Boßlet martin.boss...@googlemail.com wrote: Hello, if we do SSL/TSL client authentication, the current OpenSSL 1.0.0d verifies the client certificate upon reception of the Client Certificate message. Let's consider I want to find out whether the server trusts a certain CA I as an attacker am planning to compromise. I would send some certificate signed by that CA and then, it is possible to find out if the server trusts that certificate by interpreting the alert being returned. If the CA is trusted, the server will complain about the Certificate Verify message being wrong, otherwise it will inform me that the CA is untrusted. 1. Couldn't this be considered as a weakness? 2. Wouldn't it be better to send a less revealing alert in this case? 3. Or is this no risk at all and I am overlooking something important? Thanks in advance, Martin Bosslet __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org Verify This Message with Penango.p7s Description: S/MIME Cryptographic Signature
Re: Which tar.gz file I need for OpenSSL FIPS Object Module?
The Security Policy is the document you need. Please see Steve Marquess's link to the official copy at NIST. The Security Policy explains everything, including what file you need to obtain, its HMAC, how to verify it, what you must do to retain validation of the canister, how to build the canister, and how to build a FIPS-valid version of OpenSSL using the canister built from the verified FIPS code. -Kyle H On Fri, Jul 15, 2011 at 11:06 AM, Tatiana Evers tev...@tet.com.br wrote: Hi, I'm using openssl (openssl-0.9.8r.tar.gz ) in a project, and now we want certificate the software with FIPS certification, my question is if we must have openssl-fips-1.2.3.tar.gz to use OpenSSL FIPS Object Module? In openssl-0.9.8r.tar.gz project we already some fips files. What is the difference between openssl-fips-1.2.3.tar.gz and openssl-0.9.8r.tar.gz? In User Guide I read the following: The FIPS Object Module is the special monolithic object module built from the special source distribution identified in the Security Policy. It is not the same as the OpenSSL product or any specific official OpenSSL distribution release. Regards, Tatiana Evers tatiana.ev...@tet.com.br +55 51 3220 3433 = Tools Technologies - TT The Software Development Expert Rua Riachuelo, 1098 Conj. 1103 Centro - Porto Alegre - CEP 90010-272 Fone: +55 51 3220-3220 http://www.tet.com.br = __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How can I upload that .chm file?
A Gmail account, which allows you to send file attachments through Google's smtp server up to 10MB in size, is free. -Kyle H On Sat, Sep 18, 2010 at 6:11 PM, Harold S. Henry har...@talerian.com wrote: No luck sending to r...@openssl.org; the mail server still said the .chm file exceeded its fixed size limit... I'm happy to contribute the source (attached here), but, um, it's not exactly easy to use. Building a .chm is a bit of an exercise, and experience is useful. Still, here it is. Let me know if you find a way I can post the .chm (which, for those who don't know, is the data file for Microsoft's HTML Help 1.x viewer, and other viewers -- it's a pretty good way to browse moderately large interlinked doc sets). -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of aerow...@gmail.com Sent: Saturday, September 18, 2010 2:27 PM To: openssl-dev@openssl.org Subject: Re: How can I upload that .chm file? Send an email with the CHM attachment to r...@openssl.org. It might be a good thing to contribute the source of the utility as well, so that the code can be tweaked as useful, and so that new released versions (and any patches to the pod files) can have their content integrated into that version's generated CHM. (Note that the utility doesn't have to be written in C or perl to be useful -- CA.sh is a Bourne shell script. CHM is also only natively supported on Windows, so it might be useful to point out that OSX has a free utility called 'chmox' which can render CHM files in the Mac Quartz environment. Linux/BSD have graphical CHM viewers as well. gnochm and kchmviewer, as well as a program called xchm which is, apparently, quite outdated. -Kyle H On Sat, Sep 18, 2010 at 1:20 PM, Harold S. Henry har...@talerian.com wrote: The server won't accept an attachment that large (425 KB)… suggestions? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Openssl asm BN/AES/SHA1 optimization for SH4 and MIPS32
Please send this to r...@openssl.org so that it goes into the request tracker, or else it will likely be lost in the shuffle. -Kyle H On 9/7/10 1:56 PM, Vincent Labie wrote: Hi, Please find attached a BN/AES/SHA1 asm implementation for SH4 and MIPS32 little endian systems (common CPUs in SoC). This ASM code have been done with the help of Andy Polyakov's framework for the AES and SHA1 functions. The gain is almost 2x on SH4 with scheduling optimization, and 33/40% on MIPS with all register usage (compared to GCC generated code for RSA/AES/SHA1, the very standard ciphers for SSL connections). This gain is quite visible on low power CPU systems. A lot of tests have been run with this patch on 0.9.8o and 1.0.0a openssl trees, so I think I can propose it for the openssl main tree. Review and feedback are welcome. Thanks, Vincent Labie smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl-dev] Re: How to locate the X.509 specifications
The 5280, 3280, and 2459 profiles are utterly broken and useless. They conflate privilege management with identity management (extendedKeyUsage for the lose), and they have violated ASN.1 and OID management constraints by changing the semantics of an already-defined OID between 2459 and 3280. I expect that revision 6 of X.509 isn't going to be used by the IETF any time soon, until it's available for free. If it ever is. In the meantime, I'm using the X.509 data structures to do something explicitly out-of-scope for X.509. Here's hoping that it makes it out the door. -Kyle H On Sun, Aug 8, 2010 at 1:38 PM, David Shambroom w...@intersystems.com wrote: RFC 5280 is just what it says it is: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile tailored for the Internet (Section 3.1) No one said that it's anything more. Don't use it if you don't like it, but it's worth knowing about. Erwann ABALEA wrote: Hodie VII Id. Aug. MMX, David Shambroom scripsit: See: http://www.ietf.org/rfc/rfc5280.txt RFC5280 is only a profile for X.509 certificates and CRLs, just were RFC3280 and RFC2459 before it. Hopefully, RFC5280 is of better quality than its predecessors, but doesn't replace the standard at all. It adds more constraints, some of them are unnecessary (for example an organizationName or a commonName limited to 64 characters). RFC acts on top of X.509, and only for public key certificates (i.e. not attribute certificates). Kyle Hamilton wrote: I was asked this morning where to find the X.509 specification, since http://itu.int/ is such a messy website. It's sad the 2008 version is only available for a fee. I always thought the free 2005 version (and corresponding X.5xx standards covering other important aspects) was a good thing to help development. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME Cryptographic Signature
How to locate the X.509 specifications
I was asked this morning where to find the X.509 specification, since http://itu.int/ is such a messy website. I'll point you to the general location, because it's a better piece of information to have than the exact location. (There are other recommendations that X.509 refers to, and being able to find *all* of them is key to being able to understand the spec.) The sector that we are interested in is called ITU-T, Standardization (as opposed to ITU-R, Radiocommunications). http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx To get to X.509 from there, click the 'X' (above Y and Z), for 'Data networks, open system communications and security. That'll take you to: http://www.itu.int/itu-t/recommendations/index.aspx?ser=X . This is a tree view; you want the node labelled 'X.500-X.599: Directory'. Then, select X.509 (it's the third in the tree). The 11/2008 version (Edition 6) is only available for a fee (85 Swiss Francs), and so the version that I work from is Edition 5 (which is available for no fee). And, according to XE.com, CHF 1,00 represents USD $0.9626 at midmarket rates today (2010/08/07). -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
Re: Slow crypto initialization.
The OpenSSL development team typically don't comment on a request until they've fixed it. (I believe this is poor customer service, but I also believe that I'm not entitled to good customer service until I've paid for it.) What appears to happen is this: 1) bug submitter sends an email to r...@openssl.org 2) rt records it, along with any attached patches, and mails openssl-dev and the core committers 3) One of the core committers (eventually) looks at it 4) One of the core committers (eventually) integrates it 5) The core committer comments on the bug about when the patch was checked in, or other pertinent details 6) Eventually, the next release of OpenSSL comes out, with the patch included. OpenSSL isn't an open open-source software, in that the core committers appear to maintain a separate mailing list where they coordinate how they're working on new pieces and how they're supposed to interact. (If I had to guess, I'd think that this was primarily done for the FIPS validation effort [since the CMVP is used to non-open-source development strategies], but it might have been that too many people without any knowledge of security were trying to suggest things that were completely and inexplicably just not getting the concepts of security is a chain of components, which is only as strong as its weakest link. I am not a member of the core committing team, and in fact I have no direct correspondence with them, so these are guesses.) It would be nice to interview the developers, and ask them what's different in 1.0.0 over 0.9.8, as well as to get an idea of their plans for the future and some of the flavors of their personalities. However, I'm also not a journalist, so I'm not the appropriate person to do that, either. However: the best way to add comments (including comments on how long it's taking to process your patch) to your bug report is not to complain on the openssl-users list, it's to reply to r...@openssl.org with your bug number in the Subject line. That will cause it to add your correspondence to its record, and bounce it to openssl-dev and all the developers. I wish there were a customer service organization for it as good as Debian's... but there are other issues there. -Kyle H On 7/27/10 1:31 PM, Jake Goulding wrote: Thanks for the information about the rt address. We sent the explanation and patch as you suggested, and can now see the issue on the tracker list. However, no one has commented on it. Are there additional steps we can take to further the process of accepting the patch? Thanks! Jake Goulding | Software Engineer gould...@vivisimo.com | Connect: www.vivisimo.com Vivisimo - Information Optimized - Ger Hobbelt g...@hobbelt.com wrote: Don't be sorry, this is great work!! I'm glad the culprit has been found (and fixed)! BTW: To help the OpenSSL core team help track and fix this, it would be good to submit your message + patch to r...@openssl.org so it ends up as an issue ticket in the tracker and this material does not disappear off the horizon of an ever progressing discussion list. A reference to this email thread in the RT would be handy, e.g.: http://www.bluequartz.us/phpBB2/viewtopic.php?t=131309 (the entire thread is easily viewable as a set of forum messages there, so one page carries all) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-us...@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME Cryptographic Signature
Re: A CSP extension for OpenSSL?
I don't particularly like advocating other products here, but NSS (from Mozilla) has a (relatively) secure PKCS#11 softoken implementation, and it can interface with other PKCS#11 middleware. The softoken has been FIPS-validated, at certain versions. -Kyle H On Thu, Jun 3, 2010 at 3:15 AM, Martin Gwerder mgwer...@primecalc.com wrote: Hi All Recently we built a Linux based system setup which is heavily relying on X.509 certificates. On this occasion we had to realize that there is no such thing as a client CSP available on Linux or UNIX (neither free nor comercial; At least nothing which might be well supported by apps; If I have overlooked something let me know). This ends in the paradox situation that unless stored in a physical secured store (smartcard) a certificate identity may only be used by exposing the certificate file directly to the user using it (which makes it transportable; I am well aware that a root user may always transport a certificate unless stored in an apropriate HW store). All the following text is just a couple of thrown thoughts. Feel free to comment and/or criticize it. It usually would make no sense to implement a CSP as it would require that we would have to implement the support for the respective CSP into each and every application. There is however a solution which might work. As OpenSSL is widely used in lots of applications it would be a thing to consider the following: OpenSSL would have to be modified as follows: - Implement a dual use for certificates which allows to - Either use an ordinary certificate (to be used as of now) - or a CSP configuration which contains the configuration where and how to get the certificate services - Implement a certificate service provider daemon in OpenSSL which offers access thru named sockets or network sockets - Implement a CSP configuration generator in OpenSSL which creates CSP configuration files which can be distinguished from a certificate at any time. This modification of the OpenSSL library would allow to make the certificates more secure and allow applications without (!) any code modification (just by linking against the CSP capable OpenSSL library) to support the CSP. I am well aware of the magnitude of the proposed change. I futhermore intentionally left out a couple of important details (such as how would the client authenticate against the CSP server or how is the CSP daemon configured). I am furthermore aware that introducing such a client/server design would introduce a new SPOF and a couple thoughts should be wasted towards that direction as well. I have not seen any features covering the purpopse of the above mentioned changes. I would be however more than happy to hear that all of it allready exists. I would be very glad if someone would raise either a cople of concerns or shout for its implementation (or both). Regards Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: ssl_comp_methods never freed
Please send patches (as attachments) to r...@openssl.org, so they can be tracked. (rt will automatically assign a request number, and echo the main content of the mail to openssl-dev.) (Please note that I'm not a core developer, have no direct contact with any of the core developers, and am essentially only parroting what they have stated their preferences to be before.) -Kyle H On Thu, May 20, 2010 at 4:59 PM, Old Wolf oldw...@clear.net.nz wrote: In ssl_ciph.c there is a static STACK called ssl_comp_methods, and it is not possible to free the memory allocated to this stack (as far as I can tell). This isn't a big problem for normal applications as all allocated memory is freed when the process shuts down. However, I use OpenSSL in a Windows DLL which can be unloaded from a process (via the FreeLibrary system call), and when this happens, the memory used by ssl_comp_methods is never freed, so my DLL causes a slow leak over time if the host application repeatedly loads and unloads it. I have added a function to ssl_ciph.c which calls sk_SSL_COMP_free(ssl_comp_methods), and I call this function from my DLL's shutdown routine, and there are no more memory leaks reported by either of the leak-checking addons I use. Should I post my changes? NB. My shutdown code is currently: ERR_remove_state(0); CONF_modules_unload(1); EVP_cleanup(); CRYPTO_cleanup_all_ex_data(); ERR_free_strings(); SSL_COMP_free(); /* new function */ which is possibly slight overkill, but it works and I could not find anywhere clear in the OpenSSL documentation talking about exactly which cleanup functions need to be called (or what order to call them in). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2174] SSL_CTX_new SSL_OP_LEGACY_SERVER_CONNECT may clear previously set option
I think that line should be ret-options |= SSL_OP_LEGACY_SERVER_CONNECT;, not simply an =. -Kyle H On Wed, Feb 17, 2010 at 10:03 AM, Tomas Hoger via RT r...@openssl.org wrote: Hi! SSL_CTX_new currently contains: /* Setup RFC4507 ticket keys */ if ((RAND_pseudo_bytes(ret-tlsext_tick_key_name, 16) = 0) || (RAND_bytes(ret-tlsext_tick_hmac_key, 16) = 0) || (RAND_bytes(ret-tlsext_tick_aes_key, 16) = 0)) ret-options |= SSL_OP_NO_TICKET; followed by: /* Default is to connect to non-RI servers. When RI is more widely * deployed might change this. */ ret-options = SSL_OP_LEGACY_SERVER_CONNECT; So even if SSL_OP_NO_TICKET is set, it should be unset again due to a SSL_OP_LEGACY_SERVER_CONNECT default. Will SSL_OP_LEGACY_SERVER_CONNECT remain part of SSL_OP_ALL once SSL_OP_LEGACY_SERVER_CONNECT is no longer default? -- Tomas Hoger __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Get root certificates from System Store of Windows
If you're going to send a patch, please send it to r...@openssl.org. That gets the patch into the request tracker, and gets it into the (relatively) formal review process. -Kyle H On Thu, Jan 28, 2010 at 4:54 PM, NARUSE, Yui nar...@airemix.jp wrote: How about my previous patch, which lookup Windows' store with CryptoAPI. http://www.mail-archive.com/openssl-dev@openssl.org/msg27023.html thanks, -- NARUSE, Yui nar...@airemix.jp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta5 release v. VMS
Really, what needs to happen is that, in the case of VMS with a limited C compiler that doesn't handle long symbols, the long symbols need to be truncated in the *.num files. (This shouldn't need to be done for any other platform at this instant, but...) There's currently no conflict, so there's no current major issue -- but it's something the developers need to keep in mind, that there are arbitrary symbol length limits on at least one of the somewhat-supported platforms. -Kyle H On Fri, Jan 22, 2010 at 1:20 PM, Steven M. Schweda s...@antinode.info wrote: From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se I have applied the following changes: TITAN2_ZAY $ diff .cryptosymhacks.h [...] Plausible. (I'd bet that output from GNU diff would be more popular here.) TITAN2_ZAY $ diff .utillibeay.num [...] I didn't look closely at this. util/ssleay.num may be a better place for these things. It does a clean compile, but the functions can not be found in the library. [...] What I am doing wrong? Expecting any of this stuff to work easily? I'd guess that the new ssl/t1_reneg.c needs to be included in ssl/ssl-lib.com. Look for the scrambled mess of module names at LIB_SSL =. (Remember that these module names are in this disorder because this way it's so easy to update the list when it's changed. See how much that helped? But someday it'll all be automatic. I'm holding _my_ breath. You?) Any help would be highly appreciated as VMS community would like to have an usable and fully functional 1.0.0 release. WAKE UP! You're asleep and dreaming. I assume that these things need to be added to crypto/symhacks.h and/or util/libeay.num. Well, util/something.num. Probably. (Perhaps?) Steven M. Schweda s...@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta5 release v. VMS
On Fri, Jan 22, 2010 at 2:54 PM, Steven M. Schweda s...@antinode.info wrote: SSL_set_session_ticket_ext_cb 308 EXIST::FUNCTION: SSL_set1_param 309 EXIST::FUNCTION: SSL_CTX_set1_param 310 EXIST::FUNCTION: +ssl_add_clienthello_renegotiate_ext 311 EXIST:!VMS:FUNCTION: +ssl_add_clnthello_reneg_ext 311 EXIST:VMS:FUNCTION: +ssl_add_serverhello_renegotiate_ext 312 EXIST:!VMS:FUNCTION: +ssl_add_srvrhello_reneg_ext 312 EXIST:VMS:FUNCTION: +ssl_parse_clienthello_renegotiate_ext 313 EXIST:!VMS:FUNCTION: +ssl_parse_clnthello_reneg_ext 313 EXIST:VMS:FUNCTION: +ssl_parse_serverhello_renegotiate_ext 314 EXIST:!VMS:FUNCTION: +ssl_parse_srvrhello_reneg_ext 314 EXIST:VMS:FUNCTION: I changed the abbreviations a little from the first suggestions. I assumed that the !VMS things should be added. Someone who knows something may wish to revise that. I saw no other lower-case ssl_* things, which I find worrying. Lower-case ssl_* appears to be specifically related to the implementation of the secure renegotiation indicator extension. In any case, they are internal routines and shouldn't be exported at all, I should think, unless other extension parsing/adding code is exported. -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Get root certificates from System Store of Windows
My understanding is that OpenSSL doesn't really use the trusted certificate system, which contains the information about what a certificate is trusted for. Further, the bits available for the Windows store don't have an isomorphic mapping within the trust parameters that OpenSSL provides. Is there a spec on OpenSSL's trusted certificate architecture? Is there any guidance available on best practices to map from one to the other, or is that such a complex subject that it needs a full treatise? -Kyle H On Mon, Jan 11, 2010 at 4:38 PM, Dr. Stephen Henson st...@openssl.org wrote: On Mon, Jan 11, 2010, NARUSE, Yui wrote: (2010/01/10 23:23), Shahin Khorasani wrote: try this (snip) Thanks, it works. So I request X509_STORE_set_default_paths call this. When this is merge, both Unix user and Windows user can use the system's default root certificates. I should file this to Request Tracker as a bug? (even if this is feature request) Some CryptoAPI handling code already exists in the CryptoAPI ENGINE and I'd suggest that a ctrl for that would be the best place to put it. There are some debug options already that can dump a whole store to standard output. However some additional code would be needed because that just adds the whole store without any purpose setting code. This could cause security issues if for example client certificate authorities are used for server signing for example. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Test of disabled renegotiation in 0.9.8l
Er, *why* are you dropping the connection when renegotiation is tried? The appropriate response, per RFC, if you don't want to renegotiate is to send a warning no_renegotiation alert. -Kyle H On Mon, Nov 16, 2009 at 10:40 PM, joshi chandra joshichandran...@gmail.com wrote: Hi , I have lot patch from cvs of Openssl which will disable all the renegotiation and also will drop the connection if renegotiation is tried . This is the patch from the cvs http://cvs.openssl.org/chngview?cn=18791 http://cvs.openssl.org/chngview?cn=18794 http://cvs.openssl.org/chngview?cn=18795 As i am using this patch in older version of openssl (9.8h and 9.8k ). will this patch disable the renegotiation and also drop the connection if renegotiation is done . Thanks in Advance Joshi Lutz Jaenicke wrote: Boyle Owen wrote: PPS: Although I have subscribed to this list, I am not getting the mails (I have to keep checking the archives). Is there anyone who can check out my account? Hmm. If memory serves me right there was a subscribe message sent to the list instead of the mailing list manager (which I then moderated away)... Please try again, we do have some handy form on the web page. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/Test-of-disabled-renegotiation-in-0.9.8l-tp26301719p26385119.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2053] [PATCH] Add new -ext_print option to x509 app to print certificate extensions
How about something like '-certopt none,ext'? I'd like to see an option where 'none' automatically says 'no_header, no_sigdump, no_version, no_subject, no_issuer, no_validity, no_serial, no_pubkey, no_signame, no_ext', and anything after it is used to add to the set... rather like how ciphers are specified in the cipher string. -Kyle H On Fri, Sep 25, 2009 at 11:02 AM, Walter Goulet via RT r...@openssl.org wrote: if I rework this to an 'ext-only' option, would this be acceptable? I would prefer to improve the usability. On 9/25/09, Stephen Henson via RT r...@openssl.org wrote: [wgou...@gmail.com - Fri Sep 25 17:54:07 2009]: Hi, The following patch adds a new option, '-ext_print' to the x509 program which prints out the x509v3 extensions included in a certificate. The use case for this patch is that for users which use the command line program to parse and analyze certificates, it is useful to get the raw extensions to evaluate whether the certificate is correct for it's planned usage. The only way to programmatically do this without my patch is to print the entire certificate using the '-text' option then use a scripting tool such as perl or sed/awk to extract the extensions from the output. There is a way to do this using the -certopt option to turn off all options other than extensions as follows: openssl x509 -in ca-cert.pem -text -noout -certopt no_header,no_sigdump,no_version,no_subject,no_issuer,no_validity,no_serial,no_pubkey, no_signame This is of course rather cumbersome and could be made cleaner with something like ext_only. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_CTX
You may use an SSL_CTX object to create multiple sessions under multiple threads. Each session must have all of its I/O done in one thread (due to some rather nasty locking issues), but the SSL_CTX, once created and populated, is generally not updated -- which means that it's safe to perform read-only access to it, *iff* you aren't modifying it in another thread. If you do, you have to lock it, same as every other race condition. SSL_connect() does not corrupt memory contents. If it works, it simply has a file descriptor in the SSL structure, and possibly (if it connected and negotiated SSL/TLS) keying information in the same structure. Same with SSL_set_fd(), except that it associates an open file descriptor with the SSL session. SSL_library_init() is literally the same thing as OpenSSL_add_ssl_algorithms() and SSLeay_add_ssl_algorithms(). So, you're just going through the process of reregistering everything, but you shouldn't run into any major issues. (Note I haven't looked at the code at this point to verify.) -Kyle H On Mon, Sep 14, 2009 at 3:42 AM, svijay svi...@eiqnetworks.com wrote: Hello, -- Can we use single SSL_CTX object for multiple sessions at a time under multiple threads? -- Does SSL_connect() or SSL_set_fd() corrupts memory contents in any case? -- Can we call SSL_library_init() many times in a exe till it gets exited? Does it impact anything? I am using TLSv1. Thanks in advance. Thanks Regards, VijayKumar.S | Software Engineer *eIQnetworks®, Inc. | *www.eiqnetworks.com e. svi...@eiqnetworks.com rsvi...@eiqnetworks.com | b. http://blog.eiqnetworks.com/https://mail.eiqnetworks.com/exchweb/bin/redir.asp?URL=http://blog.eiqnetworks.com/ ** *We can honestly say that eIQnetworks has the broadest range of capabilities we’ve seen in one integrated product. - Technology Executive Alert By Linda Musthaler, Network World* image001.jpg
Re: A question about openssl command in FIPS mode
Because the 'fipsld' script isn't actually necessary to pass FIPS validation. The steps that that script does are necessary to maintain validation, but they can be done by anything (once the FIPS canister is created, anyway). Try setting OPENSSL_FIPS=1 in your environment, and make sure that the openssl commands do what they're supposed to. (md5 shouldn't work if OPENSSL_FIPS is set, for example.) -Kyle H On Fri, Sep 11, 2009 at 3:51 PM, Lin Hwang lhw...@lnxw.com wrote: Hi, I am an Openssl newby. Recently I am trying to build FIPS module and FIPS capable lib on a Linux system. I notice that all the fips_xxxtest programs at link time all go through fipsld and linked with a digest. I expect the same thing with application openssl, but I don't see it happens when I check the build log. When I run the command, it worked !! For example when I ran openssl version, it shows me OpenSSL 0.9.8j-fips 07 Jan 2009. Why there is no fingerprint, but it seems to pass FIPS_mode_set without problem? Lin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Delivering two version of libcrypto - fips and non-fips
It goes without saying that any changes you have to make to the FIPS module would be quite welcome if you passed them along upstream, along with any information about the Priesthood of the CMVP that you're dealing with which required the change, and why. Then again, I don't know if there's an NDA from the sponsor re the CMVP's actions, regardless of whether there's one from the CMVP to the sponsor re the sponsor's or CMVP's actions. -Kyle H On Tue, Sep 1, 2009 at 8:39 AM, Mark Phalanmark.pha...@sun.com wrote: On Tue, 2009-09-01 at 11:20 -0400, Steve Marquess wrote: Mark Phalan wrote: ... As you noted the incorporation of fipscanister.o in a FIPS capable OpenSSL displaces the corresponding FIPS allowed algorithms of the latter. While we retain functional equivalence (goal 1 above) any platform optimizations or other improvements of the newer implementations are lost. The nature of this interface is such that we can't easily avoid this displacement within the constraints of the existing fipscanister.o interface and 0.9.8 versioning rules. Do you think delivering two versions of libcrypto in this case is a reasonable workaround? It's the simplest solution in your case, even though it's the outcome our design hoped to avoid. Ok. I should also note that developments in FIPS 140-2 testing requirements for 2010 mean that even the existing v1.2 module will no longer be compliant. The commercial vendors who have been obtaining private label validations based on v1.2 will find that those validations will no longer be rubber stamp formalities as is the case today. Can you point me to more information about this? Does this mean that delivering a FIPS Capable OpenSSL (v1.2) as part of an OS will be essentially worthless to users of that OS in 2010? Well, I have a mixed track record in forecasting future CMVP actions so take my speculations accordingly. The CMVP typically does not revoke or invalidate extant validations simply because the criteria for new validations have changed (though I should note past OpenSSL FIPS Object Module validations have been effectively revoked). So presumably the current #1051 validation will remain in effect through 2010 for those electing to use it directly. Emphasis on presumably, as the OpenSSL open source based validations are *not* typical. So assuming you base your deliverables on already awarded validated products you *should* be OK. However, it has been common practice for vendors to take the same v1.2 source code and documentation and obtain their own copy-cat or private label validation. There are a number of practical and marketing reasons why such duplicate validations are desirable (minimizing the risk of exposure to the fate of validations #642 and #733 being first and foremost). Those copy-cat validations will no longer be possible with the as-is v1.2 source. At one point in time we thought that we would have, though sponsorships brokered by the Open Source Software Institute, long term funding for an ongoing series of periodic (annual or semi-annual) rolling validations. That would have maintained availability of a reasonably current product for direct use or as a model for private label use, and would also have allowed us to work in the desired architectural changes over several validations. Unfortunately that prospect fell through and at this point we have no plans for any future validations. Private label validations will continue but will require increasing amounts of modification to the v1.2 source code and documentation as the validation requirements are extended. We could merge those changes back into the shared baseline code and docs, but to date we have received very few contributions of that sort. So what is currently a community resource will gradually revert back to a roll-your-own situation, same as it was before the first open source based validation. Ok. Thanks for all the information. -M __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Delivering two version of libcrypto - fips and non-fips
You forgot: ./config fipscanisterbuild asm Since you're on an x86_64 platform, you can benefit a lot from the asm speedups. -Kyle H On Fri, Aug 28, 2009 at 2:48 AM, Mark Phalanmark.pha...@sun.com wrote: On Thu, 2009-08-27 at 10:23 -0400, Steve Marquess wrote: Mark Phalan wrote: I've been working on getting a FIPS Capable OpenSSL into OpenSolaris. Excellent, we designed the OpenSSL FIPS Object Module and the FIPS capable OpenSSL to enable just this sort of support in vendor O/S distros. One set of FIPS capable OpenSSL libraries shipped to all customers, with FIPS mode for the entire system enabled or not at runtime. Note the global configuration file and OPENSSL_config() call can be used for this purpose (see section 5.2 of http://openssl.org/docs/fips/UserGuide-1.2.pdf). Due to the way the FIPS Capable OpenSSL is built it ends up with older implementations of ciphers (all the ones that fipscanister.o implements). These cipher implementations are used regardless of being in FIPS mode or not. Ummm, not so. Use the OpenSSL FIPS Object Module v1.2 (the fipscanister.o part *only*, throw the rest away!) along with a current version of OpenSSL 0.9.8 for everything else. That way the old but validated crypto implementations in fipscanister.o are used in FIPS mode, the standard unvalidated (and current) ones in 0.9.8k+ are used when not in FIPS mode. This doesn't appear to be the case the way I build it... Here is a summary of how I built and tested the fips and non-fips versions on my Ultra 24 (Core2Duo Q9650 @ 3.00GHz): $ isainfo amd64 i386 openssl-fips-1.2 $ ./config fipscanisterbuild $ make # make install ... 0.9.8k-fips ./config fips shared make ... 0.9.8k ./config shared make Speed results: OpenSSL 0.9.8k 25 Mar 2009 built on: Fri Aug 28 10:36:58 CEST 2009 options:bn(64,64) md2(int) rc4(1x,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(ptr2) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -O3 -Wall -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 135063.79k 184065.92k 202569.47k 208250.88k 209704.28k aes-192 cbc 98324.28k 147109.23k 167682.30k 173344.43k 175494.49k aes-256 cbc 90383.17k 130776.13k 146193.92k 150772.74k 152103.59k OpenSSL 0.9.8k-fips 25 Mar 2009 built on: Fri Aug 28 10:35:09 CEST 2009 options:bn(64,64) md2(int) rc4(1x,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(ptr2) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -O3 -Wall -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 88270.08k 96227.86k 98987.43k 99352.58k 99543.72k aes-192 cbc 74932.78k 80559.13k 82352.64k 82683.56k 82952.90k aes-256 cbc 64523.70k 69436.15k 70589.18k 70931.49k 70934.53k Summary: AES is twice as slow when using the FIPS Capable libcrypto (note OPENSSL_FIPS wasn't set as doing so would cause an immediate assertion failure due to the use of non-FIPS approved ciphers) Digging in a little more: # openssl-0.9.8k $ ar t libcrypto.a |grep aes aes_misc.o aes_ecb.o aes_cfb.o aes_ofb.o aes_ctr.o aes_ige.o aes_wrap.o aes-x86_64.o e_aes.o # openssl-0.9.8k-fips $ ar t libcrypto.a |grep aes aes_misc.o aes_ctr.o aes_ige.o aes_wrap.o Clearly the FIPS Capable OpenSSL doesn't contain the same aes implementation as the non-FIPS one. truss(1) shows the FIPS Capable OpenSSL calling _x86_64_AES_encrypt_compact and the non-FIPS one calling _x86_64_AES_encrypt. I believe this is correct as when building in FIPS mode util/arx.pl will exclude the cipher implementations so that when fipscanister.o is included in the library there are no symbol conflicts. (See FIPSCANLIB in Configure and EXCL_OBJ in the top-level Makefile). e.g. from fipscanister.o: $ nm fipscanister.o |grep _x86_64_AES_encrypt [308] | 91008| 483|FUNC |LOCL |0 |2 |_x86_64_AES_encrypt .. from the aes object file: $ nm aes-x86_64.o |grep _x86_64_AES_encrypt [4] | 0| 507|FUNC |LOCL |0 |1 |_x86_64_AES_encrypt I've read the user guide and security policy a number of times and I don't believe that I've built this incorrectly. Please correct me if I'm wrong :) The FIPS capable build process is discussed in the User Guide document
Re: [PATCH] SHA512 ROTR macro fix for PowerPC using LP32 model
Don't worry 'bout it too much.
Could you please create that as a .diff file and attach it to an email
to r...@openssl.org? The rt system creates a case that can be tracked.
-Kyle H
On Mon, Jul 27, 2009 at 3:26 PM, Ben Nasonbna...@netflix.com wrote:
Hi,
I am new to the list, so apologies if I fail to follow any of the ground
rules.
I just ran into a bug where SHA384/512 were not being calculated
correctly on the Cell processor. I tracked it down to the definition of
the ROTR macro, which is assuming a 64 bit long, but in this case the
compiler is using the LP32 model so long is 32 bits and the values were
being truncated. Here is the patch I did that fixes the problem:
--- sha512.c 2009-07-27 15:04:52.546574000 -0700
+++ sha512.c 2009-07-27 15:08:07.373452100 -0700
@@ -344,7 +344,7 @@
((SHA_LONG64)hi)32|lo; })
# endif
# elif (defined(_ARCH_PPC) defined(__64BIT__)) ||
defined(_ARCH_PPC64)
-# define ROTR(a,n) ({ unsigned long ret; \
+# define ROTR(a,n) ({ SHA_LONG64 ret; \
asm (rotrdi %0,%1,%2 \
: =r(ret) \
: r(a),K(n)); ret; })
If it is desirable to not use SHA_LONG64 in the macro, another option
would be to test for the __LP32__ preprocessor symbol and use unsigned
long long when that is defined.
I am using OpenSSL 0.9.8k, but looking at the latest snapshot it seems
this problem has not been fixed yet.
Questions or feedback welcome.
Thanks,
Benbuck Nason
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [PATCH 00/14] Patches from the ocf-linux and uClinux-dist projects
Please mail these each as attachments to r...@openssl.org. This will ensure that each gets entered into a trackable state, and also ensures that the formatting for the patch files stays consistent. -Kyle H On Mon, Jun 29, 2009 at 7:54 PM, David McCulloughdavid_mccullo...@securecomputing.com wrote: Hi openssl-dev, Here is a series of patches against the openssl-SNAP-20090628 release. The patches fix a number of bugs and also add functionality from the ocf-linux and uClinux-dist projects. ocf-linux is a linux port of the OCF framework from BSD. The project has been running since 2004. uClinux-dist is a full source distribution thats allows for easy cross compilation for many different CPU/platform/vendor combinations, including both systems with and without MMUs. It has been running since before 2002. I have split the patches up into small unit changes so that they are easier to review and apply. Most if not all of the patches can be used in isolation against a current openssl source tree. Please let me know if there are any issues or if some other format is preferred, Thanks, Davidm ocf-linux: http://ocf-linux.sourceforge.net/ uClinux-dist: http://www.uclinux.org/pub/uClinux/dist/ -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Request from THALES to OPEN SSL
OpenSSL is distributed under a clause in US law which allows openly-available cryptographic software to be exempt from ECCN filing, under exemption TSU (EAR, section 740.13(e)). It is very possible that what you are doing with it falls under ECCN 5D002 or another in the 5Dnnn series. I am not a lawyer, I'm simply going by what the exemption says. -Kyle H On Mon, Jun 29, 2009 at 5:30 AM, patrick doudementpatrick.doudem...@thalesgroup.com wrote: Hi, Within the framework of our Export Control survey activity for components of THALES equipments, and in order to update our databases, and in order to comply with the export regulation, we need to know the applicable Export Control Code and ECCN (Export Control Classification Number) code for the following product : OPENSSL 0.9.8J Thank you in advance for your fast answer. Regards. P. Doudement -- The information contained in this e-mail/fax and any attachments are the property of THALES and may be confidential. If you are not the intended recipient, please notify us immediately, send this message back to us and destroy it. You are hereby notified that any review, dissemination, distribution, copying or otherwise use of this e-mail/fax is strictly prohibited. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [OpneSSL On MAC OS] How to build the openssl.0.9.8k zlib ?
To get zlib, use MacPorts. Then, './config --with-zlib=/opt/local/lib/'. MacOS already has a supplicant, though, yes? -Kyle H On Tue, Jun 23, 2009 at 7:28 PM, loubotloubot.l...@quantatw.com wrote: I have port the supplicant with openssl.0.9.8k on Linux platform, and it's working ok. I test the supplicant with openssl.0.9.8k on MAC OS. It always fail on the send ClientKeyExchange message to AAA. I think that my building openssl.0.9.8k process is error. Please, let me know how to build openss.0.9.8k on MAC OS 10.4. BR Loubot -- View this message in context: http://www.nabble.com/-OpneSSL-On-MAC-OS--How-to-build-the-openssl.0.9.8k-zlib---tp24177657p24177657.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Possible error in the Book?
The PrivateKey structure includes both the private and the public parts. Once you read the private key, you don't need to separately load the public. -Kyle H On Thu, Jun 18, 2009 at 3:36 AM, Vadim Lebedevva...@mbdsys.com wrote: Hello, I wonder if somebody can enlighten me: At Page 283 of Network Security with OpenSSL book there is example of generation of certificate request. And there is a code sequence seems to be strange: We read a PRIVATE key from a file using PEM_READ_PrivateKey and than we add it as a PUBLIC Key to the request X509_REQ_Set_pubkey and later yet we use the same private key to sign the request... I would think that we need to read a PUBLIC key from somewhere and use it as public key for the requset Tanks Vadim __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl-0.9.8k ./Configure --test-sanity got failed
openssl-1.0.0-beta2 has the following output: == === SANITY TESTING! === No configuration will be done, all other arguments will be ignored! == SANITY ERROR: 'beos-x86-bone' has the dso_scheme [21] field = beos valid values are 'dl', 'dlfcn', 'win32' and 'vms' SANITY ERROR: 'beos-x86-r5' has the dso_scheme [21] field = beos valid values are 'dl', 'dlfcn', 'win32' and 'vms' -Kyle H On Wed, Jun 17, 2009 at 1:10 AM, Guan Jun Heg...@novell.com wrote: Dear everyone I got the openssl-0.9.8k package from openssl.org, then I run the command './Configure --test-sanity',and I got the following error, g...@macintyre:~/project/stable/openssl-0.9.8k ./Configure --test-sanity == === SANITY TESTING! === No configuration will be done, all other arguments will be ignored! == SANITY ERROR: 'debug-steve-opt' has the dso_scheme [18] values in the following field SANITY ERROR: 'debug-steve64' has the dso_scheme [18] values in the following field it seems that there is something wrong in the Configure file. is there a patch to fix this? thanks a lot, Guanjun
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
These scripts pull the latest version of the Mozilla-approved CAs. OpenSSL is not in the business of making CA certificates available, but having the ability to do this in the stock package might be very good for the users. (Make sure that such a tool warns the user that the CA certificates are those made available by Mozilla, not the OpenSSL team, and that there's no warranty from OpenSSL on their use or misuse, such as not checking the hashes against the official locations for each CA.) -Kyle H On Mon, Jun 15, 2009 at 4:31 PM, Guenterli...@gknw.net wrote: Hi, Roumen Petrov schrieb: In the past we can download a file with CA certificates ( ca-bundle.crt.tar.gz ) from mod_ssl site. Now file is removed but it contain more then 90 certificates (PEM format concatenated together). many use the Perl script I've hacked for cURL to create a ca-bundle.crt: http://curl.haxx.se/lxr/source/lib/mk-ca-bundle.pl I've also hacked a WSH script for Win32 users who might not have Perl: http://www.gknw.net/vb/scripts/mk-ca-bundle.vbs and also a PHP commandline version: http://www.gknw.net/php/phpscripts/mk-ca-bundle.phps I'm fine with contributing any of these scripts to the OpenSSL project if there's any interest. Günter. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL code on Windows crashes.
Please, read INSTALL.W32. Also, please read http://openssl.org/support/faq.html#PROG2 for more information. (This is one of the most frequently asked questions.) If you can, build OpenSSL yourself. This may not necessarily be practical for you, but if you can it should help a lot. -Kyle H On 6/12/09, patfla p...@well.com wrote: Hi - I'm looking to eventually wrap OpenSSL in Eiffel - the OO language that we use in house. So testing out various things. We're on Windows. I downloaded the Windows port of OpenSSL from here: http://www.slproweb.com/products/Win32OpenSSL.html (and sent the author some money via paypal as requested). Found some sample and simple C code that uses the OpenSSL api here: http://www.rtfm.com/openssl-examples/ From here. To build, I needed to modify the first lines of the example code's Makefile as follows: OPENSSLDIR=c:/openssl32 CFLAGS=-g -I$(OPENSSLDIR)/include LD=-Lc:/openssl32/lib -llibeay32 -lssleay32 I sent these Windows mods to the author - no reply. With this change to the Makefile the programs appear to compile and link without error using the cygwin Windows tools. I run 'mserver'. There are 3 client variants: pclient, rclient and sclient. I run pclient (against mserver) on the same machine. Mserver listens on port 4433. Pclient, looking in the code, seems to proxy somehow. I run it against mserver and pclient returns saying 'couldn't connect socket'. sclient returns with no message. rclient provokes a trace from mclient: D:\OpenSSL\examples\onemserver 8219 [main] mserver 3044 _cygtls::handle_exceptions: Error while dumping stat e (probably corrupted stack) but mserver is still running. So what do I make of this all? Not sure - I'm totally new to SSL. Have written tcp/ip socket based programs before but, as I said, don't yet have a sense of the SSL landscape. There isn't a README or instructions with the example code. What little I've learned so far is from reading the code. Which obviously I'll do more of. It seems that the book to get, even though it's old, (and in particular for the OpenSSL API) is the following: http://www.amazon.com/Network-Security-with-OpenSSL/dp/B0028N4W3I/ref=sr_1_1?ie=UTF8s=booksqid=1244829250sr=8-1 Which I'll get shortly but don't have yet. -- View this message in context: http://www.nabble.com/OpenSSL-code-on-Windows-crashes.-tp24003641p24003641.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Can we expect debug version libraries of Openssl code to vs2005?
The pre-built OpenSSL library is provided by someone else. If you want to get debug libraries for OpenSSL, you can compile them yourself. Please see the FAQ, however; there are a couple of gotchas on Windows systems which need to be addressed within your environment during the compilation and test cycles. -Kyle H On Thu, May 21, 2009 at 5:54 AM, satyanarayana.va...@netenrich.com wrote: Hi Development Team, How can we get debug version libraries of Openssl code? VS2005 is giving follow linker error while compiling lib-curl code with openssl library files in debug mode. 1-- Build started: Project: curl-7.15.5, Configuration: Debug Win32 -- 1Linking... 1LIBCMT.lib(calloc.obj) : error LNK2005: _calloc already defined in LIBCMTD.lib(dbgheap.obj) 1LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library 1Debug\curl-7.15.5.exe : fatal error LNK1169: one or more multiply defined symbols found 1Build log was saved at file://f:\source\VS2005\Agent\thirdparty\Copy (2) of curl-7.15.5\Debug\BuildLog.htm 1curl-7.15.5 - 2 error(s), 1 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == VS2005 is building lib-curl code successfully with openssl library files. However that executable failed to write (curl_write) in https – post method. Is there any issue to compile openssl lib with vs2005? Thanks, Satya. -- Confidentiality And Disclaimer Notice Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ……www.netenrich.com - __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Source interfaces for implementing a new algorithm
Hey all, I'm trying to figure out (for my own reference) what functions I need to provide for: 1) Implementing a new stream cipher 2) Implementing a new block cipher 3) Implementing a new asymmetric cipher 4) Implementing a new hash 5) Implementing a new mode (ECB, CFB, etc) 6) Implementing a new TLS extension 7) Implementing a new TLS authentication mechanism I'd also like to know what functions I need to call for: 8) Extracting data from the current SSL connection to be provided externally, to things which require those (such as the wpa_supplicant issue). I also would like to know what macros need to be called, and where, for these new things to be registered in the codebase. OpenSSL is the most Lisp-ish C project I've ever seen (with a fairly close second being the PGP 2.0 - 2.6.2 codebase). This means that most of the assumptions that are usually made about the language are violated by the heavy use of macros to do various things that normally are in the programmer's purview. Thank you for your time. -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Confused by OpenSSL
This is actually an openssl-users question, but don't worry too much about it. :) genrsa generates both the public and the private keys in the same structure (PKCS#1). The command 'openssl rsa -in domainname.key -pubout -out domainname.pub' will take the portion that has been designated as the private key out of the structure written into domainname.pub. As a matter of implementation, OpenSSL stores the private key and the public key together in the same structure. -Kyle H On Thu, Apr 30, 2009 at 9:23 AM, dadhikra dadhi...@gmail.com wrote: Hello all, I am new to openssl, so please go easy on me if you find my question stupid. But I am really confused by openssl documentation. my question is regarding the generation of CSRs i.e. Certificate Signing Requests. As per the documentation, here is one way to generate a CSR Following command generates a private key stored in a file called domainname.key (1) openssl genrsa -out domainname.key 1024 And the following command generates a CSR, which stores the public key and the information about the company in the file called domainname.csr (2) openssl req -new -key domainname.key -out domainname.csr Now, from whatever I know about the public key cryptography, it is not possible to generate private key from the public key and vice versa. Both the keys can only be generated together through some algorithm. And there is no fundamental difference between the two keys. Any key from the pair can be designated as a public key and the counterpart as the private key. So what is happening here is that we are generating public key from the private key in command no (2). (Remember, public key is stored in domainname.csr). So if that is the case, then we can also generate private key given a public key. This is bizarre. Obviously I am missing something here. My only guess is that the file domainname.key as generated by command (1) stores BOTH public and private keys. That will make the whole game logical. Of course openssl documentation doesn't say so. So can somebody please explain the logic behind these commands. Or at least can somebody please confirm my observation? -- View this message in context: http://www.nabble.com/Confused-by-OpenSSL-tp23319693p23319693.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Issues with CMS for SMIME implementation using OPENSSL source code
Most of the OpenSSL functions and structures are generated by macros. (OpenSSL is the most lispish C I've ever seen.) Look at apps/cms.c for information on how to use them; in its basic configuration, it has no dependencies on anything external. (It can be built to have dependencies on external things, including zlib, but those are not built by default.) -Kyle H On Sat, Apr 18, 2009 at 9:20 AM, anoopg anoop.gu...@gmail.com wrote: Hi, I want to use the OpenSSL source code for SMIME implementation.I downloaded the latest complete trunk of openSSL source code (openssl-1.0.0-beta1.tar.gz ) and then built it and installed the binaries.Build is through but, I am not able to find the definitions/prototypes of some of the functions used for CMS encryption for SMIME. E.g. CMS_ContentInfo_new(),CMS_ContentInfo_free(cms),X509_* and lots of other structs. I checked the downloaded source code using md5 and it is the complete source code.I want to know whether the OPENSSL source code has got any external dependency on any other library. I am confused because in the website of OpenSSL, then have given one command line interface options to test SMIME. Any help in this regard will be highly appreciated. Regards, Anoop -- View this message in context: http://www.nabble.com/Issues-with-CMS-for-SMIME-implementation-using-OPENSSL-source-code-tp23110079p23110079.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1830] [PATCH] TLS Key Material Extractor
http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-05.txt is the current draft, and its name has now been changed to tls exporter. -Kyle H On Thu, Jan 29, 2009 at 4:30 AM, Robin Seggelmann via RT r...@openssl.org wrote: This patch adds the TLS key material extractor described in http:// www.ietf.org/internet-drafts/draft-ietf-tls-extractor-03.txt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released
I'd prefer that IBM release whatever library they're using to identify and handle Julian days. ;) -Kyle H On Thu, Apr 2, 2009 at 12:17 PM, Michael Tüxen michael.tue...@lurchi.franken.de wrote: Hi Steve, Robin will port all the patches from http://sctp.fh-muenster.de/dtls-patches.html to the beta version when he is back from vacation early next week. Regarding gettimeofday(): It is pretty common on Unix systems, not sure about Windows. But we can use any other function which allows us to get the current time. Any preferences? Best regards Michael On Apr 1, 2009, at 2:09 PM, Dr. Stephen Henson wrote: On Wed, Apr 01, 2009, Michael Txen wrote: Dear OpenSSL Project Team, are the DTLS related patches sent by Robin incorporated? The patches have been reviewed by the original author of the DTLS implementation and his comments have been incorporated. We also have successfully done an intop test with Certicom. No they haven't yet. I started looking at a few relevant tickets PR#1827, PR#1828 are broken patches, looks like line-wrap issues. PR#1829 I'm not sure about: how portable is gettimeofday()? Please update tickets with working patches against 1.0.0-beta1. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl doubt SSL_Write
If SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE are returned, the arguments *must* be *exactly* the same. This includes the data pointed to by the buffer. There is a way to set a mode on the SSL connection to allow a moving buffer, but that's it. SSL will not buffer the data passed to it. If SSL_write returns SSL_ERROR_WANT_READ, then just call SSL_write again. (Usually, in this case, you can select() on the underlying socket to determine if there's any pending data to be read from the socket.) If SSL_read returns SSL_ERROR_WANT_WRITE, just call SSL_read again. (You might try to select() to see if the socket is writable.) -Kyle H On Tue, Mar 31, 2009 at 10:50 AM, Balaji Kannadassan balaj...@nortel.com wrote: Hi All! I've have some doubts regarding SSL_write in non blocking mode.. 1. if SSL_write returned SSL_ERROR_WANT_WRITE, it is mentioned that the call has to be repeated with the same arguments. Does this means the same buffer to be used again?? or the data passed in the initial SSL_write call will be buffered by the SSL layer? 2. In case of SSL_write returning SSL_ERROR_WANT_READ due to re-negotiation, What are the steps to be followed? Is there any wait needed before the repeated SSL_write call? Does the application need to take care of the re-negotiation? Does the application need to wait for the re-negotiation to complete before repeating the SSL_write? Thanks in advance Balaji Kamal Kannadassan __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Fix RSA blinding locking hole
Submit your patch to r...@openssl.org, and it'll go into the request tracking system. I would also recommend that you wait for a bit more than a single day before getting irritated with people who work on this in their spare time, and have day jobs. -Kyle H On Wed, Apr 1, 2009 at 1:48 AM, Marc Haisenko haise...@comdasys.com wrote: Forgive my frustration, but which god do I need to sacrifice to to get some attention ? Even a go away, we don't care would be OK... Marc -- Marc Haisenko Team Leader and Senior Developer Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Fix RSA blinding locking hole
I'm only seeing two, the one with the patch and the one with the what god do you have to sacrifice?. However, that doesn't mean much of anything, as I'm horrible with managing my emails. r...@openssl.org is the best place to send patches, as it creates a ticket in the Request Tracking system that is used by the core developers. -Kyle H On Wed, Apr 1, 2009 at 1:59 AM, Marc Haisenko haise...@comdasys.com wrote: On Wednesday 01. April 2009 10:54:39 Kyle Hamilton wrote: Submit your patch to r...@openssl.org, and it'll go into the request tracking system. I would also recommend that you wait for a bit more than a single day before getting irritated with people who work on this in their spare time, and have day jobs. -Kyle H Thanks, I'll do. I'm not frustrated that I didn't a response to my patch but no response to the whole issue which I reported almost two weeks ago. I am enough of a open source veteran to know you can't expect immediate responses but four e-mails and no response is frustrating. Marc -- Marc Haisenko Team Leader and Senior Developer Comdasys AG Rüdesheimer Str. 7 80686 München Germany Tel.: +49 (0)89 548 433 321 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Fix RSA blinding locking hole
On Wed, Apr 1, 2009 at 2:12 AM, Marc Haisenko haise...@comdasys.com wrote: On Wednesday 01. April 2009 11:03:55 Kyle Hamilton wrote: I was refering to the two threads cited in my patch e-mail: [1] - http://marc.info/?l=openssl-devm=123754568501758w=2 [2] - http://marc.info/?l=openssl-usersm=123788810006272w=2 Due to a lot of problems in current web browsers (Firefox 3.0.7 had a critical flaw in some component or other, and I would prefer my machine not get pwned :) ), I tend not to go to unknown sites. This mailing list is archived on Nabble, and it's likely that you'd get more folk to look if you linked there. r...@openssl.org is the best place to send patches, as it creates a ticket in the Request Tracking system that is used by the core developers. Alright. Maybe it would be a good idea to document that on the openssl.org homepage, because before I submitted my patch I was searching the site for guidelines on how the project wants to have patches submitted, to no avail. There is no mentioning of a Request Tracker either (or maybe I'm blind) :-) It's actually under Support on the left side, then Request Tracker at the top. I agree, the site could use a major redesign to be more useful. (Right now, it's obfuscated, probably to prevent people from abusing it.) The people who give base-level support don't generally get RT accounts. (I don't have one, for example.) It's my thought that RT is primarily used for the developers, rather than trying to delegate support requests -- probably because nobody's getting paid for this (except the developers, and then only because of support from companies that want more features -- like Google, apparently most recently, if the 0.9.9 changelog is any indication). :) -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
I hope the reports that I sent to -bugs are useful...
I hope the test reports I sent to -bugs are useful. I'm on a Mac OSX 10.5.6 machine, Intel-based, and I ran tests in both 32 and 64 bit modes, both without and with the optional features. I do not have gmp installed, nor zlib, so I cannot vouch for their usability; I did not test krb5, and I also did not test the shared option. I'll happily run any other tests that you may feel useful or necessary. (Have I said thank you for working on such a usually-thankless project recently? If I haven't, thank you.) -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: I hope the reports that I sent to -bugs are useful...
On Wed, Apr 1, 2009 at 4:55 AM, Lutz Jaenicke l...@lutz-jaenicke.de wrote: Hi Kyle, thank you very much for reports, they are currently sitting in the moderation queue. I would kindly ask you and other testers to either * send success messages to the list with just the platform mentioned * send failures to openssl-bugs (or rt which is an alias) with a suitable subject line exposing the platform and type of problem Re: OpenSSL 1.0.0 beta1 released is not too useful as it will end up in many open tickets all having the same non-informative subject. Thank you very much, Lutz Hi Lutz, The problem with 'just the platform mentioned' is that there are two separate types of platforms on OSX -- 32 bit and 64 bit. I tested the default configuration on each. In addition, I also tested the experimental-jpake, enable-rfc3779, experimental-store, and basically all the other options I had available, in separate tests (both 32- and 64-bit). I'd figured that you'd have the ability to parse the configuration lines so that you could identify the options in use, the platform, and any combination which resulted in a test failure -- and that more information would be easier to diagnose problems with than less. Which list should I send success reports to? The body will need to include the compiler, the Configure options, and platform at the very least; that's a bit too much to fit into an appropriate Subject. (Or am I taking the concept of a proper, comprehensive test matrix too seriously for the OpenSSL team's liking?) -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify
This list is *not* supposed to be a platform for trying to sell product. Or even advocating for product. You come in here, complaining about how a particular feature used in one of the libraries breaks one of your instrumentation programs. Okay, fine. We'll try to work with you on that. But now you're putting the onus of testing against your product on the OpenSSL team? NOT FINE. NOT OKAY. If you're not familiar with the particular problem space, hand the problem off to someone else as IBM who is. Let *them* deal with it. The OpenSSL team has more than enough to do. And, they're all volunteers. If IBM wants to contract with individual members of the team to verify proper operation of your instrumentation library with the team's code, that's IBM's purview. But, TANSTAAFL, especially when there's a profit motive for the entity asking favors of the non-profit team. -Kyle H On Tue, Mar 31, 2009 at 2:26 PM, Allan K Pratt apr...@us.ibm.com wrote: The call8/add sequences in the new changes look like they should be no problem. Sorry to be so picky about not recognizing call8/sub. As for the PPC implementation, I'm not in a position to judge it. PurifyPlus runs on PPC with AIX (no Power Linux at this time), but I'm not familiar with PPC assembly code or the PIC patterns our recognizer supports. However, as you now know, anything labeled as an ugly hack (as LPICmeup is) will be suspect. On AIX there is a feature that lets users exclude entire libraries, so if a customer has a problem with libcrypto they could just exclude it from Purify processing. When you exclude a library on AIX we don't instrument it at all. Naturally, this means we can't report memory errors that originate in that library, even if the root cause of the error is API abuse on the part of the caller. But at least the customer gets full checking on the rest of their program. (That feature is still experimental on Solaris and Linux, not yet fully supported.) Would you care to try it yourself? You can get a trial version of PurifyPlus for free and run it on your libcrypto test programs. This will tell you if we patched things correctly. The eval version is limited functionality: it works the same way and reports the same errors as the full version, but doesn't give pinpoint accuracy in error reports. You don't see line numbers or complete call chains like you do with the full version. (For that we ask you to pay.) There's a big Download trial button here: http://www-01.ibm.com/software/awdtools/purifyplus/unix ... installing the trial is very easy, no need to set up a license server or any nonsense like that. -- Allan Pratt, apr...@us.ibm.com Rational software division of IBM __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP help required
OCSP is not part of the SSL handshake (except, as you mention, for OCSP stapling). You can look at apps/ocsp.c for information on how to use the OCSP API. The best place to use it would be in the callback called by SSL[_CTX]_set_verify(). -Kyle H On Sun, Mar 29, 2009 at 11:02 PM, Yaweh anujgupta...@gmail.com wrote: Hi, Is OCSp implemented as a part of SSL handshake or do i need to implement the functionality myself i.e. calling the api to send the request and check the response like the way it has been done in the apps?? i see some ocsp related code while ssl handshake is being done. it looks like its for OCSP stapling. Could you provide a breif idea abt how to add OCSP support to the application (client). Currently we use OpenSSl for ssl support thanks, anuj -- View this message in context: http://www.nabble.com/OCSP-help-required-tp22776849p22776849.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Why patch was forgotten?
The best way to submit patches is to email them as attachments to r...@openssl.org. That is the Request Tracker, and it makes things a lot easier for the developers to keep track of. -Kyle H On Thu, Mar 26, 2009 at 2:59 AM, Ilya O. vrgh...@gmail.com wrote: On Wed, Mar 25, 2009 at 5:37 PM, Patrick Patterson ppatter...@carillonis.com wrote: Did you submit it to the Bug Tracking system? No. I am sorry for inconvenience. I thought that mailing here would be enough at least to get feedback on what should be done for patch to be applied. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: how to uninstall openSSL Urgent help needed
This is a -users question, not a -dev question. If openssl was installed from a package provided by or in the format of your OS vendor, uninstall it using the vendor's packaging tools. I've attached a list of files that are installed on my MacOSX machine by 'make install'. (the './' at the beginning of each line refers to the $prefix that was used to configure it.) Note that OSX's dynamic libraries have a '.dylib' suffix, rather than a '.so' suffix on other machines. You may or may not have dynamic libraries, but it's something you should look into. Anyway, to uninstall it, just get rid of the files named herein. However, if you have linked anything against any dynamic version of the library, and remove it, those things will no longer work. (They will fail with 'unresolved reference' or 'dynamic library not found' error.) -Kyle H On Thu, Mar 26, 2009 at 2:42 PM, Srinivas Jonnalagadda sarinivas7...@earthlink.net wrote: Hi, I would like to know how to uninstall openssl from my unix machine. Thanks, Srinivas Jonnalagadda __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org ./bin ./bin/c_rehash ./bin/openssl ./include ./include/openssl ./include/openssl/aes.h ./include/openssl/asn1.h ./include/openssl/asn1_mac.h ./include/openssl/asn1t.h ./include/openssl/bio.h ./include/openssl/blowfish.h ./include/openssl/bn.h ./include/openssl/buffer.h ./include/openssl/cast.h ./include/openssl/comp.h ./include/openssl/conf.h ./include/openssl/conf_api.h ./include/openssl/crypto.h ./include/openssl/des.h ./include/openssl/des_old.h ./include/openssl/dh.h ./include/openssl/dsa.h ./include/openssl/dso.h ./include/openssl/dtls1.h ./include/openssl/e_os2.h ./include/openssl/ebcdic.h ./include/openssl/ec.h ./include/openssl/ecdh.h ./include/openssl/ecdsa.h ./include/openssl/engine.h ./include/openssl/err.h ./include/openssl/evp.h ./include/openssl/hmac.h ./include/openssl/idea.h ./include/openssl/krb5_asn.h ./include/openssl/kssl.h ./include/openssl/lhash.h ./include/openssl/md2.h ./include/openssl/md4.h ./include/openssl/md5.h ./include/openssl/obj_mac.h ./include/openssl/objects.h ./include/openssl/ocsp.h ./include/openssl/opensslconf.h ./include/openssl/opensslv.h ./include/openssl/ossl_typ.h ./include/openssl/pem.h ./include/openssl/pem2.h ./include/openssl/pkcs12.h ./include/openssl/pkcs7.h ./include/openssl/pq_compat.h ./include/openssl/pqueue.h ./include/openssl/rand.h ./include/openssl/rc2.h ./include/openssl/rc4.h ./include/openssl/ripemd.h ./include/openssl/rsa.h ./include/openssl/safestack.h ./include/openssl/sha.h ./include/openssl/ssl.h ./include/openssl/ssl2.h ./include/openssl/ssl23.h ./include/openssl/ssl3.h ./include/openssl/stack.h ./include/openssl/store.h ./include/openssl/symhacks.h ./include/openssl/tls1.h ./include/openssl/tmdiff.h ./include/openssl/txt_db.h ./include/openssl/ui.h ./include/openssl/ui_compat.h ./include/openssl/x509.h ./include/openssl/x509_vfy.h ./include/openssl/x509v3.h ./lib ./lib/engines ./lib/engines/lib4758cca.so ./lib/engines/libaep.so ./lib/engines/libatalla.so ./lib/engines/libcapi.so ./lib/engines/libchil.so ./lib/engines/libcswift.so ./lib/engines/libgmp.so ./lib/engines/libnuron.so ./lib/engines/libsureware.so ./lib/engines/libubsec.so ./lib/libcrypto.0.9.8.dylib ./lib/libcrypto.a ./lib/libcrypto.dylib ./lib/libssl.0.9.8.dylib ./lib/libssl.a ./lib/libssl.dylib ./lib/pkgconfig ./lib/pkgconfig/libcrypto.pc ./lib/pkgconfig/libssl.pc ./lib/pkgconfig/openssl.pc ./ssl ./ssl/certs ./ssl/man ./ssl/man/man1 ./ssl/man/man1/asn1parse.1 ./ssl/man/man1/ca.1 ./ssl/man/man1/CA.pl.1 ./ssl/man/man1/ciphers.1 ./ssl/man/man1/crl.1 ./ssl/man/man1/crl2pkcs7.1 ./ssl/man/man1/dgst.1 ./ssl/man/man1/dhparam.1 ./ssl/man/man1/dsa.1 ./ssl/man/man1/dsaparam.1 ./ssl/man/man1/ec.1 ./ssl/man/man1/ecparam.1 ./ssl/man/man1/enc.1 ./ssl/man/man1/errstr.1 ./ssl/man/man1/gendsa.1 ./ssl/man/man1/genrsa.1 ./ssl/man/man1/md2.1 ./ssl/man/man1/md4.1 ./ssl/man/man1/md5.1 ./ssl/man/man1/mdc2.1 ./ssl/man/man1/nseq.1 ./ssl/man/man1/ocsp.1 ./ssl/man/man1/openssl.1 ./ssl/man/man1/passwd.1 ./ssl/man/man1/pkcs12.1 ./ssl/man/man1/pkcs7.1 ./ssl/man/man1/pkcs8.1 ./ssl/man/man1/rand.1 ./ssl/man/man1/req.1 ./ssl/man/man1/ripemd160.1 ./ssl/man/man1/rsa.1 ./ssl/man/man1/rsautl.1 ./ssl/man/man1/s_client.1 ./ssl/man/man1/s_server.1 ./ssl/man/man1/s_time.1 ./ssl/man/man1/sess_id.1 ./ssl/man/man1/sha.1 ./ssl/man/man1/sha1.1 ./ssl/man/man1/smime.1 ./ssl/man/man1/speed.1 ./ssl/man/man1/spkac.1 ./ssl/man/man1/verify.1 ./ssl/man/man1/version.1 ./ssl/man/man1/x509.1 ./ssl/man/man3 ./ssl/man/man3/ASN1_generate_nconf.3 ./ssl/man/man3/ASN1_generate_v3.3 ./ssl/man/man3/ASN1_OBJECT_free.3 ./ssl/man/man3/ASN1_OBJECT_new.3 ./ssl/man/man3/ASN1_STRING_cmp.3 ./ssl/man/man3/ASN1_STRING_data.3
Re: A trace appearred on the screen which was not expected when using SFTP.
There is no such message in OpenSSL. That looks like it's a diagnostic message from libcurl (or whatever component it uses to perform its FTP functionality.) -Kyle H 2009/3/18 曹婷 bupt_caot...@hotmail.com: Hi developer, OPENSSL_0.9.8A_AIX5.3_64BIT is the version installed on my working server. Recently, i using libcurl to execute SFTP to do file rename on remote server. for example, the command is rename a.cpp to b.cpp then after calling curl_easy_perform, the trace data: rename a.cpp to b.cpp would appear on the screen. At the beginning, i thought that maybe the problem from libcurl, but after checking its source code, i found it was not its fault. So i only doubt now is that the problem from underlying SFTP. So could you please confirm whether the problem is from OPENSSL package? Thanks Christy 更多热辣资讯尽在新版MSN首页！ 立刻访问！ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify
You need to get off your high-horse. -Kyle H On Mon, Mar 16, 2009 at 2:23 PM, Kenneth Robinette supp...@securenetterm.com wrote: You need to take this discussion offline. Ken --- On Mon, 3/16/09, Allan K Pratt apr...@us.ibm.com wrote: From: Allan K Pratt apr...@us.ibm.com Subject: Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify To: openssl-dev@openssl.org Date: Monday, March 16, 2009, 3:49 PM And the only difference would be to relax pattern recognition so that delay slot is examined for %o7-based arithmetic for all call instructions, not only call .+8 in particular. Is this correctly understood? Yes, you correctly understand this. But it's not as easy as that. I don't need to get into Purify implementation details, but remember, if the target gets pushed more than 13 bits away we need to turn the call/add into sethi/or/call/add or something like that. The fact that this is in a delay slot and also that the %o7 value from the call is a source register complicates things even more. It would not be impossible to handle this but there is the ROI to consider. You asked when, specifically, Purify stretches code. The short answer is: anywhere we need to. Definitely at the top of a function, and at every memory load or store instruction, and after function calls. Beyond that, we might do insertion on any instruction at all, subject to our needs. sales_pitch The basic Purify insertion is on load and store instructions; everything else is in support of that. Purify's whole value proposition is to pinpoint memory errors like reading uninitialized memory, or touching beyond the end of a block or the end of the current stack, or touching memory you've already freed. In contrast, malloc-debug libraries only report bad writes, and only after the fact. They spray patterns into freed memory in the hopes that bad reads will cause visible misbehavior in the program's future. Unlike those, Purify sees both reads and writes when they happen, pinpointing the faulting instruction instead of telling you a bad thing happened sometime in the past. /sales_pitch Best case (on SPARC) is that we insert two instructions before each load or store. Worst case, we unravel instructions out of delay slots, add more instructions to shadow certain types of register usage, and deal with offsets that have grown too large by inserting additional math. You asked how you can know that Purify will *not* do insertion or stretch your code. That's a little tricky. If you have two non-global symbols that identify data blocks, and there are no global symbols or code (instructions) between them, there won't be any stretching from today's Purify. But any instructions at all are subject to insertion, and in some cases we insert dead space (a red zone) before a global data symbol. Now, back to libcrypto: while you and I have been talking, our resident genius instrumentation engine guy has actually coded some modifications to support the .PIC.me.up pattern as it appears in 0.9.8j. This supports our current customers who use past, released versions of libcrypto on SPARC. I expect this change to appear in an upcoming release of PurifyPlus, but I can't commit to it or give a date because I'm not authorized to commit to future product features or support in a public forum. The new pattern recognizer is pretty specific, intending to support existing customers with libcrypto binaries. It's not a general-purpose recognizer for optimized interprocedural PIC sequences. It recognizes patterns that stay very close to this: call target mov offset,%o0 ... target: add %o0,%o7,%o0 The new code recognizes this when offset is the distance from the call instruction to target, and the add really is the very first instruction at the call target. We'll even patch the offset if the distance from the caller to the target grows past 13 bits. The developer also coded changes to recognize and patch the self-relative offset in data from .PIC.DES_SPtrans to DES_SPtrans. I don't know the details and restrictions on this one. Like I said, it's really meant for customers with current libcrypto binaries. Regardless of any new recognizers which might appear in the future, there are two Purify-safe ways to do PIC stuff on SPARC: Short form: L1: call8 add %o7,(target-L1),regZ Long form: sethi %hi(target-L2),regX or regX,%lo(target-L2),regY L2: call8 add regY,%o7,regZ The short form will work even if Purify stretches the distance farther than 13 bits will reach. Purify is flexible: regX, regY, and regZ can be different or they can overlap, and the call8 can happen any time before the add, and you can move the o7 result of the call8 to another register if you want and then use that: it doesn't have to stay in o7. You can use the same call8-derived base
Re: [openssl.org #1847] Bug in Openssl 0.9.8j CA.sh script
-create_serial does not exist in CA.sh, either.
-Kyle H
On Tue, Feb 24, 2009 at 1:46 PM, Nguyen, Kim via RT r...@openssl.org wrote:
The CA.sh script in 0.9.8j is missing the -extensions v3_ca flag. This
doesn't seem to be a problem in CA.pl
In comparision, CA.pl has:
print Making CA certificate ...\n;
system ($REQ -new -keyout .
${CATOP}/private/$CAKEY -out ${CATOP}/$CAREQ);
system ($CA -create_serial .
-out ${CATOP}/$CACERT $CADAYS -batch .
-keyfile ${CATOP}/private/$CAKEY -selfsign .
-extensions v3_ca .
-infiles ${CATOP}/$CAREQ );
$RET=$?;
While CA,.sh has:
echo Making CA certificate ...
$REQ -new -keyout ${CATOP}/private/$CAKEY \
-out ${CATOP}/$CAREQ
$CA -out ${CATOP}/$CACERT $CADAYS -batch \
-keyfile ${CATOP}/private/$CAKEY -selfsign \
-infiles ${CATOP}/$CAREQ
RET=$?
Note -extensions v3_ca is missingchanging the above to:
else
echo Making CA certificate ...
$REQ -new -keyout ${CATOP}/private/$CAKEY \
-out ${CATOP}/$CAREQ
$CA -out ${CATOP}/$CACERT $CADAYS -batch \
-keyfile ${CATOP}/private/$CAKEY -selfsign \
-extensions v3_ca \
-infiles ${CATOP}/$CAREQ
RET=$?
Fixes the problem.
Kim
The CA.sh script in 0.9.8j is missing the –extensions v3_ca flag. This
doesn’t seem to be a problem in CA.pl
In comparision, CA.pl has:
print Making CA certificate ...\n;
system ($REQ -new -keyout .
${CATOP}/private/$CAKEY -out ${CATOP}/$CAREQ);
system ($CA -create_serial .
-out ${CATOP}/$CACERT $CADAYS -batch .
-keyfile ${CATOP}/private/$CAKEY -selfsign .
-extensions v3_ca .
-infiles ${CATOP}/$CAREQ );
$RET=$?;
While CA,.sh has:
echo Making CA certificate ...
$REQ -new -keyout ${CATOP}/private/$CAKEY \
-out ${CATOP}/$CAREQ
$CA -out ${CATOP}/$CACERT $CADAYS -batch \
-keyfile ${CATOP}/private/$CAKEY -selfsign \
-infiles ${CATOP}/$CAREQ
RET=$?
Note “-extensions v3_ca” is missing….changing the above to:
else
echo Making CA certificate ...
$REQ -new -keyout ${CATOP}/private/$CAKEY \
-out ${CATOP}/$CAREQ
$CA -out ${CATOP}/$CACERT $CADAYS -batch \
-keyfile ${CATOP}/private/$CAKEY -selfsign \
-extensions v3_ca \
-infiles ${CATOP}/$CAREQ
RET=$?
Fixes the problem.
Kim
Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify
The 'rt' is the 'request tracker' system. It essentially opens a trouble ticket, which allows for any action on the patch to be identified and tracked. (When it's updated by the core OS developers when they take an action on a patch, anyway. :)) It also -- more importantly to you, in this case -- automatically sends a mail to openssl-dev when a new request is submitted -- which allows for the discussion that you're looking for to take place. -Kyle H On Mon, Mar 9, 2009 at 4:52 PM, Allan K Pratt apr...@us.ibm.com wrote: Kyle Hamilton aerow...@gmail.com wrote: The best way is to send a patch (unified diff) to r...@openssl.org. ... The module owner will review the patch and apply it if appropriate... Thanks for the guidance. I'll try that route. I guess I was hoping to get a little bit of back-and-forth with the component owner(s), to validate the *idea* of the patch first. I don't know the process on the rt list: does sending a patch there start a discussion, or is it more of a yes/no decision at that point? Since this patch isn't about correctness on its face, and understanding its motivation and import might take some discussion, I'd like to connect with a person rather than send the patch to a potential black hole. Will I hear from somebody if my patch is rejected? By the way, a Purify user on this list asked privately about the symptom, the behavior when PurifyPlus goes bad. The program instruments without error, but then it misbehaves at runtime if you execute the functions in des_enc.m4. Those functions have names like DES_encrypt1 (and -2 and -3) and DES_decrypt3 plus a couple of others starting with DES. If you don't end up in those you'll be fine. The user who reported this got a SEGV, which at least has the virtue of being obvious. I'm not sure, but it is also possible that you could silently get incorrect encryption or decryption without crashing; this would be much worse from the user's perspective. It depends on how those tables are used. (I didn't grok the whole implementation, just identified the trick that gave Purify grief.) -- Allan Pratt, apr...@us.ibm.com Rational software division of IBM __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SPARC assembly trick in libcrypto breaks IBM Rational Purify
The best way is to send a patch (unified diff) to r...@openssl.org. This allows for ease of patching, and ensuring that the actual intent of the patch is preserved at the source level. The module owner will review the patch and apply it if appropriate, and your name (and the fact that IBM contributed a bit of resource to the code) will go into the changelog for credit. You do not need to become a regular contributor for this sequence of operations to occur. :) -Kyle H On Mon, Mar 9, 2009 at 1:17 PM, Allan K Pratt apr...@us.ibm.com wrote: Dear OpenSSL developers: I'm not a regular subscriber to openssl-dev, so please forgive me for laying this all out at once. My name is Allan Pratt, and I am a developer for IBM Rational PurifyPlus. We recently had a Purify customer write to say that Purify does not instrument libcrypto.so properly on SPARC. The customer was right. There is some clever hand-written SPARC assembly code in the DES code which Purify does not handle. This will affect any OpenSSL user on Solaris/SPARC who wants to use PurifyPlus (Purify, Quantify, or PureCoverage) as part of their software quality process, if they end up using the DES parts of libcrypto. I'd like to suggest a change to the SPARC assembly source code in OpenSSL so SPARC users can use Purify successfully. In the file crypto/des/asm/des_enc.m4 there is a function called .PIC.me.up which uses a trick to get its own address. Then it uses that address as the base for getting other addresses in a position-independent way. The trouble is, the trick is too tricky for Purify (and possibly other analysis tools that operate by decoding the instruction stream). The trick being used is that the caller puts a constant in a register before making the call. The constant is the distance from the call instruction to the start of the .PIC.me.up function. The first instruction of .PIC.me.up is an ADD of this value to the caller's return PC. The result is the .PIC.me.up function's own address. This is not a usual way for a function to get its own address on SPARC, and Purify does not handle this kind of inter-procedural address computation. We could add custom analysis logic in Purify to make this work, but it would be very specific and fragile: a future change in des_enc.m4 could make it break again. The trick being used saves a few cycles but I don't think it's in an especially performance-sensitive place: it's in the encrypt/decrypt setup code, not in a loop. A more common (though less hyper-efficient) way for the function to get its own address on SPARC is to use the call .+8 instruction. History: Looking back, I first see the des_enc.m4 file and its .PIC.me.up trick in version 0.9.8 (with no letter) from 2005. It does not appear to be in any 0.9.7 sources including the most recent, 0.9.7m from 2008. The source file comments indicate that Andy Polyakov (ap...@fy.chalmers.se) did the PIC-ification, which suggests he is responsible for the trick in .PIC.me.up. The same comment implies he did it in either 2000 or 2003. This recent customer engagement was the first time anybody had called this problem with OpenSSL and Purify on SPARC to our attention. The following two changes to the custom SPARC assembly code in des_enc.m4 will make Purify work. 1. Delete the first instruction of .PIC.me.up and replace it with this sequence: mov %o7,global1 call .+8 sub %o7,4,out0 mov global1,%o7 2. Change the delay-slot instructions of the calls to .PIC.me.up to NOP instructions. Or just leave them alone: the current instructions there become useless but harmless. The proposed sequence at the start of .PIC.me.up is longer and slower but it has the same effect as the original - that is, the same as the combined effect of the MOV in the caller's delay slot plus the original ADD instruction. It gets the address of the .PIC.me.up label into %o0 (out0) without changing other registers. (The global1 register is used as a temporary to save and restore %o7. This is safe because global1 will be set later in the function anyway.) The new sequence works both with and without Purify. I'd like to know what the openssl-dev community thinks of this idea, and how I can direct my energies to get this change into the project. I don't want to become a contributor myself; I think it's better if an owner of the code in des_enc.m4 reviews this and implements it if it meets with approval. Thanks for your attention. -- Allan Pratt, apr...@us.ibm.com Rational software division of IBM __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project
Re: GeneralizedTime support in openssl ca
Please send this patch as an attachment to r...@openssl.org. This will
track it as a ticket.
-Kyle H
On Tue, Mar 3, 2009 at 2:37 PM, Oliver Martin oli...@volatilevoid.net wrote:
Hello,
this patch adds support for GeneralizedTime for startdate/enddate in
openssl ca. I submitted an earlier version to openssl-users a bit more
than a week ago [1] but got no reaction there, so I'll try again here.
Any chance of getting something like this accepted? I guess not too
many people need certificates beyond 2049 (or before 1950) right now,
but having the capability surely can't hurt.
Also, previously it accepted non-GMT times and values without seconds,
both of which are not allowed by RFC 5280 (and previous ones). This is
fixed too.
Regards,
Oliver
[1] http://marc.info/?l=openssl-usersm=123532280026134w=2
--- openssl-SNAP-20090303.orig/apps/ca.c 2009-03-03 19:04:00.0
+0100
+++ openssl-SNAP-20090303/apps/ca.c 2009-03-03 23:04:24.0 +0100
@@ -227,6 +227,9 @@
static int get_certificate_status(const char *ser_status, CA_DB *db);
static int do_updatedb(CA_DB *db);
static int check_time_format(const char *str);
+static int check_time_valid_rfc(const char *str, int numcnt);
+static int check_utctime(const char *str);
+static int check_generalizedtime(const char *str);
char *make_revocation_str(int rev_type, char *rev_arg);
int make_revoked(X509_REVOKED *rev, const char *str);
int old_entry_print(BIO *bp, ASN1_OBJECT *obj, ASN1_STRING *str);
@@ -1109,9 +1112,10 @@
if (startdate == NULL)
ERR_clear_error();
}
- if (startdate !ASN1_UTCTIME_set_string(NULL,startdate))
+ if (startdate !((ASN1_UTCTIME_set_string(NULL, startdate)
check_utctime(startdate))
+ || (ASN1_GENERALIZEDTIME_set_string(NULL,
startdate) check_generalizedtime(startdate
{
- BIO_printf(bio_err,start date is invalid, it should
be YYMMDDHHMMSSZ\n);
+ BIO_printf(bio_err,start date is invalid, it should
be YYMMDDHHMMSSZ or MMDDHHMMSSZ\n);
goto err;
}
if (startdate == NULL) startdate=today;
@@ -1123,9 +1127,10 @@
if (enddate == NULL)
ERR_clear_error();
}
- if (enddate !ASN1_UTCTIME_set_string(NULL,enddate))
+ if (enddate !((ASN1_UTCTIME_set_string(NULL, enddate)
check_utctime(enddate))
+ || (ASN1_GENERALIZEDTIME_set_string(NULL,
startdate) check_generalizedtime(enddate
{
- BIO_printf(bio_err,end date is invalid, it should be
YYMMDDHHMMSSZ\n);
+ BIO_printf(bio_err,end date is invalid, it should be
YYMMDDHHMMSSZ or MMDDHHMMSSZ\n);
goto err;
}
@@ -1689,6 +1694,7 @@
STRING *irow=NULL;
STRING *rrow=NULL;
char buf[25];
+ int year;
tmptm=ASN1_UTCTIME_new();
if (tmptm == NULL)
@@ -2007,11 +2013,39 @@
if (strcmp(startdate,today) == 0)
X509_gmtime_adj(X509_get_notBefore(ret),0);
- else ASN1_UTCTIME_set_string(X509_get_notBefore(ret),startdate);
+ else
+ {
+ if
(!ASN1_UTCTIME_set_string(X509_get_notBefore(ret),startdate))
+ {
+ if (sscanf(startdate, %4u, year) != 1)
+ goto err;
+ if (year = 1950 year = 2049)
+ {
+ memmove(startdate, startdate + 2,
strlen(startdate) - 1);
+
ASN1_UTCTIME_set_string(X509_get_notBefore(ret),startdate);
+ }
+ else
+
ASN1_GENERALIZEDTIME_set_string(X509_get_notBefore(ret),startdate);
+ }
+ }
if (enddate == NULL)
X509_time_adj_ex(X509_get_notAfter(ret),days, 0, NULL);
- else ASN1_UTCTIME_set_string(X509_get_notAfter(ret),enddate);
+ else
+ {
+ if (!ASN1_UTCTIME_set_string(X509_get_notAfter(ret),enddate))
+ {
+ if (sscanf(enddate, %4u, year) != 1)
+ goto err;
+ if (year = 1950 year = 2049)
+ {
+ memmove(enddate, enddate + 2, strlen(enddate)
- 1);
+
ASN1_UTCTIME_set_string(X509_get_notAfter(ret),enddate);
+ }
+ else
+
Re: how to use the openssl API to verify a digital signature
This is a question that should go on openssl-users, since it does not relate to the development of the library itself. However, since it's asked here, I'll answer. apps/dgst.c has the appropriate code. Most of the OpenSSL public API documentation is poorly-written and out-of-date. I wish there were some wiki where people could contribute documentation changes, since very few people seem to be able to understand the nroff macros necessary to write manpages. -Kyle H On Mon, Feb 23, 2009 at 10:39 AM, RussMitch russell.mitch...@lynnsoft.com wrote: Hello, I'm trying to figure out how to do the following: openssl dgst -sha1 -verify my-public-key -signature my-app.sha1 my-app which works fine from the command line, but I need to be able to do if from inside my-app, and have been unsuccessful finding the appropriate documentation. /Russ -- View this message in context: http://www.nabble.com/how-to-use-the-openssl-API-to-verify-a-digital-signature-tp22167382p22167382.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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Re[2]: q and j parameters for Diffie-Hellman
If you have an IANA Private Enterprise Number, you can invent your own OID (since you own an OID tree). For example, mine is 1.3.6.1.4.1.22232. (To be explicit: you are NOT authorized to invent any OID under this tree, as it belongs to me, not you.) http://pen.iana.org/pen/PenApplication.page allows you to apply for a PEN. You can only get one -- since it is a tree, you can delegate anything you want out of it, and a closer-to-root branch does not necessarily say anything about anything farther from the trunk. -Kyle H On Mon, Feb 16, 2009 at 9:31 AM, Maxim Masiutin m...@ritlabs.com wrote: Hello Stephen, Thank you for your comment, I know that Elgamal doesn't have side effect of SS DH. May I invent an OID for SS DH EC if I need to implement it? Should I write a message to S/MIME mailing list? -- Best regards, Maxim Masiutinmailto:m...@ritlabs.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Fwd: Openssl-SNAP still erroring out (verified on OSX 10.5.6 and virgin config)
*** virgin/crypto/objects/obj_xref.h2009-02-10 05:01:06.0 -0800
--- openssl-SNAP-20090207/crypto/objects/obj_xref.h 2009-02-10
05:02:43.0 -0800
***
*** 1,4
! /* AUTOGENERATED BY objxref.pl, DO NOT EDIT */
typedef struct
{
--- 1,4
! /* AUTOGENERATED BY crypto/objects/objxref.pl, DO NOT EDIT */
typedef struct
{
***
*** 9,75
static const nid_triple sigoid_srt[] =
{
- {NID_md2WithRSAEncryption, NID_md2, NID_rsaEncryption},
- {NID_md5WithRSAEncryption, NID_md5, NID_rsaEncryption},
- {NID_shaWithRSAEncryption, NID_sha, NID_rsaEncryption},
- {NID_sha1WithRSAEncryption, NID_sha1, NID_rsaEncryption},
- {NID_dsaWithSHA, NID_sha, NID_dsa},
- {NID_dsaWithSHA1_2, NID_sha1, NID_dsa_2},
- {NID_mdc2WithRSA, NID_mdc2, NID_rsaEncryption},
- {NID_md5WithRSA, NID_md5, NID_rsa},
- {NID_dsaWithSHA1, NID_sha1, NID_dsa},
- {NID_sha1WithRSA, NID_sha1, NID_rsa},
- {NID_ripemd160WithRSA, NID_ripemd160, NID_rsaEncryption},
- {NID_md4WithRSAEncryption, NID_md4, NID_rsaEncryption},
- {NID_ecdsa_with_SHA1, NID_sha1, NID_X9_62_id_ecPublicKey},
- {NID_sha256WithRSAEncryption, NID_sha256, NID_rsaEncryption},
- {NID_sha384WithRSAEncryption, NID_sha384, NID_rsaEncryption},
- {NID_sha512WithRSAEncryption, NID_sha512, NID_rsaEncryption},
- {NID_sha224WithRSAEncryption, NID_sha224, NID_rsaEncryption},
- {NID_ecdsa_with_Recommended, NID_undef, NID_X9_62_id_ecPublicKey},
- {NID_ecdsa_with_Specified, NID_undef, NID_X9_62_id_ecPublicKey},
- {NID_ecdsa_with_SHA224, NID_sha224, NID_X9_62_id_ecPublicKey},
- {NID_ecdsa_with_SHA256, NID_sha256, NID_X9_62_id_ecPublicKey},
- {NID_ecdsa_with_SHA384, NID_sha384, NID_X9_62_id_ecPublicKey},
- {NID_ecdsa_with_SHA512, NID_sha512, NID_X9_62_id_ecPublicKey},
- {NID_dsa_with_SHA224, NID_sha224, NID_dsa},
- {NID_dsa_with_SHA256, NID_sha256, NID_dsa},
- {NID_id_GostR3411_94_with_GostR3410_2001, NID_id_GostR3411_94,
NID_id_GostR3410_2001},
- {NID_id_GostR3411_94_with_GostR3410_94, NID_id_GostR3411_94,
NID_id_GostR3410_94},
- {NID_id_GostR3411_94_with_GostR3410_94_cc, NID_id_GostR3411_94,
NID_id_GostR3410_94_cc},
- {NID_id_GostR3411_94_with_GostR3410_2001_cc, NID_id_GostR3411_94,
NID_id_GostR3410_2001_cc},
};
static const nid_triple * const sigoid_srt_xref[] =
{
- sigoid_srt[17],
- sigoid_srt[18],
- sigoid_srt[0],
- sigoid_srt[1],
- sigoid_srt[7],
- sigoid_srt[2],
- sigoid_srt[4],
- sigoid_srt[3],
- sigoid_srt[9],
- sigoid_srt[5],
- sigoid_srt[8],
- sigoid_srt[12],
- sigoid_srt[6],
- sigoid_srt[10],
- sigoid_srt[11],
- sigoid_srt[13],
- sigoid_srt[24],
- sigoid_srt[20],
- sigoid_srt[14],
- sigoid_srt[21],
- sigoid_srt[15],
- sigoid_srt[22],
- sigoid_srt[16],
- sigoid_srt[23],
- sigoid_srt[19],
- sigoid_srt[25],
- sigoid_srt[26],
- sigoid_srt[27],
- sigoid_srt[28],
};
--- 9,17
On Tue, Feb 10, 2009 at 3:30 AM, Dr. Stephen Henson st...@openssl.org wrote:
/opt/local/bin/perl crypto/objects/objxref.pl crypto/objects/obj_xref.h
[...]
Ah! Now that line could make a difference. Please copy obj_xref.h somewhere
from a virgin tarball and compare it with its contents after that command.
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
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Fwd: Openssl-SNAP still erroring out (verified on OSX 10.5.6 and virgin config)
Okay. Using a virgin SNAP-20090209 I do not get this error. Nor with a virgin SNAP-20090207. However, 'make update' on SNAP-20090207 reports a couple of changed symbols. [...] /opt/local/bin/perl util/ck_errf.pl */*.c */*/*.c ssl/s3_enc.c:607:ssl3_digest_cached_records:digest_cached_records crypto/asn1/a_gentm.c:246:asn1_generalizedtime_adj:asn1_generalizedtime_set crypto/asn1/a_time.c:115:asn1_time_adj:asn1_time_set crypto/asn1/a_utctm.c:224:asn1_utctime_adj:asn1_utctime_set /opt/local/bin/perl util/mkstack.pl -write Writing new crypto/stack/safestack.h. /opt/local/bin/perl util/mkdef.pl crypto update Updating LIBEAY info 2 old symbols got an info update Rewriting LIBEAY Updating LIBEAY numbers 1 New symbols added /opt/local/bin/perl util/mkdef.pl ssl update Updating SSLEAY info 2 old symbols got an info update Rewriting SSLEAY Updating SSLEAY numbers 1 New symbols added /opt/local/bin/perl crypto/objects/objxref.pl crypto/objects/obj_xref.h [...] After performing the 'make update' and 'make', the test failed. The steps followed were: $ ./config --prefix=$HOME/ossl --openssldir=$HOME/ossl $ make update $ make $ make test -Kyle H On Mon, Feb 9, 2009 at 2:04 PM, Dr. Stephen Henson st...@openssl.org wrote: On Sat, Feb 07, 2009, The Doctor wrote: On Sat, Feb 07, 2009 at 12:46:52PM -0800, Kyle Hamilton wrote: The bug does appear on OSX 10.5.6 (openssl-SNAP-20090207) with the following command line: ./config threads shared no-sse2 enable-whrlpool enable-montasm enable-capieng enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779 enable-mdc2 enable-rc5 --prefix=/$HOME/ossl --openssldir=$HOME/ossl [...] Generate and verify a certificate request generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 512 bit RSA private key .. writing new private key to 'testkey.pem' - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:AU State or Province Name (full name) [Queensland]: Locality Name (eg, city) []:Brisbane Organization Name (eg, company) []:CryptSoft Pty Ltd Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:Eric Young Email Address []:e...@mincom.oz.au 2693744484:error:0D0C30C6:asn1 encoding routines:ASN1_item_sign:digest and key type not supported:a_sign.c:245: problems creating request make[1]: *** [test_gen] Error 1 make[1]: Leaving directory `/Users/kyanha/workspace/ossl/snap/openssl-SNAP-20090207/test' make: *** [tests] Error 2 It also appears with the following command-line: ./config --prefix=$HOME/ossl --openssldir=$HOME/ossl -Kyle H -- Forwarded message -- From: Dr. Stephen Henson st...@openssl.org Date: Sat, Feb 7, 2009 at 2:30 AM Subject: Re: Openssl-SNAP still erroring out To: openssl-dev@openssl.org On Fri, Feb 06, 2009, Kyle Hamilton wrote: This does not appear on MacOSX 10.5.6 (with 0.9.8-stable-SNAP-20090206). ./config threads shared no-sse2 enable-whrlpool enable-montasm enable-capieng enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779 enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/contrib --openssldir=/usr/contrib You'd need to try the 0.9.9 snapshots to check the reported error. That bit of code (the EVP_PKEY APIs) isn't in 0.9.8. Steve. Hence it is BSD related. The last one that did work was openssl-SNAP-20081228 . Kyle would you like a copy of said package? I can't see anything in CVS around that time which could affect this. I don't use BSD much myself but couldn't reproduce this on FreeBSD 7.1 under VMWare. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Fwd: Openssl-SNAP still erroring out (verified on OSX 10.5.6 and virgin config)
The bug does appear on OSX 10.5.6 (openssl-SNAP-20090207) with the following command line: ./config threads shared no-sse2 enable-whrlpool enable-montasm enable-capieng enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779 enable-mdc2 enable-rc5 --prefix=/$HOME/ossl --openssldir=$HOME/ossl [...] Generate and verify a certificate request generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 512 bit RSA private key .. writing new private key to 'testkey.pem' - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:AU State or Province Name (full name) [Queensland]: Locality Name (eg, city) []:Brisbane Organization Name (eg, company) []:CryptSoft Pty Ltd Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:Eric Young Email Address []:e...@mincom.oz.au 2693744484:error:0D0C30C6:asn1 encoding routines:ASN1_item_sign:digest and key type not supported:a_sign.c:245: problems creating request make[1]: *** [test_gen] Error 1 make[1]: Leaving directory `/Users/kyanha/workspace/ossl/snap/openssl-SNAP-20090207/test' make: *** [tests] Error 2 It also appears with the following command-line: ./config --prefix=$HOME/ossl --openssldir=$HOME/ossl -Kyle H -- Forwarded message -- From: Dr. Stephen Henson st...@openssl.org Date: Sat, Feb 7, 2009 at 2:30 AM Subject: Re: Openssl-SNAP still erroring out To: openssl-dev@openssl.org On Fri, Feb 06, 2009, Kyle Hamilton wrote: This does not appear on MacOSX 10.5.6 (with 0.9.8-stable-SNAP-20090206). ./config threads shared no-sse2 enable-whrlpool enable-montasm enable-capieng enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779 enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/contrib --openssldir=/usr/contrib You'd need to try the 0.9.9 snapshots to check the reported error. That bit of code (the EVP_PKEY APIs) isn't in 0.9.8. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl-SNAP still erroring out
This does not appear on MacOSX 10.5.6 (with 0.9.8-stable-SNAP-20090206).
./config threads shared no-sse2 enable-whrlpool enable-montasm
enable-capieng enable-cms enable-seed enable-tlsext enable-camellia
enable-rfc3779 enable-mdc2 enable-rc5 zlib-dynamic
--prefix=/usr/contrib --openssldir=/usr/contrib
(Note that I don't have GMP, so I had to remove it from the line.)
All tests pass.
(however, experimental-jpake fails with Bob fails to process Alice's
step 3a (hash of hash of key mismatch).)
-Kyle H
On Fri, Feb 6, 2009 at 8:23 AM, Dr. Stephen Henson st...@openssl.org wrote:
On Fri, Feb 06, 2009, The Doctor wrote:
Right
in the tests we run into
There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
Generating a 512 bit RSA private key
..
.
writing new private key to 'testkey.pem'
-
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Queensland]:
Locality Name (eg, city) []:Brisbane
Organization Name (eg, company) []:CryptSoft Pty Ltd
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Eric Young
Email Address []:e...@mincom.oz.au
134954328:error:0D0C30C6:asn1 encoding routines:ASN1_item_sign:digest and
key type not supported:a_sign.c:245:
problems creating request
*** Error code 1
Stop.
*** Error code 1
Stop.
Source of the problem
if (type-flags EVP_MD_FLAG_PKEY_METHOD_SIGNATURE)
{
if (!pkey-ameth ||
!OBJ_find_sigid_by_algs(signid, EVP_MD_nid(type),
pkey-ameth-pkey_id))
{
ASN1err(ASN1_F_ASN1_ITEM_SIGN,
ASN1_R_DIGEST_AND_KEY_TYPE_NOT_SUPPORTED);
return 0;
}
}
Using
./Configure 386 threads shared no-sse2 enable-whrlpool enable-montasm
enable-capieng enable-cms enable-seed enable-tlsext enable-camellia
enable-rfc3779 enable-gmp enable-mdc2 enable-rc5 zlib-dynamic
--prefix=/usr/contrib --openssldir=/usr/contrib debug-bsdi-x86-elf ; gmake
update;gmake depend
to compile.
Still can't reproduce it here. Can you try a vanilla build with:
./config
to see if you still get that?
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
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Does the release of 0.9.8j also include the FIPS module support? (i.e., is this a bug-fix only release, or does this include what you have been working on for the past few months as well?) -Kyle H On Wed, Jan 7, 2009 at 4:10 AM, Dr. Stephen Henson st...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [07-Jan-2009] Incorrect checks for malformed signatures - --- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Mutual Authentication
SSL_get_peer_certificate(3ssl), SSL_get_peer_cert_chain(3ssl) will get
the certificate and certificate chain, respectively.
To control the verification process, you can use SSL_set_verify(3ssl)
and/or SSL_CTX_set_verify(3ssl). Note that the server must present a
certificate if it wants to ask for the client certificate;
SSL[_CTX]_set_verify() is necessary to actually ask the client for its
certificate.
If you want to implement your own verification function, be careful.
It's very easy to get it wrong.
-Kyle H
On Mon, Jan 5, 2009 at 1:24 AM, Itay Dagan i...@yoggie.com wrote:
Hi Guys
I have a question about Mutual authentication.
After big help from your side (Thanks Shahin and Patrick) I secseeded to
upload the server certificate from memory
and it works great verifying the server certificate
in the second fase
I configure my server to verify client certificate.
I am trying now to do the same for my certificate (Client). (upload from
memory)
My Q is :
should I do the same with the client certificate ?
Is there a open-ssl function/struct that get the client certificate ?
Thank you very much for your help.
Itay
(I added the code I used - adding my server certificate from memory) - I am
using CURL-lib here
*
intssl_ctx(CURL *curl void * sslctx, void * parm)
{
X509_STORE * store;
X509 * cert=NULL;
BIO * bio;
char * mypem = buf;
// get a BIO
bio=BIO_new_mem_buf(mypem, -1);
// use it to read the PEM formatted certificate from memory into an X509
//structure that SSL can use
PEM_read_bio_X509(bio, cert, 0, NULL);
if (cert == NULL)
return false ;
// get a pointer to the X509 certificate store (which may be empty!) //
store=SSL_CTX_get_cert_store((SSL_CTX *)sslctx);
// add our certificate to this store
if (X509_STORE_add_cert(store, cert)==0)
return false ;
// all set to go
return true ;
}
***
Thanks
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: quick open ssl question please
Not at all, sorry. OpenSSL is entirely C, and has no relation at all with C#. -Kyle H On Mon, Dec 22, 2008 at 12:33 PM, Steven MacLeod steven.macl...@syfir.com wrote: Hello, I have a quick question regarding open ssl, which so far I haven't been able to make head or tail of. I have a .net win forms app and I want to replace SSL Explorer with a .Net assembly so that the logon all contained in one place. Does Open SSL have anything like this please? Regards Steven MacLeod __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL cross-compile for ARM
You are cross-compiling, which means that the platform that you're on cannot actually run the binaries that it builds. If you do not have any .so files, it may not be able to create shared libraries in that environment. The .a files, in that case, are static libraries. -Kyle H On Sun, Dec 21, 2008 at 2:06 PM, William Estrada mrumun...@popdial.com wrote: Hi group, I just built OpenSSL on my FC8 system for my ARM processor. The build went well but failed the 'make test' with this: $ make test Doing certs touch rehash.time testing... make[1]: Entering directory `/src/ARM/openssl/openssl-0.9.8h/test' make[2]: Entering directory `/src/ARM/openssl/openssl-0.9.8h' making all in apps... make[3]: Entering directory `/src/ARM/openssl/openssl-0.9.8h/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h/apps' make[2]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h' ../util/shlib_wrap.sh ./destest ../util/shlib_wrap.sh: line 91: /src/ARM/openssl/openssl-0.9.8h/test/destest: cannot execute binary file ../util/shlib_wrap.sh: line 91: /src/ARM/openssl/openssl-0.9.8h/test/destest: Success make[1]: *** [test_des] Error 1 make[1]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h/test' make: *** [tests] Error 2 I also can't find libcrytpo.so, I have libvcrypto.a and libssl.a, but no *.so files? Where does the build put them?? -- William Estrada mrumun...@popdial.com Mt-Umunhum-Wireless.net ( http://64.124.13.3 ) Ymessenger: MrUmunhum __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: pubkey format
Can the source be made available? I would like to use it on MacOSX. -Kyle H On Fri, Dec 19, 2008 at 11:43 PM, Shahin Khorasani khoras...@amnafzar.com wrote: Hi, You can download simple utility to transform PKCS#1 RSA public key to opnessh public key format from here: http://www.parssign.com/openssh_pk_linux.tar.gz It is free to use and linked statically on Linux (must works on most distributions) Regards, Shahin Khorasani Dhiva wrote: openssl x509 -in sample.pem -pubkey -noout What is the format of the pubkey ? How can i convert or transform this key to ssh-rsa format? I am talking about the ssh keys that are available in authorized_keys file. Or Does openssl has any tools to manage the pubkey ? like dismantle and assemble again. thanks dhiva __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [FWD] An error appears when run ./CA.sh -sign
forwarding from -users for a query. This is the second time that I've heard of bad end line or could not decode base64 today. Did a change go into 0.9.8i that changed base64 handling? -Kyle H On Thu, Dec 11, 2008 at 11:31 PM, Lutz Jaenicke jaeni...@openssl.org wrote: Forwarded to openssl-users for public discussion. Best regards, Lutz - Forwarded message from fastrunn...@sina.com - Date: Fri, 12 Dec 2008 14:20:21 +0800 From: fastrunn...@sina.com To: r...@openssl.org Subject: An error appears when run ./CA.sh -sign 1??The env is solaris9+openssl0.9.8i 2??The error message is below: Using configuration from /usr/local/ssl/openssl.cnf Enter pass phrase for ./demoCA/private/cakey.pem: Error reading certificate request in newreq.pem 29809:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:746: Signed certificate is in newcert.pem 3??The CSR File is newreq.pem??it's content is below?? -BEGIN NEW CERTIFICATE REQUEST- MIIBnjCCAQcCAQAwXjELMAkGA1UEBhMCQ04xCzAJBgNVBAgTAmJqMQswCQYDVQQH EwJiajENMAsGA1UEChMEbWRjbDEMMAoGA1UECxMDbWdzMRgwFgYDVQQDEw9iam1v Y2hhLWh1YW5nd3AwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKrc553GG7Zr MwF4ZMpHFuKOQIt7f1XGLa0Cb2EFt+bAe5iXwg+bI9qOOy3p4UA7SRddzU8cCw5E miU076PI9eT2UsA1xwOxCJKAgYLQAjA04cgPzZ5w3EmvBYnxkawG+8PK5IvX2Voj JN+zV56BVMcEYLensOXv/lvdfIVZ3IADAgMBAAGgADANBgkqhkiG9w0BAQQFAAOB gQBR04JMtcpHZHEB+DlMiHS/466mvExHxVU6NuEmxdkXLhwpbjAqFBPDuWIahgv+ tv59ZhkpNQEcXr0YUKcfpx8g/8dw7MCbsg1gMHPkzQkhOLFJZBnJX7XuasR7HD63 8P1oYSNMXAuFttUt46z7iK1wBE3sq/u11MUljR0oBHukSw== -END NEW CERTIFICATE REQUEST- --- ??(http://space.sina.com.cn/ ) - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] ts verify for expired certificate patch
On Mon, Dec 1, 2008 at 8:53 PM, David Schwartz [EMAIL PROTECTED] wrote: Problem Description: When a digest has been signed and a response is produced, the current version of openssl will not verify the contents correctly if the certificate used to sign the digest has expired. Solution: When verifying the response/token, the time at which the digest was signed is used by setting the time in the X509 store by using X509_STORE_CTX_set_time. I have attached a patch file to fix this. Brad I don't know enough about the specifics of this use in this case to comment intelligently on whether this is good or bad. However, I do know enough to urge caution before this patch is accepted. There are a list of possible issues. Again, I don't know whether each of these issues actually applies to this situation, but they must be all ruled out by someone competent before this patch is accepted: 1) The certificate may have been revoked before this signature was made. Yet the certificate may not be on the current revocation list because expired certificates may be dropped from that list. This is a failure of the underlying communications protocol (X.509 and the PKIX implementation thereof), there is no means to query a server or OCSP responder to determine if the validity were changed before expiration. 2) Are we trusting the expired certificate to tell us when the signature was made? What if the certificate is not very secure and so was only made valid for, say, 6 months because it was expected to take more than 6 months to break it. Now that somoene has compromised it 2 years later, we don't want them to create a signature that claims it was made during the validity interval. http://en.wikipedia.org/wiki/Time_Stamp_Protocol has reference both to the specification (RFC 3161) (which, among other things, specifies that a hash is sent to a timestamping service, and the timestamping service sends back that hash, along with an X.509 structure which states when the timestamping service committed to that particular hash. It also has reference to a project to add TSP to OpenSSL. The way the TSP works, btw, is this: The hash must be generated first. So, the hash could not have been generated after the TSP responder said it committed to it. The timestamp must be generated last. So, the hash could not have been submitted before the TSP said it committed to it. The TSP in no circumstances ever receives the thing that the hash was made over. This is also, by the way, how MS and Mozilla implement code-signing signature validity after the signing certificate expires. I believe current practice is only to accept a signature with an expired certificate if the signature is timestamped by a trusted certificate that has not itself expired. That way, we know by a certificate that is still valid that the signature was in fact made during the validity interval for that signing certificate. I think the rules are relaxed very slightly here, but I'm not entirely certain (I haven't examined current practice this deeply). The design I would make were it up to me (since 'timestamping' is important for legal issues such as you describe): The timestamping root signs timestamping authority certificates, which in turn have a validity period. If the timestamp is within the time period that the timestamp authority is valid, then the signature on the certificate issued by the timestamping root is checked, and the revocation logs of the timestamping root verified that the timestamp authority was not revoked before it issued the timestamp. Of course, this design relies on cryptographic knowledge being maintained and managed inside the court system, which may or may not be a valid design assumption. Again, this is outside my field of expertise. I just want to make sure this isn't adopted (by the distribution or by readers of this list) before it's security is evaluated. DS In the OP's case, I'd copy the X509_STORE_CTX_set_time data from the timestamp, after verifying (to best efforts for the cost of the information being protected) that the timestamp is valid. But, this is part of why there's a mailing list here: people who are likely to have expertise in a field can give the necessary warnings. :) -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] ts verify for expired certificate patch
On Mon, Dec 1, 2008 at 9:13 PM, Brad Mitchell [EMAIL PROTECTED] wrote: I don't think there is anything in the openssl (ts) functions to accept revocation to make this decision anyway. External daemons do exist, such as (e.g.) http://www.carillon.ca/tools/pathfinder.php At the end of the day, time-stamping is only going to be as secure as the Time Stamping Authority is. The security of the certificates or rather, the private key is paramount and if this is a third party performing the time stamping, then this shouldn't be an issue. The party performing the verification should only have the X.509 cert for the TSA and the X.509 for the CA. Verisign is considered The Standard (as far as Microsoft is concerned). In fact: http://support.microsoft.com/kb/293781 lists all the certificates that are essential for Windows 2000, XP, Server 2003, Vista, and Server 2008. I'm not sure we should be considering Microsoft a standards-making body, but it's definitely a large consumer of the standards.) From a point of view of gathering evidence and time stamping it, if you were to present data many years later and not be able to verify the data due to certificates being expired (CA or TSA or otherwise) then the standard would be pretty useless as well as the concept/idea. I would think that so long as you can take the revocation into account, a timestamp should be able to be verified if any and all certificates used in the process are currently expired, i.e. can't be used to sign at this point in time, but were once valid and were valid at the time of signing. Look forward to other comments and suggestions about this. Brad The point of the signature protocol is to effectively mirror the common-law requirements for signature verification: *At the time of the signature*, was the person identified as the signer intending to affix his mark as a part of a ceremony to agree to bind him-or-herself to the performance of a task, the non-performance of a task, or to limit the exercise of his or her rights in any way? (This is essentially part of the 'final proof' of a contract -- contract law, at least in the US, requires a clear understanding of the terms of the agreement, competent parties who could be legally said to be able to agree, and the agreement must include an exchange of valuable consideration. But, if the signature isn't valid, there's no need to determine if the other parts of a contract exist, much less what they entail.) The 'at the time of the signature' is the important part. This is why the time-stamp validation protocol is much more complex than most other X.509 signature validation, it's intended to provide evidence for a court that cannot be obtained any other way. -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Draft FIPS Module v1.2 User Guide
I'm not sure that CC is the appropriate place for fipsld. Maybe LD, but CC has other uses. -Kyle H On Sat, Nov 29, 2008 at 5:41 PM, Brad House [EMAIL PROTECTED] wrote: Well, it's still not as finished as I'd like but since I'll be out of town and offline until next week I'm releasing the OpenSSL FIPS Object Module v1.2 User Guide document: http://www.openssl.org/docs/fips/UserGuide-1.2-RC1.pdf. It's still labeled as a draft as I anticipate revisions over the next few weeks. Feedback on errors/omissions/improvements will be greatly appreciated. Section 4.2.1 is incorrect, I believe. The security policy states to use ./config fipscanisterbuild but the user guide 1.2 rc states the old method of ./config fips ... Section 4.2.3 should probably also mention --with-fipslibdir so you can specify the location of the fipscanister ... Section 5.3.1, I'd probably mention that you can pass 'fipsld' as the CC env for configure scripts as well, since many projects use autoconf/automake. -Brad __ 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: OpenSSL FIPS 140-2 validation
I dunno who I'm supposed to give feedback to, but this format of FIPS announcement needs some work. First, the subject line doesn't say anything about the version of the FIPS module that has been validated. (In this case, it should be something like OpenSSL FIPS 140-2 validation for module v1.2.) My reason for suggesting this is twofold: the original plan called for multiple versions going through validation, and so that the press release can be used for press without any additional investigation by a reporter, and without causing confusion between the multiple fips module versions by a reader. Second, it doesn't describe which version of the OpenSSL API that the newly-validated module supports. (in this case, it supports v0.9.8 (and requires 0.9.8i onward), but I dunno about 0.9.7?) Providing compatibility with a version bump in the API is significant enough that it should be called out in the press release. Third, a statement that the result of the validation is only validated if it's built and used in accordance with the security policy would likely be good as well. I don't really have a rationale for this one, except that it reminds people that there is a security policy that must be followed for FIPS-using applications. Thanks for your time! -Kyle H On Tue, Nov 18, 2008 at 10:40 AM, OpenSSL [EMAIL PROTECTED] wrote: Good news for developers and vendors of software for the U.S. and Canadian government market where FIPS 140-2 validated cryptography is required. The OpenSSL FIPS Object Module, a software component compatible with the OpenSSL API, has been FIPS 140-2 validated (see certificate #1051 and Security Policy document at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm). The source distribution that generates this validated module is at http://www.openssl.org/source/openssl-fips-1.2.tar.gz. This validation means that the referenced source distribution can be used to create a binary module on a wide range of platforms, in a form compatible with OpenSSL 0.9.8, for enabling FIPS 140-2 validated cryptography in applications. Please see the Security Policy document for details on how to create a validated module for your platform and application. Other supporting information will be made available at http://www.openssl.org/docs/fips/ __ 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: More fixes for 0.9.8i
Please submit your patch to [EMAIL PROTECTED] so it can be tracked in the issue tracker? -Kyle H On Sun, Nov 9, 2008 at 2:37 PM, Philip Prindeville [EMAIL PROTECTED] wrote: This fixes the lack of tracing in Makefiles... Replacing @ with $(Q) in all places except before '@echo' rule commands. Thanks, -Philip __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Peer Certificate Verification API
The algorithm for checking of the digital signature of the peer certificate is covered in PKIX (RFC 3280, obsoleted by RFC 5280) and the ITU standard X.509. The library-client code for verifying a certificate can be found in the apps/verify.c . You might want to look at the man pages for SSL_set_verify and SSL_get_verify_callback, as they will allow you to do much of what you might want to do, as well as tell you a couple of the things that you need to watch out for. -Kyle H On Mon, Nov 3, 2008 at 5:24 AM, Aravinda babu [EMAIL PROTECTED] wrote: Hi all, Normally , During HTTPS connection establishment peer server produces it's certificate to the client.I want to know how openssl checks this certificate ? I want to know the exact API which does this so that i will check the code of that API. Please tell me the related things regarding this. (Means how client checks the digital signature of peer certificate etc) Thanks in advance, Aravind. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1762] Feature request
The GPL is explicitly not compatible with OpenSSL's license. This makes it rather difficult to use GPL code in the project. -Kyle H On Mon, Oct 20, 2008 at 5:55 AM, George Romaniuk via RT [EMAIL PROTECTED] wrote: Do you have plans to support security engine in AMCC PPC440EPx processor? AMCC has released Universal Driver Module for this engine under GPL. Regards, George Romaniuk Ablyx LLC __ 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: OPenssl 0.9.8j dev
Fips folk: Should the 'fipsdso' target complain if it gets any other
command line arguments in ./Configure? Since specifying it means that
you're trying to build the shared object...
-Kyle H
On Sat, Sep 20, 2008 at 8:56 AM, The Doctor [EMAIL PROTECTED] wrote:
Need to split the FIPS and non-FIPS compliant technologies:
When I do a fips compile namely
./Configure threads shared no-sse2 fipsdso enable-capieng enable-montasm
enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779
enable-gmp enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/contrib
--openssldir=/usr/contrib
debug-bsdi-x86-elf -g -O3 -Wall -mcpu=pentium3
with debug-bsdi-x86-elf
debug-bsdi-x86-elf, gcc:-DPERL5 -DL_ENDIAN -DTERMIOS
-fomit-frame-pointer -O9 -march=pentium3 -Wall -g::${BSDthreads}::-ldl -lm
-lc:THIRY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
I get:
Testing cipher SEED-ECB(encrypt)
Key
28 db c3 bc 49 ff d8 7d cf a5 09 b1 1d 42 2b e7
Plaintext
b4 1e 6b e2 eb a8 4a 14 8e 2e ed 84 59 3c 5e c7
Ciphertext
9b 9b 7b fc d1 81 3c b9 5d 0b 36 18 f4 0f 51 22
test SSL protocol
test ssl3 is forbidden in FIPS mode
*** IN FIPS MODE ***
Available compression methods:
1: zlib compression
8918:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips
mode:ssl_lib.c:1402:
8918:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips
mode:ssl_lib.c:1402:
test ssl2 is forbidden in FIPS mode
*** IN FIPS MODE ***
Available compression methods:
1: zlib compression
8932:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips
mode:ssl_lib.c:1402:
8932:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips
mode:ssl_lib.c:1402:
test tls1
*** IN FIPS MODE ***
Available compression methods:
1: zlib compression
8956:error:0406A08D:rsa routines:RSA_new_method:non fips method:rsa_eng.c:183:
8956:error:0D079064:asn1 encoding routines:ASN1_ITEM_EX_COMBINE_NEW:aux
error:tasn_new.c:221:
8956:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
error:tasn_dec.c:402:Type=RSA
8956:error:0D09B00D:asn1 encoding routines:d2i_PublicKey:ASN1 lib:d2i_pu.c:99:
8956:error:0B077066:x509 certificate routines:X509_PUBKEY_get:err asn1
lib:x_pubkey.c:366:
8956:error:140BF10C:SSL routines:SSL_SET_CERT:x509 lib:ssl_rsa.c:402:
ERROR in SERVER
8956:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared
cipher:s3_srvr.c:1037:
TLSv1, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
*** Error code 1 (continuing)
Test IGE mode
../util/shlib_wrap.sh ./igetest
`tests' not remade because of errors.
util/opensslwrap.sh version -a
OpenSSL 0.9.8j-fips-dev xx XXX
built on: Sat Sep 20 08:02:29 MDT 2008
platform: debug-bsdi-x86-elf
options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int)
blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O3 -Wall
-mcpu=pentium3 -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O9
-march=pentium3 -Wall -g -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
OPENSSLDIR: /usr/contrib
`test' is up to date.
using make -k test .
Please fix.
--
Member - Liberal International
This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED]
God, Queen and country! Beware Anti-Christ rising! Canada vote anything but
Conservative on 14 OCt 2008, join us at http://www.harpocrit.ca .
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
__
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: [openssl.org #1725] OpenSSL-0.9.8h: Bug in Certificate Request generation
ETA is Estimated Time of Arrival. Basically, he's asking when OpenSSL 0.9.8i is going to be released. -Kyle H On Mon, Sep 8, 2008 at 1:39 PM, Rafael Jorge Csura Szendrodi via RT [EMAIL PROTECTED] wrote: Hi, On Mon, 8 Sep 2008 16:44:43 +0200 (CEST), Steve Pincaud via RT wrote Hi, I have seen the issue will be fixed in the next release, do you have an ETA ? (0.9.8i or 0.9.9 ?) , I would then ask Apache team when such new OpenSSL milestone would be bundled in Apache2 HTTPd (2.3 ?!) Excuse-me... But I didn't understand anything... What's means ETA??? I came back to OpenSSL-0.9.8g and I am only waiting for a new release of OpenSSL (i.e. 0.9.8i). But, I generated all certificates using same the OpenSSL-0.9.8g. I only reported a bug in OpenSSL-0.9.8h (at Fri, 01 Aug 2008 05:24:58 -0700) and you answered (at Sun, 03 Aug 2008 05:55:19 -0700) that this bug was fixed in the 0.9.8 snapshots and will appear in the next OpenSSL release. Ok, I was satisfied with you response and I am waiting for the next stable version of OpenSSL. But, until the next version arrive, the OpenSSL-0.9.8g is working fine for me... Excuse-me, but I didn't understand what you are asking me now? I didn't hope you returned to that subject. Regards, Rafael Regards, Steve -- Atenciosamente, Rafael Jorge Csura Szendrodi Network Administrator - PADS/COPPE/UFRJ E-mail: [EMAIL PROTECTED] __ 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: [openssl.org #1725] OpenSSL-0.9.8h: Bug in Certificate Request generation
On Mon, Sep 8, 2008 at 1:39 PM, Rafael Jorge Csura Szendrodi via RT [EMAIL PROTECTED] wrote: Hi, On Mon, 8 Sep 2008 16:44:43 +0200 (CEST), Steve Pincaud via RT wrote Hi, I have seen the issue will be fixed in the next release, do you have an ETA ? (0.9.8i or 0.9.9 ?) , I would then ask Apache team when such new OpenSSL milestone would be bundled in Apache2 HTTPd (2.3 ?!) I only reported a bug in OpenSSL-0.9.8h (at Fri, 01 Aug 2008 05:24:58 -0700) and you answered (at Sun, 03 Aug 2008 05:55:19 -0700) that this bug was fixed in the 0.9.8 snapshots and will appear in the next OpenSSL release. Ok, I was satisfied with you response and I am waiting for the next stable version of OpenSSL. But, until the next version arrive, the OpenSSL-0.9.8g is working fine for me... I should also note it was Dr Stephen Henson who responded to you stating that the bug was fixed in the snapshots, not Steve Pincaud. -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: can we optimize bn_mul_add_words for windows
bn_mul_add_words is very CPU intensive, simply because the operation it performs is very CPU-intensive. Public-key cryptography should not be done lightly -- it should be done primarily to verify the security of a per-session key (stream or block ciphering). What exactly are you trying to do? -Kyle H On Sat, Aug 30, 2008 at 9:34 PM, samrat saha [EMAIL PROTECTED] wrote: hi all, bn_mul_add_words is very cpu intensive. My gprof profile shows that bn_mul_add_words taking 50% of the cpu time.. can we optimize it. i am using it in some windows crypto operation, because of this cpu intensive behavior my application suffers a lot. thanks, Samrat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Test app
OpenSSL itself contains all sorts of apps that do it. openssl (or openssl.exe) implements all the programs in the apps/ directory. Also, 'make test' runs all the internal self-tests. If you need to verify interoperability with something, figure out what protocol it's using -- pkcs8, pkcs12, and pkcs7 handle PKCS-formatted files of the various types, s_client connects to a TLS/SSL3/SSL2 server, s_server runs as a server to accept client connections, req will generate a certificate signing request, x509 will parse X.509 certificates... ...and if you need to perform some kind of actual crypto test, check the 'enc' manpage (if you're on Windows, http://openssl.org/docs/apps/enc.html is a pointer to the HTMLized version of the manpage for your perusal) for information on how to do it. All of the source code for these is in the apps/ subdirectory of the source distribution. You can use them as a basis for your own routines. -Kyle H On Mon, Sep 1, 2008 at 3:43 AM, Nanavati, Sitanshu [EMAIL PROTECTED] wrote: Hi all, I am looking for some real world app or test app that could be used to run with OpenSSL and check crypto functionality. Please send me the pointers/URLs. Thanks in advance. -Sitanshu __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks
Option 2 works iff pthreads exists.
-Kyle H
On Thu, Aug 28, 2008 at 11:45 PM, Sander Temme via RT [EMAIL PROTECTED] wrote:
This affects OpenSSL 0.9.8 and trunk.
In engines/e_chil.c around line 594, the engine checks if it has mutex
callbacks to work with and, if not, errors out with the message:
You HAVE to add dynamic locking callbacks via
CRYPTO_set_dynlock_{create,lock,destroy}_callback()
There used to be a static lock (CRYPTO_LOCK_HWCRHK, #39 if I'm not
mistaken), but that was removed in 0.9.8 so if the calling application
does not set up dynamic locking scaffolding as described in
threads(3), it will error out when trying to load the chil engine.
This happens whether the calling application is threaded or not. Of
course it could tell the engine to disable the mutex callbacks, but
for instance all utilities supplied with openssl neither set the
callbacks nor disable them. Neither does, for instance, Apache.
This means that a lot of popular applications error out when trying to
run with the chil engine.
I have this week committed a patch to the Apache HTTP Server that sets
up the dynamic locking callbacks:
http://svn.apache.org/viewvc?rev=687550view=rev
This resolves the issue on the Apache side. I would like to also
resolve it also on the OpenSSL side, and see two approaches:
1) Simply do away with the error like so:
--- openssl/engines/e_chil.c2008-08-17 17:22:54.0 -0700
+++ openssl-nolocks/engines/e_chil.c2008-08-21 19:15:37.0 -0700
@@ -588,12 +588,6 @@
hwcrhk_globals.mutex_release = hwcrhk_mutex_unlock;
hwcrhk_globals.mutex_destroy = hwcrhk_mutex_destroy;
}
- else if (CRYPTO_get_locking_callback() != NULL)
- {
-
HWCRHKerr(HWCRHK_F_HWCRHK_INIT,HWCRHK_R_LOCKING_MISSING);
- ERR_add_error_data(1,You HAVE to add dynamic locking
callbacks
via CRYPTO_set_dynlock_{create,lock,destroy}_callback());
- goto err;
- }
}
/* Try and get a context - if not, we may have a DSO but no
This means that non-threaded applications no longer have to set
callbacks they don't need, and that anyone who loads the engine from
multithreaded code, frankly, gets what they ask for in the way of
random crashes and excruciating pain. However, the engine does not
need to be pedantic about this in the former, common, single-threaded
case.
2) Have the engine provide its own callbacks that get set in case the
application does not provide (presumably more suitable) alternatives:
[EMAIL PROTECTED]:~/projects/openssl$ cvs diff engines/e_chil.c
cvs server: /home/openssl/cvs/CVSROOT/config: unrecognized keyword
'UseNewInfoFmtStrings'
Index: engines/e_chil.c
===
RCS file: /home/openssl/cvs/openssl/engines/e_chil.c,v
retrieving revision 1.5
diff -u -r1.5 e_chil.c
--- engines/e_chil.c18 Mar 2006 14:22:20 - 1.5
+++ engines/e_chil.c22 Aug 2008 05:54:45 -
@@ -59,6 +59,7 @@
#include stdio.h
#include string.h
+#include pthread.h
#include openssl/crypto.h
#include openssl/pem.h
#include openssl/dso.h
@@ -103,6 +104,9 @@
static int hwcrhk_mutex_lock(HWCryptoHook_Mutex*);
static void hwcrhk_mutex_unlock(HWCryptoHook_Mutex*);
static void hwcrhk_mutex_destroy(HWCryptoHook_Mutex*);
+static struct CRYPTO_dynlock_value *hwcrhk_dyn_create_function(const
char *file, int line);
+static void hwcrhk_dyn_lock_function(int mode, struct
CRYPTO_dynlock_value *l, const char *file, int line);
+static void hwcrhk_dyn_destroy_function(struct CRYPTO_dynlock_value
*l, const char *file, int line);
/* BIGNUM stuff */
static int hwcrhk_mod_exp(BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
@@ -247,6 +251,11 @@
int lockid;
};
+struct CRYPTO_dynlock_value
+{
+pthread_mutex_t mutex;
+};
+
/* hwcryptohook.h has some typedefs that turn
struct HWCryptoHook_PassphraseContextValue
into HWCryptoHook_PassphraseContext */
@@ -590,9 +599,12 @@
}
else if (CRYPTO_get_locking_callback() != NULL)
{
-
HWCRHKerr(HWCRHK_F_HWCRHK_INIT,HWCRHK_R_LOCKING_MISSING);
- ERR_add_error_data(1,You HAVE to add dynamic locking
callbacks
via CRYPTO_set_dynlock_{create,lock,destroy}_callback());
- goto err;
+ /* Upcalls haven't been set by the
+* application, use our own as
+* fallback. */
+/*
CRYPTO_set_dynlock_create_callback(hwcrhk_dyn_create_function); */
+/*
CRYPTO_set_dynlock_lock_callback(hwcrhk_dyn_lock_function);
*/
+/*
CRYPTO_set_dynlock_destroy_callback(hwcrhk_dyn_destroy_function); */
Re: FIPS certification document for OpenSsl
On Tue, Aug 19, 2008 at 5:10 PM, Steve Marquess [EMAIL PROTECTED] wrote: Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your UNIX machine down to single-user mode during the build process. It probably would not hurt to write down everything that you do in a timestamped log so that you can prove that you have followed the security policy. What he said -- and a good suggestion about the log. Though the single user mode restriction is intended to apply to runtime operation of the module, not necessarily just the module installation (creation). That restriction is in every validation that I've read for software on a general purpose computer. How can that be reconciled with the way such software is actually used? A good question, and one that I can't answer other than to note that the single user restriction is not unique to the OpenSSL FIPS Object Module; in years past I have pursued and been given multiple explanations, some quite elaborate, that I just don't get. The best conjecture I've come up with: Relying on operating system restrictions to protect the sanctity of the module's security boundary effectively moves one of the most important functions of the module's packaging outside the control of the module. For a chip, you can say it's inherent that the chip's pins are the only way to interact across the boundary. If you don't have that inherent quality, then without evidence to the contrary it must be assumed that anything can reach across that boundary. I'm probably completely off-base, but like I said, it's the best conjecture I've got. I'd actually be interested in figuring out what the SELinux extensions would do to help (essentially adding mandatory ACLs to the Linux kernel), but I don't have the cash to pony up for any kind of evaluation or validation attempt for it. :) -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS certification document for OpenSsl
It's FIPS validation, not certification. (Not that I'm entirely sure what the difference is, because when a validation is completed a certificate is issued, but I've been corrected enough times by the reps from the Open Source Software Institute that I don't dare call it anything else. :)) fips-1.2.0 has not completed the validation process, so the documentation does not exist. fips-1.1.2 has been validated with certificate 918. fips-1.1.1 validation is revoked, but was validated with certificate 733. (Interestingly, the csrc.nist.gov site doesn't show it as being revoked, but it is -- I expect this will be fixed in the near future) fips-1.0 is not available, but was validated with certificate 642. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm is the official list, and has links to both the certificates and the security policies. Note YOU MUST FOLLOW THE SECURITY POLICIES EXACTLY OR ELSE THE RESULTING LIBRARY WILL NOT BE COMPLIANT. This includes shutting your UNIX machine down to single-user mode during the build process. It probably would not hurt to write down everything that you do in a timestamped log so that you can prove that you have followed the security policy. -Kyle H On Tue, Aug 19, 2008 at 11:02 AM, Prashant Kumar [EMAIL PROTECTED] wrote: Hello All, Where can I find the documentation for OpenSsl FIPS certification ? Any help is appreciated. Regards, Prashant. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?
I'm sorry -- my comment was to David Schwartz (I realized both of you were named David, but failed to realize that you also had a surname that started with S). -Kyle H On Thu, Aug 7, 2008 at 11:44 AM, David Shambroom [EMAIL PROTECTED] wrote: Kyle, I didn't say that /dev/urandom was safe to use for cryptographic purposes. It isn't, and I didn't then and don't now advise its use. I said it never blocks. It doesn't. So what was incorrect? Kyle Hamilton wrote: David S: to my knowledge you're at least somewhat incorrect, and part of your advice is rather dangerous to rely upon (from a cryptographic theory perspective). /dev/urandom will never, under normal circumstances, block -- its output is generated algorithmically by the random/urandom device driver. (It's akin to reading from /dev/null or /dev/zero, in that the read is always handled by the kernel driver without having to wait for anything.) /dev/urandom will not block. /dev/random will block if there isn't enough entropy stirred into it. And yes, it is possible to run out the entropy pool. The amount of chaos that you stir in is the amount of chaos that you can pull out -- everything else is deterministic, and as the man page says there may be a theoretical way that the pseudorandom number generator can be attacked (though one is currently not known in the nonclassified literature) with the result that the keys generated will be predictable. If the pool is never seeded, the randomness won't ever be really random. If the pool is seeded once, the randomness will be random for as long as the amount of entropy in the seed holds out. After this, the numbers generated won't really be random. If the pool is continually re-seeded, the randomness will be random for as long as the amount of entropy in the seeds fed into it holds out. After this, the numbers generated won't really be random, until more entropy is stirred in -- and even then, that will be exhausted in the same way. The only way to guarantee that your numbers are truly cryptographically secure is to use /dev/random and deal with the fact that it will block until there's been enough entropy seeded into the randomness pool. Otherwise, many random number generators use a linear-feedback shift register with a periodicity of 2**56. That's approximately the same amount of keyspace as DES, and the output over multiple successions of readings of 2**56 bytes will repeat and not be suitably random. (If an attacker can figure out the state of your PRNG, the attacker can figure out your next-generated secret randomness. This is why the Debian debacle was so serious, and why only a few thousand possible keys were generated by the vulnerable implementations -- the randomness wasn't.) I'd certainly like to see references to the contrary, if they exist -- my references are the Handbook of Applied Cryptography and Applied Cryptography 2nd Ed. -Kyle H On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz [EMAIL PROTECTED] wrote: David Shambroom wrote: You're right: You are completely wrong. /dev/urandom never blocks. See the man page. Is this is the excerpt from the man page you are referring to? A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified liter- ature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead. If so, this doesn't say that /dev/urandom never blocks. It just says that it will not block waiting for more entropy. In fact, this paragraph is horribly misleading, because it suggests that the worst thing /dev/urandom can do is return random values with a theoretical vulnerability. Alas, this is not true. The /dev/urandom interface will happily return entirely predictable values if the pool was never seeded. If the entropy pool was ever seeded, then it can produce cryptographically-strong entropy forever. You cannot run it out of entropy. However, if it was *never* seeded, it cannot produce even a single byte of crypotgraphically-strong entropy. Reading back over the post you are responding to, I realize that it reads to mean the complete opposite of what I was trying to say. I'm not sure how I managed to do that. I was very sloppy with my terms. What I was trying to address was the case where the pool was never seeded, not the case where the pool runs out of entropy. However, reading my words, it seems I somehow said the exact opposite of what I was thinking! Sadly, Linux suffers from a three bears problem. The /dev/random implementation will block even if cryptographically-strong
Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?
On Thu, Aug 7, 2008 at 6:59 AM, David Schwartz [EMAIL PROTECTED] wrote: Kyle Hamilton wrote: David S: to my knowledge you're at least somewhat incorrect, and part of your advice is rather dangerous to rely upon (from a cryptographic theory perspective). You are at least somewhat incorrect too. And yes, it is possible to run out the entropy pool. The amount of chaos that you stir in is the amount of chaos that you can pull out -- everything else is deterministic, and as the man page says there may be a theoretical way that the pseudorandom number generator can be attacked (though one is currently not known in the nonclassified literature) with the result that the keys generated will be predictable. This is correct, but doesn't conflict with anything that I've said. If the pool is never seeded, the randomness won't ever be really random. Right. If the pool is seeded once, the randomness will be random for as long as the amount of entropy in the seed holds out. After this, the numbers generated won't really be random. Right, but they will be cryptogrpahically secure. Forever. Uh, no. If you seed it with 1 bit of entropy, then there's only 2**1 possible output chains. Entropy is observation of chaos, which is supposed to make all possible values of the entropy pool equally possible -- and the less entropy you stir in, the more likely it is that someone who figures out what's come before is going to be able to figure out what's going to come in the future. The only way to guarantee that your numbers are truly cryptographically secure is to use /dev/random and deal with the fact that it will block until there's been enough entropy seeded into the randomness pool. Nope. That does not guarantee that the numbers are truly cryptogrpahically secure. There could be a bug in the /dev/random implementation. A cosmic ray may cause the PRNG software to be bypassed. If you get to argue that there might be a weakness in the PRNG algorithm such that it does not generate cryptogrpahically-secure numbers even if it was seeded, then I get to argue that there might be a weakness in your RNG alogorithm. Technically, if you want to absolutely guarantee that you have truly cryptographically secure numbers you should perform thermodynamic analysis of case air-flows, or measure the periodicity of the release of electrons or photons from radioactive nuclei, or directly measure other phenomena that are nondeterministic. The /dev/random implementation measures as much of the nondeterministic phenomena as is possible in a typical computer system, and uses that to seed the random number generator. /dev/random and /dev/urandom have historically shared the same implementation. The difference is that /dev/random blocks when it has calculated that its entropy pool is exhausted, and /dev/urandom does not. Otherwise, many random number generators use a linear-feedback shift register with a periodicity of 2**56. That's approximately the same amount of keyspace as DES, and the output over multiple successions of readings of 2**56 bytes will repeat and not be suitably random. That seems pretty boneheaded to me, considering how trivial it is to create PRNGs with much higher periods. In any event, Linux's /dev/urandom implementation has a periodicity of way over 2^64 bytes. Sure, it's possible to create PRNGs with much higher periods, but it's rather difficult to create /good/ PRNGs with much higher periods. Even then, though, all PRNGs have the property that their output is deterministic... and deterministic is the antithesis of cryptographically secure. (If an attacker can figure out the state of your PRNG, the attacker can figure out your next-generated secret randomness. This is why the Debian debacle was so serious, and why only a few thousand possible keys were generated by the vulnerable implementations -- the randomness wasn't.) The whole point of the design of Linux's /dev/urandom implementation is that if it was ever seeded, no matter how much output you have made, an attacher can never determine the state of your PRNG. This was an explicit design goal. The whole point of cryptosystem implementation is so that if the key is properly kept secret, no matter how much material is encrypted under the key, an attacker can never determine the key or the plaintext. This is an explicit design goal. Of course, no cryptosystem has ever been found to have an unknown weakness or buggy implementation, right? I'd certainly like to see references to the contrary, if they exist -- my references are the Handbook of Applied Cryptography and Applied Cryptography 2nd Ed. Linux's /dev/urandom implementation was specifically made such that if it was ever seeded, no amount of known output would compromise the state of the PRNG. So long as it is initially seeded, the only risk is that the algorithm has some unknown weakness or bug. I'll vote unknown weakness. Give
Re: [openssl.org #1727] No License error getting
IBM limited the C compiler on AIX to only allow a certain number of simultaneous invocations systemwide, based on the number of licenses that have been purchased and installed on the system. If you have 1 simultaneous-invocation license, then anyone else who invokes the compiler will block you from being able to invoke it until their invocation completes -- and then when yours is going, it will block theirs. Fortunately, there's a document from IBM that describes why you might consider using GCC instead of the built-in C compiler. It's available at http://www.ibm.com/developerworks/aix/library/au-gnu.html . However: Your issue is NOT with OpenSSL. This is an AIX-platform generic issue that affects much more than just OpenSSL compilation. As such, it is inappropriate for this venue. The bottom line is that you need to buy more licenses for your built-in C compiler, or you need to switch to using GCC (which doesn't have the simultaneous invocation limitation). OpenSSL itself is compiling just fine, albeit slowly, from the make output you've posted. -Kyle H On Thu, Aug 7, 2008 at 1:11 AM, seeni vasan via RT [EMAIL PROTECTED] wrote: Dear Lutz, Thanks for your reply. C compiler is built in AIX. Regds seenivasan.G --- On Wed, 8/6/08, Lutz Jaenicke via RT [EMAIL PROTECTED] wrote: From: Lutz Jaenicke via RT [EMAIL PROTECTED] Subject: [openssl.org #1727] No License error getting To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Date: Wednesday, August 6, 2008, 7:03 PM It seems you do not have enough licenses for your C compiler which is thus locking up. Sincere regards, Lutz Dear Lutz, Thanks for your reply. C compiler is built in AIX. Regds seenivasan.G --- On Wed, 8/6/08, Lutz Jaenicke via RT [EMAIL PROTECTED] wrote: From: Lutz Jaenicke via RT [EMAIL PROTECTED] Subject: [openssl.org #1727] No License error getting To: [EMAIL PROTECTED] Cc: openssl-dev@openssl.org Date: Wednesday, August 6, 2008, 7:03 PM It seems you do not have enough licenses for your C compiler which is thus locking up. Sincere regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Couldn't obtain random bytes in sshd - problem in RAND_poll?
David S: to my knowledge you're at least somewhat incorrect, and part of your advice is rather dangerous to rely upon (from a cryptographic theory perspective). /dev/urandom will never, under normal circumstances, block -- its output is generated algorithmically by the random/urandom device driver. (It's akin to reading from /dev/null or /dev/zero, in that the read is always handled by the kernel driver without having to wait for anything.) /dev/urandom will not block. /dev/random will block if there isn't enough entropy stirred into it. And yes, it is possible to run out the entropy pool. The amount of chaos that you stir in is the amount of chaos that you can pull out -- everything else is deterministic, and as the man page says there may be a theoretical way that the pseudorandom number generator can be attacked (though one is currently not known in the nonclassified literature) with the result that the keys generated will be predictable. If the pool is never seeded, the randomness won't ever be really random. If the pool is seeded once, the randomness will be random for as long as the amount of entropy in the seed holds out. After this, the numbers generated won't really be random. If the pool is continually re-seeded, the randomness will be random for as long as the amount of entropy in the seeds fed into it holds out. After this, the numbers generated won't really be random, until more entropy is stirred in -- and even then, that will be exhausted in the same way. The only way to guarantee that your numbers are truly cryptographically secure is to use /dev/random and deal with the fact that it will block until there's been enough entropy seeded into the randomness pool. Otherwise, many random number generators use a linear-feedback shift register with a periodicity of 2**56. That's approximately the same amount of keyspace as DES, and the output over multiple successions of readings of 2**56 bytes will repeat and not be suitably random. (If an attacker can figure out the state of your PRNG, the attacker can figure out your next-generated secret randomness. This is why the Debian debacle was so serious, and why only a few thousand possible keys were generated by the vulnerable implementations -- the randomness wasn't.) I'd certainly like to see references to the contrary, if they exist -- my references are the Handbook of Applied Cryptography and Applied Cryptography 2nd Ed. -Kyle H On Thu, Aug 7, 2008 at 2:13 AM, David Schwartz [EMAIL PROTECTED] wrote: David Shambroom wrote: You're right: You are completely wrong. /dev/urandom never blocks. See the man page. Is this is the excerpt from the man page you are referring to? A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified liter- ature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead. If so, this doesn't say that /dev/urandom never blocks. It just says that it will not block waiting for more entropy. In fact, this paragraph is horribly misleading, because it suggests that the worst thing /dev/urandom can do is return random values with a theoretical vulnerability. Alas, this is not true. The /dev/urandom interface will happily return entirely predictable values if the pool was never seeded. If the entropy pool was ever seeded, then it can produce cryptographically-strong entropy forever. You cannot run it out of entropy. However, if it was *never* seeded, it cannot produce even a single byte of crypotgraphically-strong entropy. Reading back over the post you are responding to, I realize that it reads to mean the complete opposite of what I was trying to say. I'm not sure how I managed to do that. I was very sloppy with my terms. What I was trying to address was the case where the pool was never seeded, not the case where the pool runs out of entropy. However, reading my words, it seems I somehow said the exact opposite of what I was thinking! Sadly, Linux suffers from a three bears problem. The /dev/random implementation will block even if cryptographically-strong randomness is available. The /dev/urandom implementation will happilly hand you numbers that are not cryptograhically-strong. There is no just right interface that will tell you whether or not cryptographically-strong randomness is available and let you block waiting for it if you choose to. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org
Re: IPv6 support in OpenSSL
openssl-0.9.8h/apps/s_socket.c - 12 lines openssl-0.9.8h/crypto/bio/b_sock.c - 5 lines openssl-0.9.8h/crypto/bio/bio_err.c - 1 line (error state BIO_R_GETHOSTBYNAME_ADDR_IS_NOT_AF_INET) openssl-0.9.8h/crypto/bio/bss_conn.c - 2 lines openssl-0.9.8h/demos/easy_tls/test.c - 3 lines openssl-0.9.8h/demos/state_machine/state_machine.c - 2 lines openssl-0.9.8h/demos/tunala/ip.c - 2 lines The BIO library is what I was referring to, primarily, that specifically supports AF_INET. Yes, you can use SSL_set_fd() to associate a TCP6 handle (which can be written to with write() and read from with read()) to an SSL connection. The housekeeping work is up to you as the client of the library, though, not something that can be left to the library. -Kyle H On Tue, Aug 5, 2008 at 6:53 AM, Darryl Miles [EMAIL PROTECTED] wrote: Kyle Hamilton wrote: I cannot find any reference to AF_INET6 in the sources, though I can find AF_INET. This means that IPv6 is not supported. Surely that depends on the files where you found matches. I would suspect most of the code with AF_INET is test or demonstration code not the actual library. So sure it maybe possible to claim openssl.exe the utility tool does not support IPV6 in all the features that support IPV4 however the main event libssl.so/libcrypto.so might not reference AF_ since it works on already open socket handles (with no regard for the specific transport mechanism). Darryl __ 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: Last portion SSL_read ....
If the firewall blocks FTP, and there is no proxy that responds to requests for FTP URLs, the browser will not be able to follow the link. Do you have a webserver (http or https) upon which you can place the file? -Kyle H On Wed, Jul 30, 2008 at 2:11 AM, petekolle123 [EMAIL PROTECTED] wrote: ftp://erbse:[EMAIL PROTECTED]/ Please copy this link above in your browser address line your browser will be able to follow this link -- View this message in context: http://www.nabble.com/Last-portion-SSL_read-only-after-a-SSL_write-.--Please-Help.-tp18717834p18729136.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 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: IPv6 support in OpenSSL
I cannot find any reference to AF_INET6 in the sources, though I can find AF_INET. This means that IPv6 is not supported. Michael: software does need to support IPv6 in order to use it without going through a gateway of some kind. The reason is that nobody's figured out how to fit 128 bits of address data into the 32 bits allowed by IPv4. Your local manual pages can describe how to use IPv6 in software -- the most useful of which is section 4, ip6. Contrast this to section 4, ip. -Kyle H On Wed, Jul 30, 2008 at 8:02 AM, Michael Sierchio [EMAIL PROTECTED] wrote: Ravindra wrote: I'm looking for information regarding IPv6 support in OpenSSL. Which is the first and stable version that adds support for IPv6 in OpenSSL ? SSL operates atop TCP. Whether this supports IPv6 is left as an exercise for the reader. - M PS Does your web browser support IPv6? Does your monitor? How about your keyboard? __ 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: IPv6 support in OpenSSL
Also: My web browser does support IPv6. (kame.net shows the moving image.) My monitor and keyboard do not create socket connections, so they have no need to. -Kyle H On Wed, Jul 30, 2008 at 8:02 AM, Michael Sierchio [EMAIL PROTECTED] wrote: Ravindra wrote: I'm looking for information regarding IPv6 support in OpenSSL. Which is the first and stable version that adds support for IPv6 in OpenSSL ? SSL operates atop TCP. Whether this supports IPv6 is left as an exercise for the reader. - M PS Does your web browser support IPv6? Does your monitor? How about your keyboard? __ 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: [PATCH] PURIFY and valgrind, 2nd round
Debian c suffered from simply removing all calls to seed the random number generator with enough entropy to make it secure. When it comes to entropy, every little bit helps. The calls to add uninitialized static variable locations are never relied upon to seed the PRNG with enough entropy, but they are used to stir the pot just a little bit more. This is probably one of the most-frequently asked questions. http://openssl.org/support/faq.html#PROG14 (I think the 'answer' for that needs to be changed to include some of the prior discussion on the topic...) This is probably also one of the most-frequently answered questions. Look in the openssl-users and openssl-dev archives for the past year and you'll see people with much more knowledge of entropy than me discussing this topic, at length. -Kyle H On Fri, Jul 18, 2008 at 9:47 AM, Frederic Heem [EMAIL PROTECTED] wrote: Hi, The previous patch didn't fully work due a mysterious valgrind issue (something related to loading libssl multiple time through dl_open). This patch is simply what has Robert suggested. By the way, can someone explain me why some uninitialized static variables are used create a random number ? At least, on some embedded system, static variables are initialized to 0, therefore, can the keys be weak on these system ? I just want to avoid the security hole DebianCo have suffered recently. Best Regards, Frederic Heem __ --- NOTICE --- This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. Personal and corporate data submitted will be used in a correct, transparent and lawful manner. The data collected will be processed in paper or computerized form for the performance of contractual and lawful obligations as well as for the effective management of business relationship. The data processor is Telsey S.p.A. The data subject may exercise all the rights set forth in art. 7 of Law by Decree 30.06.2003 n. 196 as reported in the following url http://www.telsey.com/privacy.asp. __ 798t8RfNa6Dl8Ilf __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS compliance for Diffie-Hellman
fips-1.1.2 does not have validation for Diffie-Hellmann. Which version are you looking at? -Kyle H On Tue, Jul 8, 2008 at 2:57 AM, Nilay Tripathi [EMAIL PROTECTED] wrote: Hi All, I have a query regarding FIPS compliance for Diffie-Hellman api's in the openssl stack. FIPS uses the recommendation for pairwise-key establishment schemes from NIST. Document is SP800-56A. Rev.1 As per FIPS compliance requirement for DH, there are a couple of KAT (Known Answer Test) specified in the aforementioned document (which are specified in Sec. 5.6.2.4 and Sec. 5.7.1.1). [Sec. 5.6.2.4 - FFC Full Public Key Validation] [Sec. 5.7.1.1 - FFC DH Primitive] Generating 'p' randomly as a safe prime and using 'g' order as 5, the keys generated are not consistently passing Sec 5.6.2.4 KAT test. The public key does not fall into 'q' cyclic group where 'q' is defined as [q=(p-1)/2] and is a prime number. If I loop for few times I do get such generated values which passes this KAT. But I was expecting that FIPS compliant DH api's in openssl stack will generate and return only such values which satisfy this KAT. The only difference I found in normal and FIPS compliant DH code is that in latter, FIPS_self_tests api is also called; which really doesn't help in the issue noted above. I would really appreciate if anyone can throw some light on the state and any development on this issue. Regards, Nilay Tripathi One Convergence __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS compliance for Diffie-Hellman
fips-1.1 is not available, fips-1.1.1 is revoked, fips-1.1.2 is current (without DH), fips-1.2.0 is currently submitted for validation. Steve M (of the OSS Institute, which is the sponsor for the validation) stated that the fast-tracking of the fips-1.1.2 validation was possible because of the changes to the PRNG, but that the requirements for DH validation changed between the validation of 1.1.1 and 1.1.2. He has also stated that changes necessary for DH validation have been integrated into the 1.2.0 codebase. (Since I'm not intimately familiar with the code, I can't say one way or the other.) However, the code that was submitted for validation as fips-1.2.0 can be found at ftp://ftp.openssl.org/snapshot/openssl-fips-test-1.2.0.tar.gz if you're interested in poking at it. -Kyle H On Tue, Jul 8, 2008 at 3:36 AM, Nilay Tripathi [EMAIL PROTECTED] wrote: Thanks Kyle, Yes I was looking at fips-1.1.2 version only. Can you help me with some information, whether FIPS compliance for DH in openssl is available already in some other revision or expected in which future release down the line. Also, since the generation of 'q' cyclic order public key does not look deterministic to me, what is the approach which can be taken to tackle this compliance issue. Appreciate your help!! Nilay On Tue, Jul 8, 2008 at 3:48 PM, Kyle Hamilton [EMAIL PROTECTED] wrote: fips-1.1.2 does not have validation for Diffie-Hellmann. Which version are you looking at? -Kyle H On Tue, Jul 8, 2008 at 2:57 AM, Nilay Tripathi [EMAIL PROTECTED] wrote: Hi All, I have a query regarding FIPS compliance for Diffie-Hellman api's in the openssl stack. FIPS uses the recommendation for pairwise-key establishment schemes from NIST. Document is SP800-56A. Rev.1 As per FIPS compliance requirement for DH, there are a couple of KAT (Known Answer Test) specified in the aforementioned document (which are specified in Sec. 5.6.2.4 and Sec. 5.7.1.1). [Sec. 5.6.2.4 - FFC Full Public Key Validation] [Sec. 5.7.1.1 - FFC DH Primitive] Generating 'p' randomly as a safe prime and using 'g' order as 5, the keys generated are not consistently passing Sec 5.6.2.4 KAT test. The public key does not fall into 'q' cyclic group where 'q' is defined as [q=(p-1)/2] and is a prime number. If I loop for few times I do get such generated values which passes this KAT. But I was expecting that FIPS compliant DH api's in openssl stack will generate and return only such values which satisfy this KAT. The only difference I found in normal and FIPS compliant DH code is that in latter, FIPS_self_tests api is also called; which really doesn't help in the issue noted above. I would really appreciate if anyone can throw some light on the state and any development on this issue. Regards, Nilay Tripathi One Convergence __ 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: FIPS SSHv2 KDF
With the caveat that any changes you make will not have validation, http://www.cryptopp.com/ has a C++ library which has certain binary versions FIPS-validated. It may be helpful as reference material. -Kyle H On Tue, Jul 8, 2008 at 4:06 AM, Nilay Tripathi [EMAIL PROTECTED] wrote: Hi, I am using openssl fips 1.1.2 stack. Can someone please help me with some source for DH KDF specified in Sec 5.8 of SP800_56A doc. Thanks, Nilay __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1702] AutoReply: FW: IAVA notice 0036 retraction
It's extremely unfortunate that anyone would want to remove tracking information about queries. I don't think it's worth fully deleting the request -- it's important to track information about the confusion that the current advisory wording leaves in its readers, so that perhaps feedback can be given to CERT and other advisory organizations so that the advisories can be reworded to be more clear in the future. -Kyle H On Mon, Jun 16, 2008 at 4:58 AM, JTF-GNO IAVM via RT [EMAIL PROTECTED] wrote: Request to have the subject trouble ticket removed from your web site. The intention of the original email was to request additional information from the vendor regarding updates to your software. Please remove any and all information from your blog/website regarding our request for information. If you have any questions, please give me a call or reply. Robert E. Hyatt 703.601.6529 -Original Message- From: The default queue via RT [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 8:27 AM To: JTF-GNO IAVM Subject: [openssl.org #1702] AutoReply: FW: IAVA notice 0036 retraction Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: FW: IAVA notice 0036 retraction, a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [openssl.org #1702]. Please include the string: [openssl.org #1702] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, [EMAIL PROTECTED] - __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
