RE: Wider fallout from Debian issue?
> David Schwartz wrote: > > > Every known key, provided there are not too many known keys, is weak. > > Once again, you have a very idiosyncratic lexicon of cryptographic > terms. How about if we use these words the way cryptographers do? > > A weak key is one that causes a cipher to leak private data in the > ciphertext, or reveal key structure in a timing attack, or makes > the implementation vulnerable to an adaptive chosen-plaintext attack, > etc. A diminished keyspace reduces the number of keys to be attempted > in a brute force attack. This may or may not be significant. If the > reduction in keyspace means a brute force attack effort is reduced by > half to merely half the life of the universe, that might be a worthwhile > tradeoff. Okay, I guess I give up. I now realize that I had no idea what you meant in your past few comments. What relevance do you think this notion of weak keys has to do with this issue, since you were the one who brought it up? The only issue here is known keys. The keys the Debian bug causes OpenSSL to choose are not weak in this sense. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
David Schwartz wrote: Every known key, provided there are not too many known keys, is weak. Once again, you have a very idiosyncratic lexicon of cryptographic terms. How about if we use these words the way cryptographers do? A weak key is one that causes a cipher to leak private data in the ciphertext, or reveal key structure in a timing attack, or makes the implementation vulnerable to an adaptive chosen-plaintext attack, etc. A diminished keyspace reduces the number of keys to be attempted in a brute force attack. This may or may not be significant. If the reduction in keyspace means a brute force attack effort is reduced by half to merely half the life of the universe, that might be a worthwhile tradeoff. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
On Wed, May 28, 2008 at 04:31:20PM -0700, David Schwartz wrote: > > Only against random attacks of course, if all attackers first check these > > keys, then removing them strengthens the algorithm against (non-random) > > brute-force attack. This said, the effort of explicitly avoiding these > > is probably wasted (unless one suspects one has a identically weak RNG). > > I realize it's counter-intuitive, but even this is wrong. Suppose that > there's an attack tool that everyone uses to attack a particular algorithm. > It brute-forces passwords and follows a particular pattern. > > If you use an implementation that is known to not use the first 10,000 keys > this algorithm tests, attackers will respond by skipping those 10,000 keys. > The net result will only be a reduction in the keyspace. You are changing the premise. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Wider fallout from Debian issue?
> On Wed, May 28, 2008 at 03:38:47PM -0700, David Schwartz wrote: > > In principle, specifically avoiding these keys weakens the > > algorithm by reducing the keyspace. > > > Only against random attacks of course, if all attackers first check these > keys, then removing them strengthens the algorithm against (non-random) > brute-force attack. This said, the effort of explicitly avoiding these > is probably wasted (unless one suspects one has a identically weak RNG). > > -- > Viktor. I realize it's counter-intuitive, but even this is wrong. Suppose that there's an attack tool that everyone uses to attack a particular algorithm. It brute-forces passwords and follows a particular pattern. If you use an implementation that is known to not use the first 10,000 keys this algorithm tests, attackers will respond by skipping those 10,000 keys. The net result will only be a reduction in the keyspace. Even if every attacker tests a particular key first, it is a net loss in security to specifically avoid that key if you randomly chose it. Really. If you honestly and truly randomly selected the key, you should go with it. Otherwise, there's one less key for an attacker to test. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
On Wed, May 28, 2008 at 03:38:47PM -0700, David Schwartz wrote: > In principle, specifically avoiding these keys weakens the algorithm by > reducing the keyspace. > Only against random attacks of course, if all attackers first check these keys, then removing them strengthens the algorithm against (non-random) brute-force attack. This said, the effort of explicitly avoiding these is probably wasted (unless one suspects one has a identically weak RNG). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Wider fallout from Debian issue?
> David Schwartz wrote: > > ... Suppose I include a randomish > > string in my message "46e8bd8ceae57f8b7af66536e7859bad". Any > > attacker might > > see this message -- it's public. So he can certainly try that > > string as your > > password. So will you now run off and add it to a blacklist, since it's > > clearly now a weak password? > I suppose the distinction between "known" and "weak" is too fine > a semantic point for you? Every known key, provided there are not too many known keys, is weak. If it's possible for there to be so many known keys that an algorithm is compromised, something would have to be seriously broken with that algorithm in the first place. If a key is made known randomly, it is not longer any weaker than any other key. These keys are not any weaker than any other key unless you choose them because of the bug. If someone makes a buggy random number generator that always outputs 4, you don't modify your random number generator to never produce 4. Whether 4 is strong or weak depends upon whether you chose it randomly or not. In principle, specifically avoiding these keys weakens the algorithm by reducing the keyspace. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
* Deane Sloan wrote on Thu, May 29, 2008 at 04:47 +1200: > stated, the overall risk of generating such a key on an unaffected > system is (extremely?) small for the security that a 2048bit RSA private > key is intended for? The risk to generate one specific key of 2^16 (or how small was the key space?) should be `roughly the same' compared to 2048 Bit RSA, as to generate one specific key (when assuming perfect strong generation). That means, the risk that you accidently generate exactly the same key as I generated is of almost the same order of magnitude. This also was acceptable before the debian issue :) Of course you are right, this probably happens all few billion years in one of the known universes and theoretically it could even happen with the key you are generating right now :-) If someone would not accept the risk of randomness / entropy with their properties, using cryptography in this case probably would be no option, but I think in all `practical situations' such extremely unbelievable rare events (as strong key generation producing collisions) should not be overstated. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Verify Signature
Hello, We have a PHP based system on a FreeBSD box that is supposed to talk to a C# .NET app (Windows XP). We have these messages going to .NET as signed SMIME correspondence. However .NET seems unable to read these and fails with an ASN.1 exception. So the decision has been made to wrap OpenSSL's libraries on Windows and making them accessible to .NET. I have the SMIME message as a string on the .NET side, How would i go about this? Is there an easier way, another method? My hope is a method like this: public static bool VerifyMessage(byte[] pubcert, string smime, ref string message) Any thoughts? Glenn R. Martin Developer - DS Media Labs, Inc. dsMediaLabs.com Email Disclaimer This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail message by mistake and delete it from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that may arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.
Verify Signature
Hello, We have a PHP based system on a FreeBSD box that is supposed to talk to a C# .NET app (Windows XP). We have these messages going to .NET as signed SMIME correspondence. However .NET seems unable to read these and fails with an ASN.1 exception. So the decision has been made to wrap OpenSSL's libraries on Windows and making them accessible to .NET. I have the SMIME message as a string on the .NET side, How would i go about this? Is there an easier way, another method? My hope is a method like this: public static bool VerifyMessage(byte[] pubcert, string smime, ref string message) Any thoughts? Glenn R. Martin Developer - DS Media Labs, Inc. dsMediaLabs.com Email Disclaimer This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail message by mistake and delete it from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that may arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.
Re: Question about development path
--On Wednesday, May 28, 2008 12:19:25 -0500 Paul Schmehl <[EMAIL PROTECTED]> wrote: --On Wednesday, May 28, 2008 18:09:06 +0200 "Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote: OpenSSL has supported sha1+RSA from the very beginning. You wouldn't expect that error if it didn't recognize the algorithm even for totally unsupported algorithms OpenSSL will still parse the certificates. I'd say that whatever you are feeding into 'openssl pkcs12' is not in PKCS#12 format. HmmmI have no doubt that you know exactly what you're talking about. However, both certs were both exported from IE on Windows and then parsed by openssl. According to Windows they are exported in pkcs12 format. AFAIK, the only thing that's changed is the encryption algorithm used by Verisign. Is there some way I can use openssl to see what's inside the cert that doesn't work? If I sent the certs to you, could you determine what's changed? Following up on my own response.your answer led me to the resolution of the problem. Since I couldn't do anything with that cert using openssl, I looked at it with strings. Type:This file is encrypted with SafeBoot Content Encryption - If you see this message you must not edit or save this file, doing so will irretrievably corrupt the data )_(*&)(*&_*&_*& I exported another copy to a location I knew to not be encrypted with Safeboot, and openssl parses it just fine. Thanks for pointing me in the right direction. Wish I thought of this months ago. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Operation not permitted on SSL_Write()
Hello, I'm using non-blicking sockets with an event-reporting mechanism (epoll() on linux, kqueue() on freeBSD and select() elsewhere). When I try and send bigger amount of data (eg: a file) via a connection via OpenSSL, I eventually get "Operation not permitted" error on SSL_Write(). It always happens after I get a SSL_ERROR_WANT_WRITE first. After that I set the socket to "wait for epoll() to report that I can write again" and wait for it. Epoll tells me that I can write but I get the not permitted error after that. Does OpenSSL return this error on repeated non-blocking SSL_Write when the buffers are full? I'm currently trying to find out if there's an error in my state-machine logic but I'd like to know if the permission error could result from such. Thanks Ales Katona __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question about development path
--On Wednesday, May 28, 2008 18:09:06 +0200 "Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote: OpenSSL has supported sha1+RSA from the very beginning. You wouldn't expect that error if it didn't recognize the algorithm even for totally unsupported algorithms OpenSSL will still parse the certificates. I'd say that whatever you are feeding into 'openssl pkcs12' is not in PKCS#12 format. HmmmI have no doubt that you know exactly what you're talking about. However, both certs were both exported from IE on Windows and then parsed by openssl. According to Windows they are exported in pkcs12 format. AFAIK, the only thing that's changed is the encryption algorithm used by Verisign. Is there some way I can use openssl to see what's inside the cert that doesn't work? If I sent the certs to you, could you determine what's changed? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question about development path
On Wed, May 28, 2008, Paul Schmehl wrote: > We use Verisign certs for signing and encrypting our email. This year > Verisign changed the algorithm used for their certs from md5RSA to sha1RSA. > Now all my unix and mac clients can no longer import their certs because > openssl apparently doesn't understand that algorithm. > > This is the result of the following command for an md5RSA cert - openssl > pkcs12 -in certname: > > Bag Attributes: > subject=/O=The University of Texas System/OU=VeriSign Trust > Network/OU=Terms of use at https://www.verisign.com/rpa (c)99/OU=Class 2 CA > - OnSite Individual Subscriber/CN=The University of Texas at Dallas CA > issuer=/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification > Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use > only/OU=VeriSign Trust Network > > This is the result of the same command for a sha1RSA cert: > > 88566:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong > tag:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1/tasn_dec.c:1294: > 88566:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 > error:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1/tasn_dec.c:380:Type=PKCS12 > > Is there a roadmap in the development plan for including sha1RSA in the > algorithms that openssl understands? > OpenSSL has supported sha1+RSA from the very beginning. You wouldn't expect that error if it didn't recognize the algorithm even for totally unsupported algorithms OpenSSL will still parse the certificates. I'd say that whatever you are feeding into 'openssl pkcs12' is not in PKCS#12 format. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Wider fallout from Debian issue?
Thank you Victor for your succinct clarification and to David and Michael for their responses. To tie this off - is it fair to say that the impact of say 2048bit RSA SSL(etc) using a private key in the affected range is a valid consideration/concern, however in combination with the likelihood stated, the overall risk of generating such a key on an unaffected system is (extremely?) small for the security that a 2048bit RSA private key is intended for? Chuckle - so I'm basically worried about getting struck by lightening with this concern, whilst at the same time I'm playing with matches and kerosene... Thanks again, Deane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni Sent: Thursday, May 29, 2008 3:37 AM To: openssl-users@openssl.org Subject: Re: Wider fallout from Debian issue? On Wed, May 28, 2008 at 08:09:16AM -0700, Michael Sierchio wrote: > David Schwartz wrote: > > > ... Suppose I include a randomish > >string in my message "46e8bd8ceae57f8b7af66536e7859bad". Any attacker > >might see this message -- it's public. So he can certainly try that > >string as your password. So will you now run off and add it to a > >blacklist, since it's clearly now a weak password? > > I suppose the distinction between "known" and "weak" is too fine a > semantic point for you? If there exists a known subset of keys large enough for random keys to have appreciable probability of being a member of that set, the keyspace is too small. The RSA keyspace is not "small" in this sense, in fact because it succumbs to *analytic* attacks long before exhaustive key-space search brute-force attacks, the odds of a random RSA key being in a small set of keys are rediculously low. The OP's concern is unwarranted. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL_CTX_add_session without new handshake
Hi everybody. I have a SSL client and two SSL servers: auth server and, for example, file server. Client connects to the auth server, handshakes with it, then auth server sends socket descriptor and SSL session to the file server via IPC. File server reads socket descriptor, duplicates it, then it reads SSL session and adds it to the SSL context with 'SSL_CTX_add_session' call. According to the examples and man, server and client must do handshaking after this call, but the problem is, that client nothing knows about new SSL server and SSL session exchange. How can I add new SSL session without any new handshake? -- Roman
Question about development path
We use Verisign certs for signing and encrypting our email. This year Verisign changed the algorithm used for their certs from md5RSA to sha1RSA. Now all my unix and mac clients can no longer import their certs because openssl apparently doesn't understand that algorithm. This is the result of the following command for an md5RSA cert - openssl pkcs12 -in certname: Bag Attributes: subject=/O=The University of Texas System/OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)99/OU=Class 2 CA - OnSite Individual Subscriber/CN=The University of Texas at Dallas CA issuer=/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network This is the result of the same command for a sha1RSA cert: 88566:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1/tasn_dec.c:1294: 88566:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1/tasn_dec.c:380:Type=PKCS12 Is there a roadmap in the development plan for including sha1RSA in the algorithms that openssl understands? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
On Wed, May 28, 2008 at 08:09:16AM -0700, Michael Sierchio wrote: > David Schwartz wrote: > > > ... Suppose I include a randomish > >string in my message "46e8bd8ceae57f8b7af66536e7859bad". Any attacker might > >see this message -- it's public. So he can certainly try that string as > >your > >password. So will you now run off and add it to a blacklist, since it's > >clearly now a weak password? > > I suppose the distinction between "known" and "weak" is too fine > a semantic point for you? If there exists a known subset of keys large enough for random keys to have appreciable probability of being a member of that set, the keyspace is too small. The RSA keyspace is not "small" in this sense, in fact because it succumbs to *analytic* attacks long before exhaustive key-space search brute-force attacks, the odds of a random RSA key being in a small set of keys are rediculously low. The OP's concern is unwarranted. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
David Schwartz wrote: > ... Suppose I include a randomish string in my message "46e8bd8ceae57f8b7af66536e7859bad". Any attacker might see this message -- it's public. So he can certainly try that string as your password. So will you now run off and add it to a blacklist, since it's clearly now a weak password? I suppose the distinction between "known" and "weak" is too fine a semantic point for you? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Wider fallout from Debian issue?
> Finally - how real is this concern? What is the probability that say a > 2048bit generated key could fall into the 32,767 keys in the metasploit > SSH example on unaffected systems? > > Best Regards, > > Deane If you think about it, it doesn't make sense. Suppose I include a randomish string in my message "46e8bd8ceae57f8b7af66536e7859bad". Any attacker might see this message -- it's public. So he can certainly try that string as your password. So will you now run off and add it to a blacklist, since it's clearly now a weak password? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote: > Finally - how real is this concern? What is the probability that say a > 2048bit generated key could fall into the 32,767 keys in the metasploit > SSH example on unaffected systems? This concern is unwarranted. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
how to add an extension to a X509 certificate ?
Hello everyone,
I would like to add an extension to a X509v3 certificate.
I wrote :
void Addmyextension(X509* cert, int nid, char* value, bool crit)
{
X509_EXTENSION* ex = X509_EXTENSION_new();
ex->object = OBJ_nid2obj(nid);
crit? ex->critical = 0xff : ex->critical = -1; // Question 1
ASN1_STRING_set(ex->value, value, strlen(value)); // Question 2
X509_add_ext( cert, ex, -1);
cout << " A :"<< toHex(ex->value->data) << endl;
}
Question 1 :
Is 0xff and -1 good value for critical state ? I found these one in
x509_v3.c line 240...
Question 2 :
I don't think this line is good.
When i set the same text as i found in other extension, i don't have the
same value in the asn1_string :
STACK_OF (X509_EXTENSION)* sk_ext = cert->cert_info->extensions;
X509_EXTENSION *ex2 =sk_X509_EXTENSION_value(sk_ext, 1);
cout << "B :"data) << endl;
I get :
A :43413A54525545
B :30030101FF
But this value must be the same (value = "CA:TRUE", A is the hexadecimal
code of this char*). So i think my Addmyextension is not good.
I have a get function for convert the stack of extension to a map. I
think i must create a similar function (which use BIO probably) for set
an extension.
map Certificate::getV3ext()
{
map extension;
ASN1_OBJECT *obj;
// bio struct is use to read the X509_EXTENSION in this case (like a
stream in c++)
BIO *bio = BIO_new(BIO_s_mem());
int i, len, n = X509_get_ext_count( _d_cert );
char buffer[BUFFER_SIZE];
X509_EXTENSION *ex;
for (i=0; iobject);// convert it to integer
cout << "type " << type << " " << string(OBJ_nid2ln(type)) << endl;
if (X509_EXTENSION_get_critical(ex))// if critical
text = CRITICAL_TEXTE;//add "critical, " text to
the string
if(!X509V3_EXT_print(bio, ex, 0, 0))// read the text of this
extention
M_ASN1_OCTET_STRING_print(bio,ex->value);
len = BIO_read(bio, buffer, BUFFER_SIZE);// here buffer contain
the text, len the lenght of it.
buffer[len] = '\0';// add the EOT sign
text += buffer;// add the readed text to the string
extension.insert(make_pair(type,text));// put it in the map
}
BIO_free(bio);// clear the bio "stream"
return extension; // retrun the map
}
But i can find how to use BIO feature for add an extension.
Thanks in advance,
pierre delcour
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
OpenSSL 0.9.8h released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8h released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8h of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release. For a complete list of changes, please see http://cvs.openssl.org/getfile/openssl/CHANGES?v=1.1238.2.104 Two moderate severity security flaws have been fixed in OpenSSL 0.9.8h. The OpenSSL security team would like to thank Codenomicon for reporting these issues: OpenSSL Server Name extension crash --- Testing using the Codenomicon TLS test suite discovered a flaw in the handling of server name extension data in OpenSSL 0.9.8f and OpenSSL 0.9.8g. If OpenSSL has been compiled using the non-default TLS server name extensions, a remote attacker could send a carefully crafted packet to a server application using OpenSSL and cause it to crash. (CVE-2008-0891). Please note this issue does not affect any other released versions of OpenSSL, and does not affect versions compiled without TLS server name extensions. OpenSSL Omit Server Key Exchange message crash -- Testing using the Codenomicon TLS test suite discovered a flaw if the 'Server Key exchange message' is omitted from a TLS handshake in OpenSSL 0.9.8f and OpenSSL 0.9.8g. If a client connects to a malicious server with particular cipher suites, the server could cause the client to crash. (CVE-2008-1672). Please note this issue does not affect any other released versions of OpenSSL. Users of OpenSSL 0.9.8f or 0.9.8g should update to the OpenSSL 0.9.8h release which contains patches to correct these issues. We consider OpenSSL 0.9.8h to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8h is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8h.tar.gz Size: 3439981 MD5 checksum: 7d3d41dafc76cf2fcb5559963b5783b3 SHA1 checksum: ced4f2da24a202e01ea22bef30ebc8aee274de86 The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBSD0zDu6tTP1JpWPZAQLsDQP/VSBPNnqGy0i+QW/hsU8n+9A1o6DKZISA ctQRYMbsZg4VyQOvdJg++LXI8VJyXJCzfHwtoYPSGaaOq/H4S8Z7DmK6zHW7cpi0 zSAIPaI3XA5lxzrbhADxpuDVVVUkGJA+dxsUpLV1V+lKbrRfZhzBwXyV8jAqdlsE b2DlMZ8v+lg= =0T9U -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Library used for I/O operation
Hi, I'm trying to test some algorithm with openssl comman line and oprofile. Then, to separate the time used for the real cryptographic operation from the time used for I/O operation, I need to know which library is used to read a file. The library can see are used in the execution of a command are the following libcrypto.so.0.9.8 ld-2.7.so libc-2.7.so openssl libssl.so.0.9.8 libdl-2.7.so libz.so.1.2.3.3 Can anybody tell me which is used for I/O operation on file? Bye Silvia
Wider fallout from Debian issue?
Hi, Regarding the recently reported Debian patch of OpenSSL issue, the affected keys would seem to be well known and with the metasploit site hosting pre-computed keys and a number of scripts around various sites available to take advantage of the specific problem, it would seem like just a matter of time before these keys become the first port of call for a malicious user looking to compromise any arbitrary key (in the hope that it's from an affected system). Should these compromisable keys now be considered in the same light as a password of "password" on otherwise unaffected systems? In other words - if these keys could now form the base of a dictionary (of sorts) for an attack, should we consider also checking generated private keys (by OpenSSL in this instance) much as some systems check for silly passwords? If so: Would the key space be narrowed materially if these keys were removed from the "allowable" private keys in 2048 RSA for example? Could a 128bit MAC of the keys be used (or the like) instead of actually looking up against the full keys? From a runtime perspective, distributing the full pre-computed keys and checking could be prohibitive for some solutions, vs. say a binary tree of 128bit hashes. How significantly would a 128 bit MAC of the key reduce the allowable key space? Is there any intention that OpenSSL do such a "bad key" check (much as the OpenSSL-blacklist for Ubuntu presumably does), or would it be something that users concerned enough would look to do themselves? With all the posts around why the Debian issue may have occurred, I'd hate to be trail blazing... Finally - how real is this concern? What is the probability that say a 2048bit generated key could fall into the 32,767 keys in the metasploit SSH example on unaffected systems? Best Regards, Deane __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Decoding ASN.1 PBE 3-DES
Hi, I'm trying to write a 3-DES decoder in Javascript, but I'm dealing with input generated by other libraries, encoded in ASN.1. I ran openssl on one of the sample inputs, to decode the ASN.1 for me, here's the output: [h-118 test]$ openssl asn1parse -i -inform DER -in dec 0:d=0 hl=2 l=inf cons: SEQUENCE 2:d=1 hl=2 l= 9 prim: OBJECT:pkcs7-encryptedData 13:d=1 hl=2 l=inf cons: cont [ 0 ] 15:d=2 hl=2 l=inf cons: SEQUENCE 17:d=3 hl=2 l= 1 prim:INTEGER :00 20:d=3 hl=2 l=inf cons:SEQUENCE 22:d=4 hl=2 l= 9 prim: OBJECT:pkcs7-data 33:d=4 hl=2 l= 35 cons: SEQUENCE 35:d=5 hl=2 l= 10 prim: OBJECT:pbeWithSHA1And3- KeyTripleDES-CBC 47:d=5 hl=2 l= 21 cons: SEQUENCE 49:d=6 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]: 41547850E21772D405568A3360142909 67:d=6 hl=2 l= 1 prim: INTEGER :01 70:d=4 hl=2 l=inf cons: cont [ 0 ] 72:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]: 65271944D9552B0D52A817FCE68DB23A 90:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]: 35BA7C869EFD6D6E 100:d=5 hl=2 l= 0 prim: EOC 102:d=4 hl=2 l= 0 prim: EOC 104:d=3 hl=2 l= 0 prim:EOC 106:d=2 hl=2 l= 0 prim: EOC 108:d=1 hl=2 l= 0 prim: EOC Now, the 3-DES algorithm which I implemented (pretty standard), expects a 16 byte key, an 8 byte initialization vector and the encrypted string itself. How do I find out which of the ASN.1 fields correspond to the IV and data? How can I generate a 24 bit key from the salt (some ASN.1 field I can't figure out which) and passphrase? Also, can I use openssl to decode the input file? If yes, looking at the openssl code might help me figure things out. Thanks in advance! -- Anant P.S. I'm not on the list, so I would appreciate it if you could Cc me on any replies. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
