From noloader at gmail.com  Mon Jun  1 00:46:05 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 31 May 2015 20:46:05 -0400
Subject: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent
 retry for Public Key parse after Traditional/Subject Public Key Info parse
 fails
In-Reply-To: <rt-4.0.4-21615-1433089666-1690.3887-6-0@openssl.org>
References: <RT-Ticket-3887@openssl.org>
 <CAH8yC8nvVUOL9JsHy_X7U8zHSmAhHBpkEh_jFrp6Hgzw5T4Kdg@mail.gmail.com>
 <rt-4.0.4-21615-1433089666-1690.3887-6-0@openssl.org>
Message-ID: <CAH8yC8kNFQiadguDbrHMWG1nH69MOnV8KbEX7u=_7NzcwN9b5g@mail.gmail.com>

On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT <rt at openssl.org> wrote:
> Nice idea, I'm however thinking that much of the trying different formats could
> be moved to load_key / load_pubkey, all that would be needed is a keyformat
> denoting "try anything". -1, perhaps?
>

I like the idea, and I was entertaining it. The goal here ways to
improve rsautl, so I deferred.

There are some potential issues with moving the logic into load_key
and load_pubkey. The first issue is the change in behavior utility
wide. That is, it will affect most (all?) utilities. I think its a
good idea, but others may not.

The second issue (related to the first), is the rsa utility has tried
to address these issue already. So there's a few other
switches/options for the rsa utility. For example, RSAPublicKey_in and
RSAPublicKey_out. This may or may not be an issue.

The third issue (related to the first), is that other similar
functions, like load_certificate, may not get the change. This may or
may not matter, and may or may not be an issue.

The fourth issue is the cracker. Effectively, apps{c|h} only
recognizes PEM, PEMRSA, ASN1, and ASN1RSA (see str2fmt, which appears
to be removed in 1.1.0). So OpenSSL would need a way to identify other
encodings, types and algorithms. For example, a PEM encoded DSA
SubjectPublicKeyInfo or PrivateKeyInfo (traditional key) versus a
ANS.1/DER encoded DSA public key or private key.

**********

I think there's little difference between load_key and load_pubkey.
Fold them together, and call the function that remains load_key and
return the EVP_PKEY.

load_key should take a encoding hint (PEM vs ASN.1, etc), a key type
hint (SPKI/Traditional versus Key-Only, etc), a key pair hint (public
versus private), and a key algorithm hint (RSA, DSA, etc).

I would envision it to be similar to:

    int encoding_hint = -1, key_type_hint = -1, key_pair_hint = -1,
key_alg_hint = -1;
    key_hints(?, &encoding_hint, &key_type_hint, &key_pair_hint, &key_alg_hint);

That's going to lead to an ugly message cracker, but I don't know how
to avoid it.

**********

There is a key_file_format function in apps.c, but its not really
useful. I think this is the keystone to making things work here. It
should peek at the key, and return the tuple {key encoding, key type,
key pair, key algorithm} hints. Its similar to str2fmt, but it works
directly with the key specified by the user rather than command line
arguments.

One of the things I give the user credit for is that they know the
key-file they want to use. They may not know the encoding, format or
type - but they know the filename. So something to peek into the file
and then make intelligent decisions would probably be very helpful to
the user.

I understand key_file_format won't work with stdin. So maybe the
course of action is to peek from a BIO. If its a file BIO, then
everything just works. If its from stdin, then wrap it in a memory bio
so everything works as expected.

**********

Jeff

From rt at openssl.org  Mon Jun  1 00:46:48 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Mon, 1 Jun 2015 02:46:48 +0200
Subject: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent
	retry for Public Key parse after Traditional/Subject Public
	Key Info parse fails
In-Reply-To: <CAH8yC8kNFQiadguDbrHMWG1nH69MOnV8KbEX7u=_7NzcwN9b5g@mail.gmail.com>
References: <RT-Ticket-3887@openssl.org>
 <CAH8yC8nvVUOL9JsHy_X7U8zHSmAhHBpkEh_jFrp6Hgzw5T4Kdg@mail.gmail.com>
 <rt-4.0.4-21615-1433089666-1690.3887-6-0@openssl.org>
 <CAH8yC8kNFQiadguDbrHMWG1nH69MOnV8KbEX7u=_7NzcwN9b5g@mail.gmail.com>
Message-ID: <rt-4.0.4-24922-1433119607-1803.3887-6-0@openssl.org>

On Sun, May 31, 2015 at 12:27 PM, Richard Levitte via RT <rt at openssl.org> wrote:
> Nice idea, I'm however thinking that much of the trying different formats could
> be moved to load_key / load_pubkey, all that would be needed is a keyformat
> denoting "try anything". -1, perhaps?
>

I like the idea, and I was entertaining it. The goal here ways to
improve rsautl, so I deferred.

There are some potential issues with moving the logic into load_key
and load_pubkey. The first issue is the change in behavior utility
wide. That is, it will affect most (all?) utilities. I think its a
good idea, but others may not.

The second issue (related to the first), is the rsa utility has tried
to address these issue already. So there's a few other
switches/options for the rsa utility. For example, RSAPublicKey_in and
RSAPublicKey_out. This may or may not be an issue.

The third issue (related to the first), is that other similar
functions, like load_certificate, may not get the change. This may or
may not matter, and may or may not be an issue.

The fourth issue is the cracker. Effectively, apps{c|h} only
recognizes PEM, PEMRSA, ASN1, and ASN1RSA (see str2fmt, which appears
to be removed in 1.1.0). So OpenSSL would need a way to identify other
encodings, types and algorithms. For example, a PEM encoded DSA
SubjectPublicKeyInfo or PrivateKeyInfo (traditional key) versus a
ANS.1/DER encoded DSA public key or private key.

**********

I think there's little difference between load_key and load_pubkey.
Fold them together, and call the function that remains load_key and
return the EVP_PKEY.

load_key should take a encoding hint (PEM vs ASN.1, etc), a key type
hint (SPKI/Traditional versus Key-Only, etc), a key pair hint (public
versus private), and a key algorithm hint (RSA, DSA, etc).

I would envision it to be similar to:

    int encoding_hint = -1, key_type_hint = -1, key_pair_hint = -1,
key_alg_hint = -1;
    key_hints(?, &encoding_hint, &key_type_hint, &key_pair_hint, &key_alg_hint);

That's going to lead to an ugly message cracker, but I don't know how
to avoid it.

**********

There is a key_file_format function in apps.c, but its not really
useful. I think this is the keystone to making things work here. It
should peek at the key, and return the tuple {key encoding, key type,
key pair, key algorithm} hints. Its similar to str2fmt, but it works
directly with the key specified by the user rather than command line
arguments.

One of the things I give the user credit for is that they know the
key-file they want to use. They may not know the encoding, format or
type - but they know the filename. So something to peek into the file
and then make intelligent decisions would probably be very helpful to
the user.

I understand key_file_format won't work with stdin. So maybe the
course of action is to peek from a BIO. If its a file BIO, then
everything just works. If its from stdin, then wrap it in a memory bio
so everything works as expected.

**********

Jeff



From rt at openssl.org  Mon Jun  1 03:07:08 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Mon, 1 Jun 2015 05:07:08 +0200
Subject: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent
	retry for Public Key parse after Traditional/Subject Public
	Key Info parse fails
In-Reply-To: <CAH8yC8kEXE5U_FfV6VcW=RVHko60TJ9QQ4injfuybXw0CC6anA@mail.gmail.com>
References: <RT-Ticket-3887@openssl.org>
 <CAH8yC8nvVUOL9JsHy_X7U8zHSmAhHBpkEh_jFrp6Hgzw5T4Kdg@mail.gmail.com>
 <CAH8yC8kEXE5U_FfV6VcW=RVHko60TJ9QQ4injfuybXw0CC6anA@mail.gmail.com>
Message-ID: <rt-4.0.4-25913-1433128028-1699.3887-6-0@openssl.org>

I submitted this earlier, but I forgot to tweak the docs. The docs
were missing the -keyform option, and they needed the behavior change
documented.

I also fixed a typo in the patch. The following was missing an 'else if':

    if(keyformat == FORMAT_PEM) {
        next_format = FORMAT_PEMRSA;
    } else if(keyformat == FORMAT_ASN1) {
        next_format = FORMAT_ASN1RSA;
    } else {
        next_format = -1;
    }

Attached is the updated patch.

If the patch is rejected, you might consider taking the documentation
updates (sans the behavioral changes).

On Sat, May 30, 2015 at 6:17 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> apps.c has a couple of parsing routines called load_pubkey and
> load_key. rsautl uses those routines.
>
> However, there's no option in rsautil to use anything other than a
> ASN.1/DER or PEM encoded traditional key (or subject public key info).
> The code paths are present, we just can't seem to get to them.
>
> ...

-------------- next part --------------
diff --git a/apps/apps.c b/apps/apps.c
index 60f71c3..f80767a 100644
--- a/apps/apps.c
+++ b/apps/apps.c
@@ -763,7 +763,7 @@ X509_CRL *load_crl(const char *infile, int format)
 }
 
 EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
-                   const char *pass, ENGINE *e, const char *key_descrip)
+                   const char *pass, ENGINE *e, const char *key_descrip, int last_try)
 {
     BIO *key = NULL;
     EVP_PKEY *pkey = NULL;
@@ -773,7 +773,7 @@ EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
     cb_data.prompt_info = file;
 
     if (file == NULL && (!maybe_stdin || format == FORMAT_ENGINE)) {
-        BIO_printf(bio_err, "no keyfile specified\n");
+        if(last_try) { BIO_printf(bio_err, "no keyfile specified\n"); }
         goto end;
     }
 #ifndef OPENSSL_NO_ENGINE
@@ -827,7 +827,7 @@ EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
     }
  end:
     BIO_free(key);
-    if (pkey == NULL) {
+    if (pkey == NULL && last_try) {
         BIO_printf(bio_err, "unable to load %s\n", key_descrip);
         ERR_print_errors(bio_err);
     }
@@ -842,7 +842,7 @@ static const char *key_file_format(int format)
 }
 
 EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
-                      const char *pass, ENGINE *e, const char *key_descrip)
+                      const char *pass, ENGINE *e, const char *key_descrip, int last_try)
 {
     BIO *key = NULL;
     EVP_PKEY *pkey = NULL;
@@ -852,7 +852,7 @@ EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
     cb_data.prompt_info = file;
 
     if (file == NULL && (!maybe_stdin || format == FORMAT_ENGINE)) {
-        BIO_printf(bio_err, "no keyfile specified\n");
+        if(last_try) { BIO_printf(bio_err, "no keyfile specified\n"); }
         goto end;
     }
 #ifndef OPENSSL_NO_ENGINE
@@ -914,8 +914,9 @@ EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
 #endif
  end:
     BIO_free(key);
-    if (pkey == NULL)
+    if (pkey == NULL && last_try) {
         BIO_printf(bio_err, "unable to load %s\n", key_descrip);
+    }
     return (pkey);
 }
 
diff --git a/apps/apps.h b/apps/apps.h
index a8652a1..0cd563a 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -427,9 +427,9 @@ X509 *load_cert(const char *file, int format,
 X509_CRL *load_crl(const char *infile, int format);
 int load_cert_crl_http(const char *url, X509 **pcert, X509_CRL **pcrl);
 EVP_PKEY *load_key(const char *file, int format, int maybe_stdin,
-                   const char *pass, ENGINE *e, const char *key_descrip);
+                   const char *pass, ENGINE *e, const char *key_descrip, int last_try);
 EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin,
-                      const char *pass, ENGINE *e, const char *key_descrip);
+                      const char *pass, ENGINE *e, const char *key_descrip, int last_try);
 STACK_OF(X509) *load_certs(const char *file, int format,
                            const char *pass, ENGINE *e,
                            const char *cert_descrip);
diff --git a/apps/ca.c b/apps/ca.c
index 4dc9176..8c03efd 100644
--- a/apps/ca.c
+++ b/apps/ca.c
@@ -587,7 +587,7 @@ end_of_options:
             goto end;
         }
     }
-    pkey = load_key(keyfile, keyformat, 0, key, e, "CA private key");
+    pkey = load_key(keyfile, keyformat, 0, key, e, "CA private key", 1 /*last_try*/);
     if (key)
         OPENSSL_cleanse(key, strlen(key));
     if (pkey == NULL) {
diff --git a/apps/cms.c b/apps/cms.c
index 7ccca5b..5966873 100644
--- a/apps/cms.c
+++ b/apps/cms.c
@@ -762,7 +762,7 @@ int cms_main(int argc, char **argv)
         keyfile = NULL;
 
     if (keyfile) {
-        key = load_key(keyfile, keyform, 0, passin, e, "signing key file");
+        key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/);
         if (!key)
             goto end;
     }
@@ -966,7 +966,7 @@ int cms_main(int argc, char **argv)
                                e, "signer certificate");
             if (!signer)
                 goto end;
-            key = load_key(keyfile, keyform, 0, passin, e, "signing key file");
+            key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/);
             if (!key)
                 goto end;
             for (kparam = key_first; kparam; kparam = kparam->next) {
diff --git a/apps/crl.c b/apps/crl.c
index 17391e2..cc82ac2 100644
--- a/apps/crl.c
+++ b/apps/crl.c
@@ -266,7 +266,7 @@ int crl_main(int argc, char **argv)
         newcrl = load_crl(crldiff, informat);
         if (!newcrl)
             goto end;
-        pkey = load_key(keyfile, keyformat, 0, NULL, NULL, "CRL signing key");
+        pkey = load_key(keyfile, keyformat, 0, NULL, NULL, "CRL signing key", 1 /*last_try*/);
         if (!pkey) {
             X509_CRL_free(newcrl);
             goto end;
diff --git a/apps/dgst.c b/apps/dgst.c
index 308555c..03f0f3f 100644
--- a/apps/dgst.c
+++ b/apps/dgst.c
@@ -286,9 +286,9 @@ int dgst_main(int argc, char **argv)
 
     if (keyfile) {
         if (want_pub)
-            sigkey = load_pubkey(keyfile, keyform, 0, NULL, e, "key file");
+            sigkey = load_pubkey(keyfile, keyform, 0, NULL, e, "key file", 1 /*last_try*/);
         else
-            sigkey = load_key(keyfile, keyform, 0, passin, e, "key file");
+            sigkey = load_key(keyfile, keyform, 0, passin, e, "key file", 1 /*last_try*/);
         if (!sigkey) {
             /*
              * load_[pub]key() has already printed an appropriate message
diff --git a/apps/dsa.c b/apps/dsa.c
index f02f293..34d8e0b 100644
--- a/apps/dsa.c
+++ b/apps/dsa.c
@@ -204,9 +204,9 @@ int dsa_main(int argc, char **argv)
         EVP_PKEY *pkey;
 
         if (pubin)
-            pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key");
+            pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key", 1 /*last_try*/);
         else
-            pkey = load_key(infile, informat, 1, passin, e, "Private Key");
+            pkey = load_key(infile, informat, 1, passin, e, "Private Key", 1 /*last_try*/);
 
         if (pkey) {
             dsa = EVP_PKEY_get1_DSA(pkey);
diff --git a/apps/ocsp.c b/apps/ocsp.c
index 4c3aa39..944b14c 100644
--- a/apps/ocsp.c
+++ b/apps/ocsp.c
@@ -528,7 +528,7 @@ int ocsp_main(int argc, char **argv)
                 goto end;
         }
         rkey = load_key(rkeyfile, FORMAT_PEM, 0, NULL, NULL,
-                        "responder private key");
+                        "responder private key", 1 /*last_try*/);
         if (!rkey)
             goto end;
     }
@@ -573,7 +573,7 @@ int ocsp_main(int argc, char **argv)
                 goto end;
         }
         key = load_key(keyfile, FORMAT_PEM, 0, NULL, NULL,
-                       "signer private key");
+                       "signer private key", 1 /*last_try*/);
         if (!key)
             goto end;
 
diff --git a/apps/pkcs12.c b/apps/pkcs12.c
index 82131e8..b603794 100644
--- a/apps/pkcs12.c
+++ b/apps/pkcs12.c
@@ -386,7 +386,7 @@ int pkcs12_main(int argc, char **argv)
 
         if (!(options & NOKEYS)) {
             key = load_key(keyname ? keyname : infile,
-                           FORMAT_PEM, 1, passin, e, "private key");
+                           FORMAT_PEM, 1, passin, e, "private key", 1 /*last_try*/);
             if (!key)
                 goto export_end;
         }
diff --git a/apps/pkcs8.c b/apps/pkcs8.c
index f8a340e..ddc2062 100644
--- a/apps/pkcs8.c
+++ b/apps/pkcs8.c
@@ -236,7 +236,7 @@ int pkcs8_main(int argc, char **argv)
     if (out == NULL)
         goto end;
     if (topk8) {
-        pkey = load_key(infile, informat, 1, passin, e, "key");
+        pkey = load_key(infile, informat, 1, passin, e, "key", 1 /*last_try*/);
         if (!pkey)
             goto end;
         if ((p8inf = EVP_PKEY2PKCS8_broken(pkey, p8_broken)) == NULL) {
diff --git a/apps/pkey.c b/apps/pkey.c
index 875087f..cde83ec 100644
--- a/apps/pkey.c
+++ b/apps/pkey.c
@@ -173,9 +173,9 @@ int pkey_main(int argc, char **argv)
         goto end;
 
     if (pubin)
-        pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key");
+        pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key", 1 /*last_try*/);
     else
-        pkey = load_key(infile, informat, 1, passin, e, "key");
+        pkey = load_key(infile, informat, 1, passin, e, "key", 1 /*last_try*/);
     if (!pkey)
         goto end;
 
diff --git a/apps/pkeyutl.c b/apps/pkeyutl.c
index 4c267c1..d6c7e19 100644
--- a/apps/pkeyutl.c
+++ b/apps/pkeyutl.c
@@ -352,11 +352,11 @@ static EVP_PKEY_CTX *init_ctx(int *pkeysize,
     }
     switch (key_type) {
     case KEY_PRIVKEY:
-        pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key");
+        pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key", 1 /*last_try*/);
         break;
 
     case KEY_PUBKEY:
-        pkey = load_pubkey(keyfile, keyform, 0, NULL, e, "Public Key");
+        pkey = load_pubkey(keyfile, keyform, 0, NULL, e, "Public Key", 1 /*last_try*/);
         break;
 
     case KEY_CERT:
@@ -427,7 +427,7 @@ static int setup_peer(EVP_PKEY_CTX *ctx, int peerform, const char *file)
         return 0;
     }
 
-    peer = load_pubkey(file, peerform, 0, NULL, NULL, "Peer Key");
+    peer = load_pubkey(file, peerform, 0, NULL, NULL, "Peer Key", 1 /*last_try*/);
 
     if (!peer) {
         BIO_printf(bio_err, "Error reading peer key %s\n", file);
diff --git a/apps/req.c b/apps/req.c
index 3bae59e..dd3c629 100644
--- a/apps/req.c
+++ b/apps/req.c
@@ -481,7 +481,7 @@ int req_main(int argc, char **argv)
     }
 
     if (keyfile != NULL) {
-        pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key");
+        pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key", 1 /*last_try*/);
         if (!pkey) {
             /* load_key() has already printed an appropriate message */
             goto end;
diff --git a/apps/rsa.c b/apps/rsa.c
index 87cb702..dae59f2 100644
--- a/apps/rsa.c
+++ b/apps/rsa.c
@@ -275,9 +275,9 @@ int rsa_main(int argc, char **argv)
             } else
                 tmpformat = informat;
 
-            pkey = load_pubkey(infile, tmpformat, 1, passin, e, "Public Key");
+            pkey = load_pubkey(infile, tmpformat, 1, passin, e, "Public Key", 1 /*last_try*/);
         } else
-            pkey = load_key(infile, informat, 1, passin, e, "Private Key");
+            pkey = load_key(infile, informat, 1, passin, e, "Private Key", 1 /*last_try*/);
 
         if (pkey != NULL)
             rsa = EVP_PKEY_get1_RSA(pkey);
diff --git a/apps/rsautl.c b/apps/rsautl.c
index 8ba838b..4d029be 100644
--- a/apps/rsautl.c
+++ b/apps/rsautl.c
@@ -120,7 +120,7 @@ int rsautl_main(int argc, char **argv)
     char *passinarg = NULL, *passin = NULL, *prog;
     char rsa_mode = RSA_VERIFY, key_type = KEY_PRIVKEY;
     unsigned char *rsa_in = NULL, *rsa_out = NULL, pad = RSA_PKCS1_PADDING;
-    int rsa_inlen, keyformat = FORMAT_PEM, keysize, ret = 1;
+    int rsa_inlen, keyformat = FORMAT_PEM, next_format, keysize, ret = 1;
     int rsa_outlen = 0, hexdump = 0, asn1parse = 0, need_priv = 0, rev = 0;
     OPTION_CHOICE o;
 
@@ -217,16 +217,30 @@ int rsautl_main(int argc, char **argv)
     if (!app_load_modules(NULL))
         goto end;
 
-/* FIXME: seed PRNG only if needed */
+    /* FIXME: seed PRNG only if needed */
     app_RAND_load_file(NULL, 0);
+    
+    /* rsautl does not offer a way to specify just a public key. It requires a */
+    /*   subjectPublicKeyInfo, and there's no argument or option to switch to  */
+    /*   the a non-traditional key in either ASN.1/DER or PEM format. This     */
+    /*   attempts to make an intelligent retry.                                */
+    if(keyformat == FORMAT_PEM) {
+        next_format = FORMAT_PEMRSA;
+    } else if(keyformat == FORMAT_ASN1) {
+        next_format = FORMAT_ASN1RSA;
+    } else {
+        next_format = -1;
+    }
 
     switch (key_type) {
     case KEY_PRIVKEY:
-        pkey = load_key(keyfile, keyformat, 0, passin, e, "Private Key");
+        pkey = load_key(keyfile, keyformat, 0, passin, e, "Private Key", 0 /*last_try*/);
+        if(!pkey && next_format != -1) { pkey = load_key(keyfile, next_format, 0, passin, e, "Private Key", 1 /*last_try*/); }
         break;
 
     case KEY_PUBKEY:
-        pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public Key");
+        pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public Key", 0 /*last_try*/);
+        if(!pkey && next_format != -1) { pkey = load_pubkey(keyfile, next_format, 0, NULL, e, "Public Key", 1 /*last_try*/); }
         break;
 
     case KEY_CERT:
diff --git a/apps/s_cb.c b/apps/s_cb.c
index 35366c5..10e6c0a 100644
--- a/apps/s_cb.c
+++ b/apps/s_cb.c
@@ -1050,10 +1050,10 @@ int load_excert(SSL_EXCERT **pexc)
             return 0;
         if (exc->keyfile) {
             exc->key = load_key(exc->keyfile, exc->keyform,
-                                0, NULL, NULL, "Server Key");
+                                0, NULL, NULL, "Server Key", 1 /*last_try*/);
         } else {
             exc->key = load_key(exc->certfile, exc->certform,
-                                0, NULL, NULL, "Server Key");
+                                0, NULL, NULL, "Server Key", 1 /*last_try*/);
         }
         if (!exc->key)
             return 0;
diff --git a/apps/s_client.c b/apps/s_client.c
index 009e5fe..85a9e39 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1112,7 +1112,7 @@ int s_client_main(int argc, char **argv)
 
     if (key_file) {
         key = load_key(key_file, key_format, 0, pass, e,
-                       "client certificate private key file");
+                       "client certificate private key file", 1 /*last_try*/);
         if (key == NULL) {
             ERR_print_errors(bio_err);
             goto end;
diff --git a/apps/s_server.c b/apps/s_server.c
index 189019d..3469add 100644
--- a/apps/s_server.c
+++ b/apps/s_server.c
@@ -1452,7 +1452,7 @@ int s_server_main(int argc, char *argv[])
 
     if (nocert == 0) {
         s_key = load_key(s_key_file, s_key_format, 0, pass, e,
-                         "server certificate private key file");
+                         "server certificate private key file", 1 /*last_try*/);
         if (!s_key) {
             ERR_print_errors(bio_err);
             goto end;
@@ -1474,7 +1474,7 @@ int s_server_main(int argc, char *argv[])
 
         if (tlsextcbp.servername) {
             s_key2 = load_key(s_key_file2, s_key_format, 0, pass, e,
-                              "second server certificate private key file");
+                              "second server certificate private key file", 1 /*last_try*/);
             if (!s_key2) {
                 ERR_print_errors(bio_err);
                 goto end;
@@ -1532,7 +1532,7 @@ int s_server_main(int argc, char *argv[])
             s_dkey_file = s_dcert_file;
 
         s_dkey = load_key(s_dkey_file, s_dkey_format,
-                          0, dpass, e, "second certificate private key file");
+                          0, dpass, e, "second certificate private key file", 1 /*last_try*/);
         if (!s_dkey) {
             ERR_print_errors(bio_err);
             goto end;
diff --git a/apps/smime.c b/apps/smime.c
index 45898de..f74105f 100644
--- a/apps/smime.c
+++ b/apps/smime.c
@@ -491,7 +491,7 @@ int smime_main(int argc, char **argv)
         keyfile = NULL;
 
     if (keyfile) {
-        key = load_key(keyfile, keyform, 0, passin, e, "signing key file");
+        key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/);
         if (!key)
             goto end;
     }
@@ -574,7 +574,7 @@ int smime_main(int argc, char **argv)
                                e, "signer certificate");
             if (!signer)
                 goto end;
-            key = load_key(keyfile, keyform, 0, passin, e, "signing key file");
+            key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/);
             if (!key)
                 goto end;
             if (!PKCS7_sign_add_signer(p7, signer, key, sign_md, flags))
diff --git a/apps/spkac.c b/apps/spkac.c
index d41331c..72f8b3a 100644
--- a/apps/spkac.c
+++ b/apps/spkac.c
@@ -163,7 +163,7 @@ int spkac_main(int argc, char **argv)
 
     if (keyfile) {
         pkey = load_key(strcmp(keyfile, "-") ? keyfile : NULL,
-                        FORMAT_PEM, 1, passin, e, "private key");
+                        FORMAT_PEM, 1, passin, e, "private key", 1 /*last_try*/);
         if (!pkey) {
             goto end;
         }
diff --git a/apps/x509.c b/apps/x509.c
index 77a2a6b..0c7a810 100644
--- a/apps/x509.c
+++ b/apps/x509.c
@@ -510,7 +510,7 @@ int x509_main(int argc, char **argv)
     }
 
     if (fkeyfile) {
-        fkey = load_pubkey(fkeyfile, keyformat, 0, NULL, e, "Forced key");
+        fkey = load_pubkey(fkeyfile, keyformat, 0, NULL, e, "Forced key", 1 /*last_try*/);
         if (fkey == NULL)
             goto end;
     }
@@ -823,7 +823,7 @@ int x509_main(int argc, char **argv)
                 BIO_printf(bio_err, "Getting Private key\n");
                 if (Upkey == NULL) {
                     Upkey = load_key(keyfile, keyformat, 0,
-                                     passin, e, "Private key");
+                                     passin, e, "Private key", 1 /*last_try*/);
                     if (Upkey == NULL)
                         goto end;
                 }
@@ -835,7 +835,7 @@ int x509_main(int argc, char **argv)
                 BIO_printf(bio_err, "Getting CA Private Key\n");
                 if (CAkeyfile != NULL) {
                     CApkey = load_key(CAkeyfile, CAkeyformat,
-                                      0, passin, e, "CA Private Key");
+                                      0, passin, e, "CA Private Key", 1 /*last_try*/);
                     if (CApkey == NULL)
                         goto end;
                 }
@@ -855,7 +855,7 @@ int x509_main(int argc, char **argv)
                     goto end;
                 } else {
                     pk = load_key(keyfile, keyformat, 0,
-                                  passin, e, "request key");
+                                  passin, e, "request key", 1 /*last_try*/);
                     if (pk == NULL)
                         goto end;
                 }
diff --git a/doc/apps/rsautl.pod b/doc/apps/rsautl.pod
index 1a498c2..5699af5 100644
--- a/doc/apps/rsautl.pod
+++ b/doc/apps/rsautl.pod
@@ -10,6 +10,7 @@ B<openssl> B<rsautl>
 [B<-in file>]
 [B<-out file>]
 [B<-inkey file>]
+[B<-keyform format>]
 [B<-pubin>]
 [B<-certin>]
 [B<-sign>]
@@ -33,17 +34,21 @@ data using the RSA algorithm.
 
 =item B<-in filename>
 
-This specifies the input filename to read data from or standard input
+the input filename to read data from or standard input
 if this option is not specified.
 
 =item B<-out filename>
 
-specifies the output filename to write to or standard output by
+the output filename to write to or standard output by
 default.
 
 =item B<-inkey file>
 
-the input key file, by default it should be an RSA private key.
+input key file, and by default it should be a RSA private key. The key can be in any supported format, including PEM and DER (ASN.1). The key should be in traditional format.
+
+=item B<-keyform format>
+
+the format of the key files, by default PEM.
 
 =item B<-pubin>
 
@@ -55,12 +60,13 @@ the input is a certificate containing an RSA public key.
 
 =item B<-sign>
 
-sign the input data and output the signed result. This requires
-and RSA private key.
+sign the input data and output the signed result. This operation requires
+a RSA private key.
 
 =item B<-verify>
 
-verify the input data and output the recovered data.
+verify the input data and output the recovered data. This operation can
+use either a RSA public key or private key.
 
 =item B<-encrypt>
 
@@ -93,6 +99,14 @@ B<-verify> option.
 B<rsautl> because it uses the RSA algorithm directly can only be
 used to sign or verify small pieces of data.
 
+Prior to OpenSSL 1.0.2c, the keys had to be in traditional format
+in a supported encoding, like PEM or DER. OpenSSL 1.0.2c added an
+intelligent fallback so that both traditional and non-traditional
+format can be utilized without command line arguments (the command
+line options were never present). Traditional format means
+subjectPublicKeyInfo with an algorithm OID and public key; while
+non-traditional means just a public key.
+
 =head1 EXAMPLES
 
 Sign some data using a private key:

From erwann.abalea at opentrust.com  Mon Jun  1 08:15:50 2015
From: erwann.abalea at opentrust.com (Erwann Abalea)
Date: Mon, 1 Jun 2015 10:15:50 +0200
Subject: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails
	for 3-level cert chain when using X509v3 Authority Key Identifier
In-Reply-To: <rt-4.0.4-5720-1432972122-1127.3886-21-0@openssl.org>
References: <RT-Ticket-3886@openssl.org>
 <CAA-U2SgHMV4Zo_vX5ax+uTBSoSePrnTmywDURS5gfYrqFxbwuQ@mail.gmail.com>
 <rt-4.0.4-5720-1432972122-1127.3886-21-0@openssl.org>
Message-ID: <9B9ECBE7-588D-4155-806D-BB1DA1E92F01@opentrust.com>

Bonjour,

> Le 30 mai 2015 ? 09:48, John Lofgren via RT <rt at openssl.org> a ?crit :
> 
> I believe I have pinpointed a typo-error that may be the cause of one or
> two other outstanding bugs related to certificate chain validation. This
> bug only occurs in a chain of certs at least 3 deep when the certs use
> the X509v3 Authority Key Identifier extension.
> 
> I am attaching a chain of 3 certs that verifies using the Windows
> Certificate Manager, but fails to verify in versions 1.0.1, 1.0.1c and
> 1.0.1m.
> 
> Example failure command:
> openssl verify -CAfile openssl-verify-chain-bug-CA.crt -untrusted
> openssl-verify-chain-bug-IM-CA.crt openssl-verify-chain-bug-CS.crt

This chain is malformed.
In -bug-CS.crt certificate, the AKI.issuername should be "C=US, O=OpenSSL, CN=openssl verify chain bug Root CA ? instead of ? C=US, O=OpenSSL, CN=openssl verify chain bug Intermediate CA ?.

Microsoft doesn?t choke on it because this extension is only a helper and MUST NOT be used to (in)validate a certificate chain.

> If have also provided a one line patch to crypto/x509v3/v3_purp.c. I
> believe the error is due to a simple typo. The function X509_check_akid()
> is meant to compare the keyID, serial number, and issuer name between a
> cert and its issuer cert. The keyID and serial number compares are working
> correctly. However, when comparing the issuer name, instead of comparing
> the cert's issuer name to the issuer cert's subject name, it is comparing
> to the issuer cert's *issuer* name.  i.e. instead of comparing to the
> parent name, it is comparing to the grandparent name.

AKI is a helper to identify the issuer certificate. A certificate can uniquely be specified by its issuer name and serial number. Therefore, the AKI MUST contain the issuer?s issuer name and the issuer?s serial number.


From rt at openssl.org  Mon Jun  1 08:32:19 2015
From: rt at openssl.org (Erwann Abalea via RT)
Date: Mon, 1 Jun 2015 10:32:19 +0200
Subject: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails
	for 3-level cert chain when using X509v3 Authority Key Identifier
In-Reply-To: <9B9ECBE7-588D-4155-806D-BB1DA1E92F01@opentrust.com>
References: <RT-Ticket-3886@openssl.org>
 <CAA-U2SgHMV4Zo_vX5ax+uTBSoSePrnTmywDURS5gfYrqFxbwuQ@mail.gmail.com>
 <rt-4.0.4-5720-1432972122-1127.3886-21-0@openssl.org>
 <9B9ECBE7-588D-4155-806D-BB1DA1E92F01@opentrust.com>
Message-ID: <rt-4.0.4-31731-1433147538-211.3886-6-0@openssl.org>

Bonjour,

> Le 30 mai 2015 ? 09:48, John Lofgren via RT <rt at openssl.org> a ?crit :
> 
> I believe I have pinpointed a typo-error that may be the cause of one or
> two other outstanding bugs related to certificate chain validation. This
> bug only occurs in a chain of certs at least 3 deep when the certs use
> the X509v3 Authority Key Identifier extension.
> 
> I am attaching a chain of 3 certs that verifies using the Windows
> Certificate Manager, but fails to verify in versions 1.0.1, 1.0.1c and
> 1.0.1m.
> 
> Example failure command:
> openssl verify -CAfile openssl-verify-chain-bug-CA.crt -untrusted
> openssl-verify-chain-bug-IM-CA.crt openssl-verify-chain-bug-CS.crt

This chain is malformed.
In -bug-CS.crt certificate, the AKI.issuername should be "C=US, O=OpenSSL, CN=openssl verify chain bug Root CA ? instead of ? C=US, O=OpenSSL, CN=openssl verify chain bug Intermediate CA ?.

Microsoft doesn?t choke on it because this extension is only a helper and MUST NOT be used to (in)validate a certificate chain.

> If have also provided a one line patch to crypto/x509v3/v3_purp.c. I
> believe the error is due to a simple typo. The function X509_check_akid()
> is meant to compare the keyID, serial number, and issuer name between a
> cert and its issuer cert. The keyID and serial number compares are working
> correctly. However, when comparing the issuer name, instead of comparing
> the cert's issuer name to the issuer cert's subject name, it is comparing
> to the issuer cert's *issuer* name.  i.e. instead of comparing to the
> parent name, it is comparing to the grandparent name.

AKI is a helper to identify the issuer certificate. A certificate can uniquely be specified by its issuer name and serial number. Therefore, the AKI MUST contain the issuer?s issuer name and the issuer?s serial number.



From KThirumal at inautix.co.in  Mon Jun  1 10:11:57 2015
From: KThirumal at inautix.co.in (Thirumal, Karthikeyan)
Date: Mon, 1 Jun 2015 10:11:57 +0000
Subject: [openssl-dev] F5 termination of TCP connection
Message-ID: <55A0598A7539EC4BAB296D8BBA5AC12288ED6FCC@WTPCPMBMEM07.ams.bnymellon.net>

Dear Team,

We have a client-server (Server is a C++ process) communication which does a TCP communication over a secure layer. The SSL is achieved by OpenSSL library on that process.

Am having some connection problems in the Server side - So inorder to avoid this can I put this SSL under F5 termination - so that all SSL related aspects are done at the F5 load balancer itself and the server is not much loaded.

Has anyone tried this before ? Can someone she some lights on this please ?

Thanks & Regards
________________________
Karthikeyan Thirumal



******************************************************
This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named.  If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email.  If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email.

Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses.  The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission.
******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150601/4acdf509/attachment.html>

From tshort at akamai.com  Mon Jun  1 13:25:12 2015
From: tshort at akamai.com (Short, Todd)
Date: Mon, 1 Jun 2015 13:25:12 +0000
Subject: [openssl-dev] [openssl.org #3882] [BUGFIX]
	lh_SSL_SESSION_delete() not checked
In-Reply-To: <rt-4.0.4-23712-1433105178-1432.3882-6-0@openssl.org>
References: <RT-Ticket-3882@openssl.org>
 <CBD78500-0BB4-4374-8F9D-EBEE1C00C70B@akamai.com>
 <rt-4.0.4-21623-1433090604-286.3882-6-0@openssl.org>
 <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com>
 <rt-4.0.4-23040-1433100244-598.3882-6-0@openssl.org>
 <rt-4.0.4-23557-1433103762-302.3882-6-0@openssl.org>
 <4D06E1D9-072B-4824-8753-D6A1E17D6C84@akamai.com>
 <rt-4.0.4-23549-1433104098-603.3882-6-0@openssl.org>
 <rt-4.0.4-23712-1433105178-1432.3882-6-0@openssl.org>
Message-ID: <37B0EA30-DA8C-49A5-9EA5-547EFA3EBA86@akamai.com>

Depending on how the comparison function was implemented, the insert could still succeed at the point mentioned.

In the case of the patch sent for RT 3883, the original implementation of the comparison function always failed if the client IP address was not set (given that RT 3883 does not require the IP address to be set before adding to the session database, this made sense - a NULL address should never match any other address, even a NULL address). Thus we would end up in a situation where no match was found in the lhash, but still deleting the structure from the list, causing an inconsistency. The compare function was repaired to always match itself, preventing this occurrence.

The patch makes the code in timeout_doall_arg() match the remove_session_lock() function, which does an lh_SESSION_retrieve() followed by lh_SSL_SESSION_delete() and SSL_SESSION_list_remove() if the retrieve() is successful.

Fundamentally, this patch is to keep the SSL_SESSION database in a consistent state, regardless of the behavior of the compare and hash functions. I consider that a ?good? thing.

One could replace most of timeout_doall_arg() with remove_session_lock(lck=0) and have the same effect - but that won?t necessarily work with RT 3883?s patch since it does not set the session_id_length for client-side SSL_SESSIONs.

static void timeout_doall_arg(SSL_SESSION *s, TIMEOUT_PARAM *p)
{
    if ((p->time == 0) || (p->time > (s->time + s->timeout))) { /* timeout */
        /*
         * The reason we don't call SSL_CTX_remove_session() is to save on
         * locking overhead
         */
        (void)remove_session_lock(p->ctx, s, 0);
    }
}

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On May 31, 2015, at 4:46 PM, Salz, Rich via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hmm, but does it? If you look for the comment '/* We *are* in trouble ... */'
in ssl_sess.c, you'll see that there is a similar kind of protection in place
already at the time of insert. So quite frankly and with all respect, I'm not
sure if this particular fix does anything of value any longer.

On Sun May 31 22:28:18 2015, tshort at akamai.com<mailto:tshort at akamai.com> wrote:
We (Akamai) had a bad session compare function at one point; the
compare was fixed, but also added this change to protect the LHASH.

So, yes, this can only really happen if one has a bad comparison
function.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


On May 31, 2015, at 4:22 PM, Richard Levitte via RT <rt at openssl.org<mailto:rt at openssl.org>>
wrote:

I'm not sure how that can happen, as each SSL_SESSION in that lhash
will have
unique content. This is assured by the way lh_insert functions and
by
ssl_session_cmp (which gets called by getrn in lhash.c, via the
function
pointer cf).

So while your suggestion will most probably work as a band aid, I'm
thinking
you've really found a bug in ssl_session_cmp or in the lhash code
itself. Could
you verify?

On Sun May 31 21:24:04 2015, tshort at akamai.com<mailto:tshort at akamai.com> wrote:
No,

The second code sample removes a matching instance, but not
necessarily the same instance. If they are not the same instance,
then
it would need to be re-inserted in and else clause.

This is a fine distinction.

This would leave to having the list and hash not contain the same
contents: Either the number of items is different, or the two sets
of
items are different.

There's a similar example in the code, I believe, but I'd have to
search for it.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


On May 31, 2015, at 12:43 PM, Richard Levitte via RT
<rt at openssl.org<mailto:rt at openssl.org>> wrote:

You solution does the following:

if (lh_SSL_SESSION_retrieve(p->cache, s) == s) {
(void)lh_SSL_SESSION_delete(p->cache, s);
...

Would you agree that the following does the same?

if (lh_SSL_SESSION_delete(p->cache, s) == s) {
...


On Sat May 30 09:48:06 2015, tshort at akamai.com<mailto:tshort at akamai.com> wrote:
Hello OpenSSL Org:

This is a change that Akamai has made to its
implementation of OpenSSL.

Version: master branch
Description:
lh_SSL_SESSION_delete() not checked

Fix an OpenSSL issue where the
return code of lh_SSL_SESSION_delete()
is not checked, causing a
stale reference in the lhash.

Github link:


https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?


--
Richard Levitte
levitte at openssl.org


--
Richard Levitte
levitte at openssl.org




--
Richard Levitte
levitte at openssl.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150601/08e6de20/attachment-0001.html>

From rt at openssl.org  Mon Jun  1 13:36:31 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Mon, 1 Jun 2015 15:36:31 +0200
Subject: [openssl-dev] [openssl.org #3882] [BUGFIX]
	lh_SSL_SESSION_delete() not checked
In-Reply-To: <37B0EA30-DA8C-49A5-9EA5-547EFA3EBA86@akamai.com>
References: <RT-Ticket-3882@openssl.org>
 <CBD78500-0BB4-4374-8F9D-EBEE1C00C70B@akamai.com>
 <rt-4.0.4-21623-1433090604-286.3882-6-0@openssl.org>
 <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com>
 <rt-4.0.4-23040-1433100244-598.3882-6-0@openssl.org>
 <rt-4.0.4-23557-1433103762-302.3882-6-0@openssl.org>
 <4D06E1D9-072B-4824-8753-D6A1E17D6C84@akamai.com>
 <rt-4.0.4-23549-1433104098-603.3882-6-0@openssl.org>
 <rt-4.0.4-23712-1433105178-1432.3882-6-0@openssl.org>
 <37B0EA30-DA8C-49A5-9EA5-547EFA3EBA86@akamai.com>
Message-ID: <rt-4.0.4-21394-1433165790-1407.3882-6-0@openssl.org>

Depending on how the comparison function was implemented, the insert could still succeed at the point mentioned.

In the case of the patch sent for RT 3883, the original implementation of the comparison function always failed if the client IP address was not set (given that RT 3883 does not require the IP address to be set before adding to the session database, this made sense - a NULL address should never match any other address, even a NULL address). Thus we would end up in a situation where no match was found in the lhash, but still deleting the structure from the list, causing an inconsistency. The compare function was repaired to always match itself, preventing this occurrence.

The patch makes the code in timeout_doall_arg() match the remove_session_lock() function, which does an lh_SESSION_retrieve() followed by lh_SSL_SESSION_delete() and SSL_SESSION_list_remove() if the retrieve() is successful.

Fundamentally, this patch is to keep the SSL_SESSION database in a consistent state, regardless of the behavior of the compare and hash functions. I consider that a ?good? thing.

One could replace most of timeout_doall_arg() with remove_session_lock(lck=0) and have the same effect - but that won?t necessarily work with RT 3883?s patch since it does not set the session_id_length for client-side SSL_SESSIONs.

static void timeout_doall_arg(SSL_SESSION *s, TIMEOUT_PARAM *p)
{
    if ((p->time == 0) || (p->time > (s->time + s->timeout))) { /* timeout */
        /*
         * The reason we don't call SSL_CTX_remove_session() is to save on
         * locking overhead
         */
        (void)remove_session_lock(p->ctx, s, 0);
    }
}

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On May 31, 2015, at 4:46 PM, Salz, Rich via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hmm, but does it? If you look for the comment '/* We *are* in trouble ... */'
in ssl_sess.c, you'll see that there is a similar kind of protection in place
already at the time of insert. So quite frankly and with all respect, I'm not
sure if this particular fix does anything of value any longer.

On Sun May 31 22:28:18 2015, tshort at akamai.com<mailto:tshort at akamai.com> wrote:
We (Akamai) had a bad session compare function at one point; the
compare was fixed, but also added this change to protect the LHASH.

So, yes, this can only really happen if one has a bad comparison
function.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


On May 31, 2015, at 4:22 PM, Richard Levitte via RT <rt at openssl.org<mailto:rt at openssl.org>>
wrote:

I'm not sure how that can happen, as each SSL_SESSION in that lhash
will have
unique content. This is assured by the way lh_insert functions and
by
ssl_session_cmp (which gets called by getrn in lhash.c, via the
function
pointer cf).

So while your suggestion will most probably work as a band aid, I'm
thinking
you've really found a bug in ssl_session_cmp or in the lhash code
itself. Could
you verify?

On Sun May 31 21:24:04 2015, tshort at akamai.com<mailto:tshort at akamai.com> wrote:
No,

The second code sample removes a matching instance, but not
necessarily the same instance. If they are not the same instance,
then
it would need to be re-inserted in and else clause.

This is a fine distinction.

This would leave to having the list and hash not contain the same
contents: Either the number of items is different, or the two sets
of
items are different.

There's a similar example in the code, I believe, but I'd have to
search for it.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


On May 31, 2015, at 12:43 PM, Richard Levitte via RT
<rt at openssl.org<mailto:rt at openssl.org>> wrote:

You solution does the following:

if (lh_SSL_SESSION_retrieve(p->cache, s) == s) {
(void)lh_SSL_SESSION_delete(p->cache, s);
...

Would you agree that the following does the same?

if (lh_SSL_SESSION_delete(p->cache, s) == s) {
...


On Sat May 30 09:48:06 2015, tshort at akamai.com<mailto:tshort at akamai.com> wrote:
Hello OpenSSL Org:

This is a change that Akamai has made to its
implementation of OpenSSL.

Version: master branch
Description:
lh_SSL_SESSION_delete() not checked

Fix an OpenSSL issue where the
return code of lh_SSL_SESSION_delete()
is not checked, causing a
stale reference in the lhash.

Github link:


https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?


--
Richard Levitte
levitte at openssl.org


--
Richard Levitte
levitte at openssl.org




--
Richard Levitte
levitte at openssl.org




From rsalz at akamai.com  Mon Jun  1 14:03:09 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 1 Jun 2015 14:03:09 +0000
Subject: [openssl-dev] Do you use EGD or PRNGD?
Message-ID: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>

We are thinking of removing support for EGD (entropy-gathering daemon) in the next release.  None of our supported platforms have needed it for some time.  If this will cause an issue for you, please reply soon.

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150601/00160cb4/attachment.html>

From krzysiek at leeds.pl  Mon Jun  1 11:36:01 2015
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Mon, 01 Jun 2015 13:36:01 +0200
Subject: [openssl-dev] F5 termination of TCP connection
In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC12288ED6FCC@WTPCPMBMEM07.ams.bnymellon.net>
References: <55A0598A7539EC4BAB296D8BBA5AC12288ED6FCC@WTPCPMBMEM07.ams.bnymellon.net>
Message-ID: <8cb4d4d6f2e1d5ab6ac06c2fe0e75b8d@flogreenserver.dyndns.org>

Hi,

Yes, that's exactly what we do in our configuration. We have 24 servers 
with rather high workload. SSL is offloaded on F5 load balancer and 
servers behind load balancers receive decrypted traffic.

I'm not aware of any performance issues. And in fact it's quite good 
idea as server itself doesn't need to know anything about TLS/SSL 
protocol.

--
Kris


On 2015-06-01 12:11, Thirumal, Karthikeyan wrote:
> Dear Team,
> 
> We have a client-server (Server is a C++ process) communication which
> does a TCP communication over a secure layer. The SSL is achieved by
> OpenSSL library on that process.
> 
> Am having some connection problems in the Server side - So inorder to
> avoid this can I put this SSL under F5 termination - so that all SSL
> related aspects are done at the F5 load balancer itself and the server
> is not much loaded.
> 
> Has anyone tried this before ? Can someone she some lights on this
> please ?
> 
> Thanks & Regards
>  ________________________
>  Karthikeyan Thirumal
> 
>  ******************************************************
>  This message and any files or attachments sent with this message
> contain confidential information and is intended only for the
> individual named. If you are not the named addressee, you should not
> disseminate, distribute, copy or use any part of this email. If you
> have received this message in error, please delete it and all copies
> from your system and notify the sender immediately by return Email.
> 
>  Email transmission cannot be guaranteed to be secure or error-free as
> information can be intercepted, corrupted, lost, destroyed, late,
> incomplete or may contain viruses. The sender, therefore, does not
> accept liability for any errors or omissions in the contents of this
> message, which arise as a result of email transmission.
>  ******************************************************
> 
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From rt at openssl.org  Mon Jun  1 14:22:00 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Mon, 1 Jun 2015 16:22:00 +0200
Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add
	IPv4/IPv6:port-based client cache
In-Reply-To: <F818FABD-FA03-4581-9DEC-AFC130763362@akamai.com>
References: <RT-Ticket-3883@openssl.org>
 <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com>
 <rt-4.0.4-5720-1432972092-1373.3883-21-0@openssl.org>
 <20150531060603.GX2342@mournblade.imrryr.org>
 <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.4-19811-1433078843-1044.3883-6-0@openssl.org>
 <F818FABD-FA03-4581-9DEC-AFC130763362@akamai.com>
Message-ID: <rt-4.0.4-31106-1433168518-1655.3883-6-0@openssl.org>

Re: copyrights:

Planning to copy the (109-line) main copyright from another source file and append to it:

/* ====================================================================
 * Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
 * This code was originally developed by Akamai Technologies and
 * and contributed to the OpenSSL project.
 */

Acceptable?
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On May 31, 2015, at 9:27 AM, Salz, Rich via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:


(Documentation is in the source files, not a .pod)

Do you have code to produce usable manpages from the embedded
documentation?  We can't ask users to read the source.

I believe Todd meant for the test program.


   * The copyright notice does not refer to any license that would allow
     inclusion in OpenSSL.

Sigh.  We'll fix that to just submit with the akamai copyright and openssl license.






From rt at openssl.org  Mon Jun  1 15:20:34 2015
From: rt at openssl.org (John Lofgren via RT)
Date: Mon, 1 Jun 2015 17:20:34 +0200
Subject: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails
	for 3-level cert chain when using X509v3 Authority Key Identifier
In-Reply-To: <CAA-U2Sj2W7CLegkvwXJbzw09Cm03hvhBk8b=2vNbE2xwKvhO=Q@mail.gmail.com>
References: <RT-Ticket-3886@openssl.org>
 <CAA-U2SgHMV4Zo_vX5ax+uTBSoSePrnTmywDURS5gfYrqFxbwuQ@mail.gmail.com>
 <rt-4.0.4-5720-1432972122-1127.3886-21-0@openssl.org>
 <9B9ECBE7-588D-4155-806D-BB1DA1E92F01@opentrust.com>
 <rt-4.0.4-31731-1433147538-211.3886-6-0@openssl.org>
 <CAA-U2Sj2W7CLegkvwXJbzw09Cm03hvhBk8b=2vNbE2xwKvhO=Q@mail.gmail.com>
Message-ID: <rt-4.0.4-10747-1433172033-1795.3886-6-0@openssl.org>

Erwann, thank you for the explanation. This makes sense now. I looked at
the spec and now I understand the purpose the AKI.authorityCertIssuer. What
made me misunderstand this in the first place is that 'openssl x509 -text
...' gives no indication that this field is the name of the issuer's
issuer. It only says "DirName":

>>>
            X509v3 Authority Key Identifier:

keyid:21:83:24:4A:59:07:DB:D4:17:2A:29:3C:13:8E:52:B1:EE:09:58:D3
                DirName:/C=US/O=OpenSSL/CN=openssl verify chain bug
Intermediate CA
                serial:DC:71:66:B4:3A:50:5A:BE
<<<

One remaining question. If this extension is "only a helper and MUST NOT be
used to (in)validate a certificate chain" as you say or as the spec says
"non-critical", then why does 'openssl verify' reject this chain?

Thanks,
John

On Mon, Jun 1, 2015 at 3:32 AM, Erwann Abalea via RT <rt at openssl.org> wrote:

> Bonjour,
>
> > Le 30 mai 2015 ? 09:48, John Lofgren via RT <rt at openssl.org> a ?crit :
> >
> > I believe I have pinpointed a typo-error that may be the cause of one or
> > two other outstanding bugs related to certificate chain validation. This
> > bug only occurs in a chain of certs at least 3 deep when the certs use
> > the X509v3 Authority Key Identifier extension.
> >
> > I am attaching a chain of 3 certs that verifies using the Windows
> > Certificate Manager, but fails to verify in versions 1.0.1, 1.0.1c and
> > 1.0.1m.
> >
> > Example failure command:
> > openssl verify -CAfile openssl-verify-chain-bug-CA.crt -untrusted
> > openssl-verify-chain-bug-IM-CA.crt openssl-verify-chain-bug-CS.crt
>
> This chain is malformed.
> In -bug-CS.crt certificate, the AKI.issuername should be "C=US, O=OpenSSL,
> CN=openssl verify chain bug Root CA ? instead of ? C=US, O=OpenSSL,
> CN=openssl verify chain bug Intermediate CA ?.
>
> Microsoft doesn?t choke on it because this extension is only a helper and
> MUST NOT be used to (in)validate a certificate chain.
>
> > If have also provided a one line patch to crypto/x509v3/v3_purp.c. I
> > believe the error is due to a simple typo. The function X509_check_akid()
> > is meant to compare the keyID, serial number, and issuer name between a
> > cert and its issuer cert. The keyID and serial number compares are
> working
> > correctly. However, when comparing the issuer name, instead of comparing
> > the cert's issuer name to the issuer cert's subject name, it is comparing
> > to the issuer cert's *issuer* name.  i.e. instead of comparing to the
> > parent name, it is comparing to the grandparent name.
>
> AKI is a helper to identify the issuer certificate. A certificate can
> uniquely be specified by its issuer name and serial number. Therefore, the
> AKI MUST contain the issuer?s issuer name and the issuer?s serial number.
>
>
>


From dkg at fifthhorseman.net  Mon Jun  1 16:56:11 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 01 Jun 2015 12:56:11 -0400
Subject: [openssl-dev] F5 termination of TCP connection
In-Reply-To: <8cb4d4d6f2e1d5ab6ac06c2fe0e75b8d@flogreenserver.dyndns.org>
References: <55A0598A7539EC4BAB296D8BBA5AC12288ED6FCC@WTPCPMBMEM07.ams.bnymellon.net>
 <8cb4d4d6f2e1d5ab6ac06c2fe0e75b8d@flogreenserver.dyndns.org>
Message-ID: <87siabe5as.fsf@alice.fifthhorseman.net>

On Mon 2015-06-01 07:36:01 -0400, Krzysztof Kwiatkowski wrote:

> Yes, that's exactly what we do in our configuration. We have 24 servers 
> with rather high workload. SSL is offloaded on F5 load balancer and 
> servers behind load balancers receive decrypted traffic.
>
> I'm not aware of any performance issues. And in fact it's quite good 
> idea as server itself doesn't need to know anything about TLS/SSL 
> protocol.

...  And the network connecting the load balancers to the backend
servers is completely physically secured, has no untrusted devices
connected to it anywhere, and all the backend servers completely trust
each other to avoid snooping or interfering with each others' traffic
... right?

When describing deployment configurations, please don't omit the
infrastructure and threat-model requirements for doing this kind of
deployment securely and responsibly.  You might think it goes without
saying, but a couple sentences of reminder don't hurt.

Or, as the powerpoint slide said: "SSL added and removed here ;)" [0]

          --dkg

[0] https://www.agwa.name/blog/post/cloudflare_ssl_added_and_removed_here

From erwann.abalea at opentrust.com  Mon Jun  1 17:12:50 2015
From: erwann.abalea at opentrust.com (Erwann Abalea)
Date: Mon, 1 Jun 2015 19:12:50 +0200
Subject: [openssl-dev] verify fails for 3-level cert chain when using
	X509v3 Authority Key Identifier
In-Reply-To: <rt-4.0.4-10747-1433172033-1795.3886-6-0@openssl.org>
References: <RT-Ticket-3886@openssl.org>
 <CAA-U2SgHMV4Zo_vX5ax+uTBSoSePrnTmywDURS5gfYrqFxbwuQ@mail.gmail.com>
 <rt-4.0.4-5720-1432972122-1127.3886-21-0@openssl.org>
 <9B9ECBE7-588D-4155-806D-BB1DA1E92F01@opentrust.com>
 <rt-4.0.4-31731-1433147538-211.3886-6-0@openssl.org>
 <CAA-U2Sj2W7CLegkvwXJbzw09Cm03hvhBk8b=2vNbE2xwKvhO=Q@mail.gmail.com>
 <rt-4.0.4-10747-1433172033-1795.3886-6-0@openssl.org>
Message-ID: <34904EB8-5056-4E8C-9672-F8686A833CC7@opentrust.com>

Bonsoir John,

> Le 1 juin 2015 ? 17:20, John Lofgren via RT <rt at openssl.org> a ?crit :
> [?]

> One remaining question. If this extension is "only a helper and MUST NOT be
> used to (in)validate a certificate chain" as you say or as the spec says
> "non-critical", then why does 'openssl verify' reject this chain?

That?s an open question. This topic has been raised on IETF PKIX last april.
The normative validation algorithm in section 6 of RFC5280 doesn?t use AKI/SKI.
RFC4158 is about path construction and is also clear on not using AKI/SKI to eliminate a certificate chain.


From rt at openssl.org  Mon Jun  1 17:17:05 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Mon, 1 Jun 2015 19:17:05 +0200
Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add
	IPv4/IPv6:port-based client cache
In-Reply-To: <72B259D9-AA5F-40A2-AC7F-9822D3001526@akamai.com>
References: <RT-Ticket-3883@openssl.org>
 <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com>
 <rt-4.0.4-5720-1432972092-1373.3883-21-0@openssl.org>
 <20150531060603.GX2342@mournblade.imrryr.org>
 <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.4-19811-1433078843-1044.3883-6-0@openssl.org>
 <F818FABD-FA03-4581-9DEC-AFC130763362@akamai.com>
 <rt-4.0.4-31106-1433168518-1655.3883-6-0@openssl.org>
 <72B259D9-AA5F-40A2-AC7F-9822D3001526@akamai.com>
Message-ID: <rt-4.0.4-2487-1433179023-793.3883-6-0@openssl.org>

Note that this (almost) is identical to the Sun Microsystems contribution copyright in s3_both.c, s3_clnt.c s3_lib.c s3_srvr.c, ssl_cert.c ssl_ciph.c, ssl_lib.c and ssl_locl.h?

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On Jun 1, 2015, at 10:22 AM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Re: copyrights:

Planning to copy the (109-line) main copyright from another source file and append to it:

/* ====================================================================
* Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
* This code was originally developed by Akamai Technologies and
* and contributed to the OpenSSL project.
*/

Acceptable?
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com><mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On May 31, 2015, at 9:27 AM, Salz, Rich via RT <rt at openssl.org<mailto:rt at openssl.org><mailto:rt at openssl.org>> wrote:


(Documentation is in the source files, not a .pod)

Do you have code to produce usable manpages from the embedded
documentation?  We can't ask users to read the source.

I believe Todd meant for the test program.


  * The copyright notice does not refer to any license that would allow
    inclusion in OpenSSL.

Sigh.  We'll fix that to just submit with the akamai copyright and openssl license.





_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



From chenyt at cs.sjtu.edu.cn  Mon Jun  1 17:18:48 2015
From: chenyt at cs.sjtu.edu.cn (=?utf-8?B?6ZmI6Zuo5Lqt?=)
Date: Mon, 1 Jun 2015 10:18:48 -0700
Subject: [openssl-dev] verify fails for 3-level cert chain when
	usingX509v3 Authority Key Identifier
In-Reply-To: <34904EB8-5056-4E8C-9672-F8686A833CC7@opentrust.com>
References: <RT-Ticket-3886@openssl.org>
 <CAA-U2SgHMV4Zo_vX5ax+uTBSoSePrnTmywDURS5gfYrqFxbwuQ@mail.gmail.com>
 <rt-4.0.4-5720-1432972122-1127.3886-21-0@openssl.org>
 <9B9ECBE7-588D-4155-806D-BB1DA1E92F01@opentrust.com>
 <rt-4.0.4-31731-1433147538-211.3886-6-0@openssl.org>
 <CAA-U2Sj2W7CLegkvwXJbzw09Cm03hvhBk8b=2vNbE2xwKvhO=Q@mail.gmail.com>
 <rt-4.0.4-10747-1433172033-1795.3886-6-0@openssl.org>
 <34904EB8-5056-4E8C-9672-F8686A833CC7@opentrust.com>
Message-ID: <0D7C5FAFE2964330ABE8869F139878E4@sjtu.edu.cn>

Believe that this question will be raised again and again...

Yuting Chen

-----Original Message----- 
From: Erwann Abalea
Sent: Monday, June 01, 2015 10:12 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] verify fails for 3-level cert chain when 
usingX509v3 Authority Key Identifier

Bonsoir John,

> Le 1 juin 2015 ? 17:20, John Lofgren via RT <rt at openssl.org> a ?crit :
> [?]

> One remaining question. If this extension is "only a helper and MUST NOT 
> be
> used to (in)validate a certificate chain" as you say or as the spec says
> "non-critical", then why does 'openssl verify' reject this chain?

That?s an open question. This topic has been raised on IETF PKIX last 
april.
The normative validation algorithm in section 6 of RFC5280 doesn?t use 
AKI/SKI.
RFC4158 is about path construction and is also clear on not using AKI/SKI to 
eliminate a certificate chain.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 


From noloader at gmail.com  Mon Jun  1 17:30:38 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 1 Jun 2015 13:30:38 -0400
Subject: [openssl-dev] F5 termination of TCP connection
In-Reply-To: <87siabe5as.fsf@alice.fifthhorseman.net>
References: <55A0598A7539EC4BAB296D8BBA5AC12288ED6FCC@WTPCPMBMEM07.ams.bnymellon.net>
 <8cb4d4d6f2e1d5ab6ac06c2fe0e75b8d@flogreenserver.dyndns.org>
 <87siabe5as.fsf@alice.fifthhorseman.net>
Message-ID: <CAH8yC8=wOKHf=vK=XwxLJbFENQBhN4B9UfuREw+X=AYzfC5FGQ@mail.gmail.com>

On Mon, Jun 1, 2015 at 12:56 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Mon 2015-06-01 07:36:01 -0400, Krzysztof Kwiatkowski wrote:
>
>> Yes, that's exactly what we do in our configuration. We have 24 servers
>> with rather high workload. SSL is offloaded on F5 load balancer and
>> servers behind load balancers receive decrypted traffic.
>>
>> I'm not aware of any performance issues. And in fact it's quite good
>> idea as server itself doesn't need to know anything about TLS/SSL
>> protocol.
>
> ...  And the network connecting the load balancers to the backend
> servers is completely physically secured, has no untrusted devices
> connected to it anywhere, and all the backend servers completely trust
> each other to avoid snooping or interfering with each others' traffic
> ... right?

+1.

I've seen financial institutions use T1 or T3 framing between data
centers as the only protection (and not IPSec or TLS). Their thinking
was no one could really tap the copper or fibre, so it was not a
problem. If someone did tap the it, then the signal could not be
used/interpreted without special equipment, so it was not a problem
again.

I've also seen malware burrow in within the security boundary at
financial institutions. The malware was more than happy to leave the
databases alone and sniff the traffic to avoid IDS. And the malware
will encrypt its outgoing payload on the way to its dead-drop, so the
data gets encrypted eventually :)

Jeff

From tim at multitalents.net  Mon Jun  1 17:21:01 2015
From: tim at multitalents.net (Tim Rice)
Date: Mon, 1 Jun 2015 10:21:01 -0700 (PDT)
Subject: [openssl-dev] Do you use EGD or PRNGD?
In-Reply-To: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <alpine.UW2.2.11.1506011016080.5291@server01.int.multitalents.net>

On Mon, 1 Jun 2015, Salz, Rich wrote:

> We are thinking of removing support for EGD (entropy-gathering daemon) 
> in the next release.  None of our supported platforms have needed it for 
> some time.  If this will cause an issue for you, please reply soon.

There is one currently shipping system I am aware of that does
need PRNGD. OpenServer 5 from XinuOS.

> --
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
> 

-- 
Tim Rice				Multitalents
tim at multitalents.net



From rsalz at akamai.com  Mon Jun  1 17:38:36 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 1 Jun 2015 17:38:36 +0000
Subject: [openssl-dev] Do you use EGD or PRNGD?
In-Reply-To: <alpine.UW2.2.11.1506011016080.5291@server01.int.multitalents.net>
References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <alpine.UW2.2.11.1506011016080.5291@server01.int.multitalents.net>
Message-ID: <acdd9c34ab614988b973377f5255d11e@ustx2ex-dag1mb2.msg.corp.akamai.com>

> There is one currently shipping system I am aware of that does need PRNGD.
> OpenServer 5 from XinuOS.

Which isn't a supported system...


From rsbecker at nexbridge.com  Mon Jun  1 17:42:47 2015
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Mon, 1 Jun 2015 13:42:47 -0400
Subject: [openssl-dev] Do you use EGD or PRNGD?
In-Reply-To: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <00b101d09c92$600409a0$200c1ce0$@nexbridge.com>

On June 1, 2015 10:03 AM Rich Salz wrote:
> We are thinking of removing support for EGD (entropy-gathering daemon) in
the next release.
> None of our supported platforms have needed it for some time.? If this
will cause
> an issue for you, please reply soon.

While HP NonStop is not officially supported, I have been helping to
maintain a fork for the platform since December and are current through
1.0.2a. We do use prngd. I am looking for ways to get back on the official
platform list, looking for alternatives to prngd for that platform, and
trying get vendor by-in in this area.


From rsalz at akamai.com  Mon Jun  1 18:33:01 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 1 Jun 2015 18:33:01 +0000
Subject: [openssl-dev] Do you use EGD or PRNGD?
In-Reply-To: <00b101d09c92$600409a0$200c1ce0$@nexbridge.com>
References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <00b101d09c92$600409a0$200c1ce0$@nexbridge.com>
Message-ID: <48ce1b94ef3648d990a5e253a8992fec@ustx2ex-dag1mb2.msg.corp.akamai.com>

> While HP NonStop is not officially supported, I have been helping to maintain
> a fork for the platform since December and are current through 1.0.2a. We
> do use prngd. I am looking for ways to get back on the official platform list,
> looking for alternatives to prngd for that platform, and trying get vendor by-
> in in this area.

Thanks for the info.

One possibility is to have a separate program use prngd and write it to a RANDFILE that openssl uses.  Probably servers are the most important users, and you could/should have one file per server ...

From deengert at gmail.com  Mon Jun  1 19:14:21 2015
From: deengert at gmail.com (Douglas E Engert)
Date: Mon, 01 Jun 2015 14:14:21 -0500
Subject: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent
 retry for Public Key parse after Traditional/Subject Public Key Info parse
 fails
In-Reply-To: <rt-4.0.4-16865-1433058399-373.3887-21-0@openssl.org>
References: <RT-Ticket-3887@openssl.org>
 <CAH8yC8nvVUOL9JsHy_X7U8zHSmAhHBpkEh_jFrp6Hgzw5T4Kdg@mail.gmail.com>
 <rt-4.0.4-16865-1433058399-373.3887-21-0@openssl.org>
Message-ID: <556CAF0D.6030009@gmail.com>



On 5/31/2015 2:46 AM, noloader at gmail.com via RT wrote:
> apps.c has a couple of parsing routines called load_pubkey and
> load_key. rsautl uses those routines.
>
> However, there's no option in rsautil to use anything other than a
> ASN.1/DER or PEM encoded traditional key (or subject public key info).
> The code paths are present, we just can't seem to get to them.

The load_pubkey already has code to support FORMAT_PEMRSA
and call PEM_read_bio_RSAPublicKey

Looking at OpenSSL 1.0.2, it looks like the problem is more in
apps.c in the str2fmt that does not have an option to set FORMAT_PEMRSA
or FORMAT_ASN1RSA.

>
> Folks in the field have problem with it on occasion. See, for example,
> "Can't load programmatically generated public key,"
> http://stackoverflow.com/q/30547646.
>
> This patch adds an intelligent fallback:
>
>      /* rsautl does not offer a way to specify just a public key. It
> requires a */
>      /*   subjectPublicKeyInfo, and there's no argument or option to
> switch to  */
>      /*   the other type with either ASN.1/DER or PEM. This attempts to
> make an */
>      /*   intelligent retry. */
>      if(keyformat == FORMAT_PEM) {
>          next_format = FORMAT_PEMRSA;
>      } if(keyformat == FORMAT_ASN1) {
>          next_format = FORMAT_ASN1RSA;
>      } else {
>          next_format = -1;
>      }
>
>      switch (key_type) {
>      case KEY_PRIVKEY:
>          pkey = load_key(keyfile, keyformat, 0, passin, e, "Private
> Key", 0 /*last_try*/);
>          if(!pkey && next_format != -1) { pkey = load_key(keyfile,
> next_format, 0, passin, e, "Private Key", 1 /*last_try*/); }
>          break;
>
>      case KEY_PUBKEY:
>          pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public
> Key", 0 /*last_try*/);
>          if(!pkey && next_format != -1) { pkey = load_pubkey(keyfile,
> next_format, 0, NULL, e, "Public Key", 1 /*last_try*/); }
>          break;
>
> Then, functions load_key and load_pubkey suppress the error messages
> if last_try is 0:
>
>      if (pkey == NULL && last_try) {
>          BIO_printf(bio_err, "unable to load %s\n", key_descrip);
>      }
>
> All in all, existing behavior and error messages are maintained. The
> subcommand is just a little more robust.
>
> Related, we might be able to make similar changes to rsa.c. But
> there's some extra special sauce present, so it was not a clear
> cut-in. I think the special sauce kid of attempts to do the same thing
> as above. (Maybe this patch should act more like rsa.c?)
>
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>


From rsalz at akamai.com  Mon Jun  1 19:41:41 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 1 Jun 2015 19:41:41 +0000
Subject: [openssl-dev] [openssl-users]  Do you use EGD or PRNGD?
In-Reply-To: <CAH8yC8nR00ANC=2YwS0MW3L77gzc5qTg0ocy91nYwccbprBwzA@mail.gmail.com>
References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAH8yC8nR00ANC=2YwS0MW3L77gzc5qTg0ocy91nYwccbprBwzA@mail.gmail.com>
Message-ID: <c2d8a3ff7d554b81b098598473c6c2bc@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I had to install an entropy gather on Debian desktop because reads to
> /dev/random would fail on occasion when the device was opened
> O_NONBLOCK. I was not hitting it hard - I was just trying to grab a 32 byte
> one-time seed to seed an in-app generator. It was really surprising to see
> Debian's RNG could only supply 7 bytes or so. I was amazed it happened out
> of the box in 2014.

I agree, that's pretty amazing.

Why is there no need?

It's hard to get random seeding done right.  The fewer moving parts, the easier it is to understand what's going on, and prove to yourself (or others) that it is correct.

As a workaround, periodically writing EGD data into a file that the application uses...

From richard at levitte.org  Mon Jun  1 19:52:41 2015
From: richard at levitte.org (Richard Levitte)
Date: Mon, 01 Jun 2015 21:52:41 +0200 (CEST)
Subject: [openssl-dev] Do you use EGD or PRNGD?
In-Reply-To: <48ce1b94ef3648d990a5e253a8992fec@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <00b101d09c92$600409a0$200c1ce0$@nexbridge.com>
 <48ce1b94ef3648d990a5e253a8992fec@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150601.215241.1644886557227726719.richard@levitte.org>

In message <48ce1b94ef3648d990a5e253a8992fec at ustx2ex-dag1mb2.msg.corp.akamai.com> on Mon, 1 Jun 2015 18:33:01 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> > While HP NonStop is not officially supported, I have been helping to maintain
rsalz> > a fork for the platform since December and are current through 1.0.2a. We
rsalz> > do use prngd. I am looking for ways to get back on the official platform list,
rsalz> > looking for alternatives to prngd for that platform, and trying get vendor by-
rsalz> > in in this area.
rsalz> 
rsalz> Thanks for the info.
rsalz> 
rsalz> One possibility is to have a separate program use prngd and write it to a RANDFILE that openssl uses.  Probably servers are the most important users, and you could/should have one file per server ...

I'd like to remind people of the possibility to make an engine module.

Cheers,
Richard

-- 
Richard Levitte                         richard at levitte.org
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish

From krzysiek at leeds.pl  Mon Jun  1 20:59:36 2015
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Mon, 01 Jun 2015 22:59:36 +0200
Subject: [openssl-dev] F5 termination of TCP connection
In-Reply-To: <CAH8yC8=wOKHf=vK=XwxLJbFENQBhN4B9UfuREw+X=AYzfC5FGQ@mail.gmail.com>
References: <55A0598A7539EC4BAB296D8BBA5AC12288ED6FCC@WTPCPMBMEM07.ams.bnymellon.net>
 <8cb4d4d6f2e1d5ab6ac06c2fe0e75b8d@flogreenserver.dyndns.org>
 <87siabe5as.fsf@alice.fifthhorseman.net>
 <CAH8yC8=wOKHf=vK=XwxLJbFENQBhN4B9UfuREw+X=AYzfC5FGQ@mail.gmail.com>
Message-ID: <556CC7B8.8020606@leeds.pl>

Yes, obviously security of the connection ends on offloading device with 
all consequences.

I agree that having TLS end-to-end is great but quite hard to do it with 
OpenSSL if you need full-duplex connection. So in my case I have SSL 
till F5. One connection may trigger many transactions inside my intranet 
and here I can't afford half-duplex. So we offload SSL on F5 and just 
make sure everything behind F5 is super secure (but not ssl).

Kris


On 06/01/2015 07:30 PM, Jeffrey Walton wrote:
> On Mon, Jun 1, 2015 at 12:56 PM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>> On Mon 2015-06-01 07:36:01 -0400, Krzysztof Kwiatkowski wrote:
>>
>>> Yes, that's exactly what we do in our configuration. We have 24 servers
>>> with rather high workload. SSL is offloaded on F5 load balancer and
>>> servers behind load balancers receive decrypted traffic.
>>>
>>> I'm not aware of any performance issues. And in fact it's quite good
>>> idea as server itself doesn't need to know anything about TLS/SSL
>>> protocol.
>> ...  And the network connecting the load balancers to the backend
>> servers is completely physically secured, has no untrusted devices
>> connected to it anywhere, and all the backend servers completely trust
>> each other to avoid snooping or interfering with each others' traffic
>> ... right?
> +1.
>
> I've seen financial institutions use T1 or T3 framing between data
> centers as the only protection (and not IPSec or TLS). Their thinking
> was no one could really tap the copper or fibre, so it was not a
> problem. If someone did tap the it, then the signal could not be
> used/interpreted without special equipment, so it was not a problem
> again.
>
> I've also seen malware burrow in within the security boundary at
> financial institutions. The malware was more than happy to leave the
> databases alone and sniff the traffic to avoid IDS. And the malware
> will encrypt its outgoing payload on the way to its dead-drop, so the
> data gets encrypted eventually :)
>
> Jeff
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


From rt at openssl.org  Mon Jun  1 22:03:36 2015
From: rt at openssl.org (Per Allansson via RT)
Date: Tue, 2 Jun 2015 00:03:36 +0200
Subject: [openssl-dev] [openssl.org #3888] BUG: BIO_CTRL_DGRAM_SET_DONT_FRAG
	does nothing on IPv4/Linux
In-Reply-To: <BLUPR0701MB104205F13E019984526451FCE1B60@BLUPR0701MB1042.namprd07.prod.outlook.com>
References: <RT-Ticket-3888@openssl.org>
 <BLUPR0701MB104205F13E019984526451FCE1B60@BLUPR0701MB1042.namprd07.prod.outlook.com>
Message-ID: <rt-4.0.4-28142-1433196210-1811.3888-21-0@openssl.org>

Is present in at least OpenSSL 1.0.2 / master.

The code in bss_dgram.c checks if  IP_MTUDISCOVER is defined, where it should test for IP_MTU_DISCOVER:

diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c
index 5eade50..7cd57bf 100644
--- a/crypto/bio/bss_dgram.c
+++ b/crypto/bio/bss_dgram.c
@@ -882,7 +882,7 @@ static long dgram_ctrl(BIO *b, int cmd, long num, void *ptr)
                 perror("setsockopt");
                 ret = -1;
             }
-# elif defined(OPENSSL_SYS_LINUX) && defined(IP_MTUDISCOVER)
+# elif defined(OPENSSL_SYS_LINUX) && defined(IP_MTU_DISCOVER)
             if ((sockopt_val = num ? IP_PMTUDISC_PROBE : IP_PMTUDISC_DONT),
                 (ret = setsockopt(b->num, IPPROTO_IP, IP_MTU_DISCOVER,
                                   &sockopt_val, sizeof(sockopt_val))) < 0) {





From rt at openssl.org  Tue Jun  2 11:56:04 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 2 Jun 2015 13:56:04 +0200
Subject: [openssl-dev] [openssl.org #3808] BUG: corrupted ssl session id
In-Reply-To: <796405036.28778360.1429265697846.JavaMail.zimbra@stormshield.eu>
References: <RT-Ticket-3808@openssl.org>
 <1771678525.28767891.1429265377682.JavaMail.zimbra@stormshield.eu>
 <796405036.28778360.1429265697846.JavaMail.zimbra@stormshield.eu>
Message-ID: <rt-4.0.4-4544-1433246163-1131.3808-6-0@openssl.org>

Fixes to this pushed to all branches.

Thanks for your report.

Matt


From rt at openssl.org  Tue Jun  2 12:05:12 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 2 Jun 2015 14:05:12 +0200
Subject: [openssl-dev] [openssl.org #3888] BUG: BIO_CTRL_DGRAM_SET_DONT_FRAG
	does nothing on IPv4/Linux
In-Reply-To: <BLUPR0701MB104205F13E019984526451FCE1B60@BLUPR0701MB1042.namprd07.prod.outlook.com>
References: <RT-Ticket-3888@openssl.org>
 <BLUPR0701MB104205F13E019984526451FCE1B60@BLUPR0701MB1042.namprd07.prod.outlook.com>
Message-ID: <rt-4.0.4-4544-1433246712-64.3888-6-0@openssl.org>

Patch applied. Many thanks.

Matt


From rt at openssl.org  Tue Jun  2 13:50:19 2015
From: rt at openssl.org (Pascal Cuoq via RT)
Date: Tue, 2 Jun 2015 15:50:19 +0200
Subject: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior
	executed through OpenSSL tests
In-Reply-To: <E0753661-CEA5-4771-B5B6-967F3BFDA253@trust-in-soft.com>
References: <RT-Ticket-3891@openssl.org>
 <E0753661-CEA5-4771-B5B6-967F3BFDA253@trust-in-soft.com>
Message-ID: <rt-4.0.4-27406-1433253016-1519.3891-21-0@openssl.org>

The attached archive contains a collection of patches for undefined behaviors
that happen while the tests in directory tests/ are executed, with a recent
(as of June 2015) OpenSSL git version.

Each undefined behavior really happens for at least one
execution, the execution of the test. In other terms, none of these is a
?false positive?. The issues broadly fall in the following categories:

- accessing uninitialized data, sometimes as a result of not testing
the error code of a function (the patch fixes the caller to check for success of the
function that's supposed to allocate or initialize);

- dereferencing NULL (often for the same reason of failing to check for success
of called functions);

- using dangling pointers in comparisons as a result of the order in which they
are freed and compared.

A README file discusses the changes for which discussion seems necessary.

The undefined behaviors were found using a Valgrind-like, ASan-like tool to be
released as Open-Source soon: http://trust-in-soft.com/tis-interpreter/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl_git_patches.tgz
Type: application/octet-stream
Size: 8543 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150602/b79aa84d/attachment-0001.obj>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rt at openssl.org  Tue Jun  2 15:54:47 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 2 Jun 2015 17:54:47 +0200
Subject: [openssl-dev] [openssl.org #3848] [PATCH] Fix memory leak caused by
	not calling SSL_COMP_free_compression_methods()
In-Reply-To: <BLUPR03MB341AEECC2B98C33217866C3EBD90@BLUPR03MB341.namprd03.prod.outlook.com>
References: <RT-Ticket-3848@openssl.org>
 <BLUPR03MB341AEECC2B98C33217866C3EBD90@BLUPR03MB341.namprd03.prod.outlook.com>
Message-ID: <rt-4.0.4-21548-1433260487-606.3848-6-0@openssl.org>

Thanks! Applied.
commit 45d051c82563a75b07ec54b63e3a5bbad388ab67
Author: Gunnar Kudrjavets <gunnarku at exchange.microsoft.com>
Date: Wed May 13 15:13:55 2015 -0400

RT3848: Call SSL_COMP_free_compression_methods

Signed-off-by: Rich Salz <rsalz at akamai.com>
Reviewed-by: Matt Caswell <matt at openssl.org>
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Tue Jun  2 15:58:58 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 2 Jun 2015 17:58:58 +0200
Subject: [openssl-dev] [openssl.org #3472] PATCH: Update info on PKCS8
	command and -iter option
In-Reply-To: <CAH8yC8mFKd9pJBYPsxBV=YCNV2xWu5B8cMwY7MkvLmPvj9_FOg@mail.gmail.com>
References: <RT-Ticket-3472@openssl.org>
 <CAH8yC8mFKd9pJBYPsxBV=YCNV2xWu5B8cMwY7MkvLmPvj9_FOg@mail.gmail.com>
Message-ID: <rt-4.0.4-22429-1433260738-282.3472-6-0@openssl.org>

fixed thanks
commit f20bb4eb18b01979cb23b2ae4a60675c83c4ba91
Author: Jeffrey Walton <noloader at gmail.com>
Date: Wed May 13 15:27:57 2015 -0400

RT3472: Doc pkcs8 -iter flag is in OpenSSL 1.1

Reviewed-by: Matt Caswell <matt at openssl.org>
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Tue Jun  2 16:24:35 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 2 Jun 2015 18:24:35 +0200
Subject: [openssl-dev] [openssl.org #832] ocsp and dsa key+socket option
	SO_REUSEADDR for responder
References: <RT-Ticket-832@openssl.org>
Message-ID: <rt-4.0.4-27182-1433262275-1507.832-6-0@openssl.org>

fixed in master

master 366e2a6 RT832: Use REUSEADDR in ocsp responder

Author: Rich Salz <rsalz at akamai.com>
Date: Sat May 2 10:44:31 2015 -0400

RT832: Use REUSEADDR in ocsp responder

I also re-ordered some of #ifdef's.

Reviewed-by: Matt Caswell <matt at openssl.org>

--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Tue Jun  2 21:19:14 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 2 Jun 2015 23:19:14 +0200
Subject: [openssl-dev] [openssl.org #3230] Deficiency in the Perl script
	openssl/crypto/objects/objects.pl
In-Reply-To: <2193.84.190.43.201.1389391598.squirrel@www2.informatik.hu-berlin.de>
References: <RT-Ticket-3230@openssl.org>
 <2193.84.190.43.201.1389391598.squirrel@www2.informatik.hu-berlin.de>
Message-ID: <rt-4.0.4-448-1433279953-1159.3230-6-0@openssl.org>

OpenSSL_1_0_1-stable 32b2ad7 RT3230: Better test for C identifier
OpenSSL_1_0_2-stable fb22f74 RT3230: Better test for C identifier
master 591b7ae RT3230: Better test for C identifier

Author: Annie Yousar <a.yousar at informatik.hu-berlin.de>
Date: Sun May 3 09:05:47 2015 -0400

RT3230: Better test for C identifier

objects.pl only looked for a space to see if the name could be
used as a C identifier. Improve the test to match the real C
rules.

Signed-off-by: Rich Salz <rsalz at akamai.com>
Reviewed-by: Matt Caswell <matt at openssl.org>
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Tue Jun  2 21:59:11 2015
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 2 Jun 2015 23:59:11 +0200
Subject: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined
	behavior executed through OpenSSL tests
In-Reply-To: <afe5b7a2885547afb619808b2b4e2d5c@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3891@openssl.org>
 <E0753661-CEA5-4771-B5B6-967F3BFDA253@trust-in-soft.com>
 <rt-4.0.4-27406-1433253016-1519.3891-21-0@openssl.org>
 <afe5b7a2885547afb619808b2b4e2d5c@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <rt-4.0.4-752-1433282350-1460.3891-6-0@openssl.org>

Generally, these look good.  I have concerns about three (that you raised); quoting from your README.  Any comments from others?

+ err.c.patch
The 'int_thread_del_item' function calls 'int_thread_release' that accesses (*hash), but this is invalid because  'int_thread_del_item' frees 'int_thread_hash' that can be an alias of 'hash'. This patch fixes the problem, but WARNING: it changes the program behavior since 'int_thread_release' now returns earlier and then doesn't call CRYPTO_add. Don't know whether this is the correct fix for this problem.

+ mem_dbg.c.patch
The 'pop_info' function return 'ret' after OPENSSL_free(ret), and the returned value is then tested (ret = (pop_info() != NULL)) in CRYPTO_pop_info,
which is incorrect since the address is now a dangling pointer ("indeterminate" in the C standard). This patch fixes the problem, but don't know whether this is the correct fix regarding the behavior of the 'pop_info' callers. Regardless, returning an address that has just been passed to free() is never useful and a change is necessary here.

+ Patches about catching memory allocation errors are grouped in malloc.patch
Most of them consist on adding tests about fields being non-NULL before accessing to sub-fields, or tests on the returned value of functions that where memory allocation may have failed.


From levitte at openssl.org  Wed Jun  3 05:17:31 2015
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 03 Jun 2015 07:17:31 +0200 (CEST)
Subject: [openssl-dev] RT is down, will be up again within the hour
Message-ID: <20150603.071731.2156788991817514345.levitte@openssl.org>

Hi,

OpenSSL's request tracker is down for the moment being, but will rise
again within the hour, in a new box and updated software.

What has happened is that the request tracker is moving to a new and
hopefully more powerful box (*).  That new box has had a slave
database server that's been synchronising its data with the old box
for a few days, and now is the time to switch over.

The DNS entries have been changed a few minutes ago, and now, all that
remains is to wait for DNS around the globe to cache up.  Meanwhile,
to allow database traffic between the boxes to slow down, I've taken
down the web service on the old box.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Wed Jun  3 05:36:14 2015
From: rt at openssl.org (Osvaldo Calles via RT)
Date: Wed, 03 Jun 2015 05:36:14 +0000
Subject: [openssl-dev] [openssl.org #3893] Bug in openssl-1.0.2a when
	disabling DES
In-Reply-To: <CAH12EXxNtofdp=C_qVmFKnenpD6qnmK_M3WsMH70JQkMa=77-A@mail.gmail.com>
References: <RT-Ticket-3893@openssl.org>
 <CAH12EXxNtofdp=C_qVmFKnenpD6qnmK_M3WsMH70JQkMa=77-A@mail.gmail.com>
Message-ID: <rt-4.0.19-6286-1433309774-1481.3893-21-0@openssl.org>

Self-test report generated by 'make report' - testlog attached

Application Details (name, version)
 - openssl-1.0.2a

Problem Description

./Configure linux-x86_64 no-des
make depend
make

../libcrypto.a(cms_kari.o): In function `cms_RecipientInfo_kari_encrypt':
cms_kari.c:(.text+0xa21): undefined reference to `EVP_des_ede3_wrap'
collect2: error: ld returned 1 exit status
../Makefile.shared:164: recipe for target 'link_app.' failed



when OPENSSL_NO_DES is defined (no-des), the cms utility (Cryptographic
Message Syntax) should not use des3 for encryption.

------------------
In file cms_kari.c at line 400

if (EVP_CIPHER_type(cipher) == NID_des_ede3_cbc)
kekcipher = EVP_des_ede3_wrap();

------------------

An error message should be printed to the final user "des3 not supported"

-- 
:[ Saludos .... Osvaldo Calles :[

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testlog
Type: application/octet-stream
Size: 19285 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150603/0c5884fa/attachment-0001.obj>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rt at openssl.org  Wed Jun  3 14:42:06 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 03 Jun 2015 14:42:06 +0000
Subject: [openssl-dev] [openssl.org #3872] EVP_PKEY_asn1_set_item
In-Reply-To: <CAGo04MWwWTA5ZJot0C0T0T8KsN78e=SWXhvQQMcKaXmrFkyZOg@mail.gmail.com>
References: <RT-Ticket-3872@openssl.org>
 <CAGo04MWwWTA5ZJot0C0T0T8KsN78e=SWXhvQQMcKaXmrFkyZOg@mail.gmail.com>
Message-ID: <rt-4.0.19-6285-1433342526-432.3872-6-0@openssl.org>

Committed now. Thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From rt at openssl.org  Wed Jun  3 19:00:58 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Wed, 03 Jun 2015 19:00:58 +0000
Subject: [openssl-dev] [openssl.org #3894] PATCH: EVP_PKEY_get_type (new
	function)
In-Reply-To: <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
Message-ID: <rt-4.0.19-6285-1433358057-324.3894-21-0@openssl.org>

I've found this to be a useful function over the years. I shared it
with others, too (see, for example,
http://stackoverflow.com/a/30626251/608639).

I understand opacity is preferred and this is discouraged, and the
additional documentation reflects the sentiment.

For me (and the the programmers under me), this is completely about
validating state; and not about encapsulation. I do not allow a
transition from one state to the next without control. That means
EVP_PKEY_get1_RSA cannot be called *unless* they actually have an RSA
key. Otherwise, the operation must hard fail.

I have similar requirements for freeing pointers. To call free, a
pointer must be non-NULL. Otherwise, its a logic error since its not
possible to free a NULL pointer. So EVP_PKEY_get_type is about both
form and function. Not everyone has the same opinions, so we need a
choice. EVP_PKEY_get_type provides that choice.

*****

Attached is both the `git diff` and the new documentation. The new
documentation was not included in the diff, even after a `git add`.
Git is such a miserable tool at times....

-------------- next part --------------
diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
index 1fdde9a..0cd8a42 100644
--- a/crypto/evp/evp_lib.c
+++ b/crypto/evp/evp_lib.c
@@ -61,6 +61,15 @@
 #include <openssl/evp.h>
 #include <openssl/objects.h>
 
+/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
+int EVP_PKEY_get_type(EVP_PKEY *pkey)
+{
+    if (!pkey)
+        return EVP_PKEY_NONE;
+
+    return EVP_PKEY_type(pkey->type);
+}
+
 int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
 {
     int ret;
diff --git a/doc/crypto/evp.pod b/doc/crypto/evp.pod
index 29fab9f..288f373 100644
--- a/doc/crypto/evp.pod
+++ b/doc/crypto/evp.pod
@@ -97,6 +97,7 @@ L<EVP_PKEY_verify(3)|EVP_PKEY_verify(3)>,
 L<EVP_PKEY_verify_recover(3)|EVP_PKEY_verify_recover(3)>,
 L<EVP_PKEY_derive(3)|EVP_PKEY_derive(3)>,
 L<EVP_BytesToKey(3)|EVP_BytesToKey(3)>,
+L<EVP_PKEY_get_type(3)|EVP_PKEY_get_type(3)>,
 L<OpenSSL_add_all_algorithms(3)|OpenSSL_add_all_algorithms(3)>,
 L<engine(3)|engine(3)>
 
diff --git a/include/openssl/evp.h b/include/openssl/evp.h
index dff81b0..7b25313 100644
--- a/include/openssl/evp.h
+++ b/include/openssl/evp.h
@@ -109,6 +109,9 @@
 # define EVP_PKEY_HMAC   NID_hmac
 # define EVP_PKEY_CMAC   NID_cmac
 
+/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
+int EVP_PKEY_get_type(EVP_PKEY *pkey);
+
 #ifdef  __cplusplus
 extern "C" {
 #endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EVP_PKEY_get_type.pod
Type: application/octet-stream
Size: 1408 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150603/a30ba6c4/attachment.obj>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rt at openssl.org  Wed Jun  3 20:50:25 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Wed, 03 Jun 2015 20:50:25 +0000
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
	EVP_PKEY_get_type (new function)
In-Reply-To: <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
Message-ID: <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>

Here's an updated patch that includes the documentation changes. `git
diff master` is needed after `git add` because adding doesn't seem to
really add things for git :)

riemann::openssl-git$ cat evp_pkey_get_type.diff
diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
index 1fdde9a..0cd8a42 100644
--- a/crypto/evp/evp_lib.c
+++ b/crypto/evp/evp_lib.c
@@ -61,6 +61,15 @@
 #include <openssl/evp.h>
 #include <openssl/objects.h>

+/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
+int EVP_PKEY_get_type(EVP_PKEY *pkey)
+{
+    if (!pkey)
+        return EVP_PKEY_NONE;
+
+    return EVP_PKEY_type(pkey->type);
+}
+
 int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
 {
     int ret;
diff --git a/doc/crypto/EVP_PKEY_get_type.pod b/doc/crypto/EVP_PKEY_get_type.pod
new file mode 100644
index 0000000..1faaae5
--- /dev/null
+++ b/doc/crypto/EVP_PKEY_get_type.pod
@@ -0,0 +1,65 @@
+=pod
+
+=head1 NAME
+
+EVP_PKEY_get_type - queries the EVP_PKEY for the type of key
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ int EVP_PKEY_get_type(EVP_PKEY *pkey);
+
+=head1 DESCRIPTION
+
+B<EVP_PKEY_get_type> queries the EVP_PKEY for the type of key.
+
+Though B<EVP_PKEY_get_type> is available, its use is discouraged
because it peeks into implementation specific details.
+
+==head1 RETURN VALUES
+
+If B<pkey> is B<NULL>, then the function returns B<EVP_PKEY_NONE>.
+
+If B<pkey> is not B<NULL>, then the return value will be one of the
following values from B<evp.h>:
+
+ * EVP_PKEY_NONE
+ * EVP_PKEY_RSA
+ * EVP_PKEY_RSA2
+ * EVP_PKEY_DSA
+ * EVP_PKEY_DSA1
+ * EVP_PKEY_DSA2
+ * EVP_PKEY_DSA3
+ * EVP_PKEY_DSA4
+ * EVP_PKEY_DH
+ * EVP_PKEY_DHX
+ * EVP_PKEY_EC
+ * EVP_PKEY_HMAC
+ * EVP_PKEY_CMAC
+
+==head1 EXAMPLE
+
+EVP_PKEY* pkey = PEM_read_PUBKEY(...);
+if(pkey == NULL) /* Error */
+
+int type = EVP_PKEY_get_type(pkey);
+if(type != EVP_PKEY_RSA && type != EVP_PKEY_RSA2) /* Error */
+
+RSA* rsa = EVP_PKEY_get1_RSA(pkey);
+if(rsa == NULL) /* Error */
+
+/* Use 'rsa' in RSA_size, RSA_public_encrypt, etc */
+
+RSA_free(rsa);
+EVP_free(pkey);
+
+==head1 SEE ALSO
+
+B<EVP(3), EVP(3)>,
+B<EVP_PKEY_get1_DH(3), EVP_PKEY_get1_DH(3)>,
+B<EVP_PKEY_get1_DSA(3), EVP_PKEY_get1_DSA(3)>,
+B<EVP_PKEY_get1_EC_KEY(3), EVP_PKEY_get1_EC_KEY(3)>,
+B<EVP_PKEY_get1_RSA(3), EVP_PKEY_get1_RSA(3)>,
+
+==head1 HISTORY
+
+This function was first added to OpenSSL 1.1.0.
\ No newline at end of file
diff --git a/doc/crypto/evp.pod b/doc/crypto/evp.pod
index 29fab9f..288f373 100644
--- a/doc/crypto/evp.pod
+++ b/doc/crypto/evp.pod
@@ -97,6 +97,7 @@ L<EVP_PKEY_verify(3)|EVP_PKEY_verify(3)>,
 L<EVP_PKEY_verify_recover(3)|EVP_PKEY_verify_recover(3)>,
 L<EVP_PKEY_derive(3)|EVP_PKEY_derive(3)>,
 L<EVP_BytesToKey(3)|EVP_BytesToKey(3)>,
+L<EVP_PKEY_get_type(3)|EVP_PKEY_get_type(3)>,
 L<OpenSSL_add_all_algorithms(3)|OpenSSL_add_all_algorithms(3)>,
 L<engine(3)|engine(3)>

diff --git a/include/openssl/evp.h b/include/openssl/evp.h
index dff81b0..8a90b10 100644
--- a/include/openssl/evp.h
+++ b/include/openssl/evp.h
@@ -742,6 +742,9 @@ int EVP_CIPHER_CTX_set_padding(EVP_CIPHER_CTX *c, int pad);
 int EVP_CIPHER_CTX_ctrl(EVP_CIPHER_CTX *ctx, int type, int arg, void *ptr);
 int EVP_CIPHER_CTX_rand_key(EVP_CIPHER_CTX *ctx, unsigned char *key);

+/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
+int EVP_PKEY_get_type(EVP_PKEY *pkey);
+
 BIO_METHOD *BIO_f_md(void);
 BIO_METHOD *BIO_f_base64(void);
 BIO_METHOD *BIO_f_cipher(void);
riemann::openssl-git$


On Wed, Jun 3, 2015 at 3:00 PM, The default queue via RT <rt at openssl.org> wrote:
>
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
>         "PATCH: EVP_PKEY_get_type (new function)",
> 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 #3894].

-------------- next part --------------
diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
index 1fdde9a..0cd8a42 100644
--- a/crypto/evp/evp_lib.c
+++ b/crypto/evp/evp_lib.c
@@ -61,6 +61,15 @@
 #include <openssl/evp.h>
 #include <openssl/objects.h>
 
+/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
+int EVP_PKEY_get_type(EVP_PKEY *pkey)
+{
+    if (!pkey)
+        return EVP_PKEY_NONE;
+
+    return EVP_PKEY_type(pkey->type);
+}
+
 int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
 {
     int ret;
diff --git a/doc/crypto/EVP_PKEY_get_type.pod b/doc/crypto/EVP_PKEY_get_type.pod
new file mode 100644
index 0000000..1faaae5
--- /dev/null
+++ b/doc/crypto/EVP_PKEY_get_type.pod
@@ -0,0 +1,65 @@
+=pod
+
+=head1 NAME
+
+EVP_PKEY_get_type - queries the EVP_PKEY for the type of key
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ int EVP_PKEY_get_type(EVP_PKEY *pkey);
+
+=head1 DESCRIPTION
+
+B<EVP_PKEY_get_type> queries the EVP_PKEY for the type of key.
+
+Though B<EVP_PKEY_get_type> is available, its use is discouraged because it peeks into implementation specific details.
+
+==head1 RETURN VALUES
+
+If B<pkey> is B<NULL>, then the function returns B<EVP_PKEY_NONE>.
+
+If B<pkey> is not B<NULL>, then the return value will be one of the following values from B<evp.h>:
+
+ * EVP_PKEY_NONE
+ * EVP_PKEY_RSA
+ * EVP_PKEY_RSA2
+ * EVP_PKEY_DSA
+ * EVP_PKEY_DSA1
+ * EVP_PKEY_DSA2
+ * EVP_PKEY_DSA3
+ * EVP_PKEY_DSA4
+ * EVP_PKEY_DH
+ * EVP_PKEY_DHX
+ * EVP_PKEY_EC
+ * EVP_PKEY_HMAC
+ * EVP_PKEY_CMAC
+
+==head1 EXAMPLE
+
+EVP_PKEY* pkey = PEM_read_PUBKEY(...);
+if(pkey == NULL) /* Error */
+
+int type = EVP_PKEY_get_type(pkey);
+if(type != EVP_PKEY_RSA && type != EVP_PKEY_RSA2) /* Error */
+
+RSA* rsa = EVP_PKEY_get1_RSA(pkey);
+if(rsa == NULL) /* Error */
+
+/* Use 'rsa' in RSA_size, RSA_public_encrypt, etc */
+
+RSA_free(rsa);
+EVP_free(pkey);
+
+==head1 SEE ALSO
+
+B<EVP(3), EVP(3)>,
+B<EVP_PKEY_get1_DH(3), EVP_PKEY_get1_DH(3)>,
+B<EVP_PKEY_get1_DSA(3), EVP_PKEY_get1_DSA(3)>,
+B<EVP_PKEY_get1_EC_KEY(3), EVP_PKEY_get1_EC_KEY(3)>,
+B<EVP_PKEY_get1_RSA(3), EVP_PKEY_get1_RSA(3)>,
+
+==head1 HISTORY
+
+This function was first added to OpenSSL 1.1.0.
\ No newline at end of file
diff --git a/doc/crypto/evp.pod b/doc/crypto/evp.pod
index 29fab9f..288f373 100644
--- a/doc/crypto/evp.pod
+++ b/doc/crypto/evp.pod
@@ -97,6 +97,7 @@ L<EVP_PKEY_verify(3)|EVP_PKEY_verify(3)>,
 L<EVP_PKEY_verify_recover(3)|EVP_PKEY_verify_recover(3)>,
 L<EVP_PKEY_derive(3)|EVP_PKEY_derive(3)>,
 L<EVP_BytesToKey(3)|EVP_BytesToKey(3)>,
+L<EVP_PKEY_get_type(3)|EVP_PKEY_get_type(3)>,
 L<OpenSSL_add_all_algorithms(3)|OpenSSL_add_all_algorithms(3)>,
 L<engine(3)|engine(3)>
 
diff --git a/include/openssl/evp.h b/include/openssl/evp.h
index dff81b0..8a90b10 100644
--- a/include/openssl/evp.h
+++ b/include/openssl/evp.h
@@ -742,6 +742,9 @@ int EVP_CIPHER_CTX_set_padding(EVP_CIPHER_CTX *c, int pad);
 int EVP_CIPHER_CTX_ctrl(EVP_CIPHER_CTX *ctx, int type, int arg, void *ptr);
 int EVP_CIPHER_CTX_rand_key(EVP_CIPHER_CTX *ctx, unsigned char *key);
 
+/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
+int EVP_PKEY_get_type(EVP_PKEY *pkey);
+
 BIO_METHOD *BIO_f_md(void);
 BIO_METHOD *BIO_f_base64(void);
 BIO_METHOD *BIO_f_cipher(void);

From prasad.sg at hp.com  Thu Jun  4 06:06:46 2015
From: prasad.sg at hp.com (Sg, Prasad)
Date: Thu, 4 Jun 2015 06:06:46 +0000
Subject: [openssl-dev] logjam vulnerability -- changes to 0.9.8 version
Message-ID: <AC26DFF54C285B47BF4E94E8662DC09ACF0ADDF3@G4W3292.americas.hpqcorp.net>

Hi,

I could see that the changes for restricting the DH parameter size is done only to 1.0.1 and 1.0.2 branches of OpenSSL.
Will this be back ported to 0.9.8 branch as well?

Thanks and warm regards,
Prasad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150604/09869114/attachment.html>

From kurt at roeckx.be  Thu Jun  4 19:09:41 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 4 Jun 2015 21:09:41 +0200
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
 EVP_PKEY_get_type (new function)
In-Reply-To: <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
 <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
Message-ID: <20150604190941.GA8688@roeckx.be>

On Wed, Jun 03, 2015 at 08:50:25PM +0000, noloader at gmail.com via RT wrote:
> Here's an updated patch that includes the documentation changes. `git
> diff master` is needed after `git add` because adding doesn't seem to
> really add things for git :)
> 
> riemann::openssl-git$ cat evp_pkey_get_type.diff
> diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
> index 1fdde9a..0cd8a42 100644
> --- a/crypto/evp/evp_lib.c
> +++ b/crypto/evp/evp_lib.c
> @@ -61,6 +61,15 @@
>  #include <openssl/evp.h>
>  #include <openssl/objects.h>
> 
> +/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
> +int EVP_PKEY_get_type(EVP_PKEY *pkey)
> +{
> +    if (!pkey)
> +        return EVP_PKEY_NONE;
> +
> +    return EVP_PKEY_type(pkey->type);
> +}
> +

This seems to do almost exactly the same as EVP_PKEY_base_id().

>  int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
>  {
>      int ret;
> diff --git a/doc/crypto/EVP_PKEY_get_type.pod b/doc/crypto/EVP_PKEY_get_type.pod
> new file mode 100644
> index 0000000..1faaae5
> --- /dev/null
> +++ b/doc/crypto/EVP_PKEY_get_type.pod
> @@ -0,0 +1,65 @@
> +=pod
> +
> +=head1 NAME
> +
> +EVP_PKEY_get_type - queries the EVP_PKEY for the type of key
> +
> +=head1 SYNOPSIS
> +
> + #include <openssl/evp.h>
> +
> + int EVP_PKEY_get_type(EVP_PKEY *pkey);
> +
> +=head1 DESCRIPTION
> +
> +B<EVP_PKEY_get_type> queries the EVP_PKEY for the type of key.

I think I prefer that to be written as EVP_PKEY_get_type() instead
of B<EVP_PKEY_get_type>.

> +Though B<EVP_PKEY_get_type> is available, its use is discouraged
> because it peeks into implementation specific details.

This doesn't make sense.  You're discouraging the function you
add?  Maybe you mean EVP_PKEY_type(pkey->type)?

I don't know if there are plans to run the EVP_PKEY into a opaque
struct soon, but it probably should.  I would avoid talking about
implementation details unless it's important for the user to know,
and that doesn't seem to be the case.

> +==head1 RETURN VALUES
> +
> +If B<pkey> is B<NULL>, then the function returns B<EVP_PKEY_NONE>.
> +
> +If B<pkey> is not B<NULL>, then the return value will be one of the
> following values from B<evp.h>:
> +
> + * EVP_PKEY_NONE
> + * EVP_PKEY_RSA
> + * EVP_PKEY_RSA2
> + * EVP_PKEY_DSA
> + * EVP_PKEY_DSA1
> + * EVP_PKEY_DSA2
> + * EVP_PKEY_DSA3
> + * EVP_PKEY_DSA4
> + * EVP_PKEY_DH
> + * EVP_PKEY_DHX
> + * EVP_PKEY_EC
> + * EVP_PKEY_HMAC
> + * EVP_PKEY_CMAC

EVP_PKEY_type() currently documents:

EVP_PKEY_type() returns the type of key corresponding to
the value type. The type of a key can be obtained with
EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding key
types or NID_undef if the key type is unassigned.

I'm guessing one of them is wrong.


Kurt


From rt at openssl.org  Thu Jun  4 19:09:50 2015
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Thu, 04 Jun 2015 19:09:50 +0000
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
	EVP_PKEY_get_type (new function)
In-Reply-To: <20150604190941.GA8688@roeckx.be>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
 <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
 <20150604190941.GA8688@roeckx.be>
Message-ID: <rt-4.0.19-6285-1433444990-1381.3894-6-0@openssl.org>

On Wed, Jun 03, 2015 at 08:50:25PM +0000, noloader at gmail.com via RT wrote:
> Here's an updated patch that includes the documentation changes. `git
> diff master` is needed after `git add` because adding doesn't seem to
> really add things for git :)
> 
> riemann::openssl-git$ cat evp_pkey_get_type.diff
> diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
> index 1fdde9a..0cd8a42 100644
> --- a/crypto/evp/evp_lib.c
> +++ b/crypto/evp/evp_lib.c
> @@ -61,6 +61,15 @@
>  #include <openssl/evp.h>
>  #include <openssl/objects.h>
> 
> +/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
> +int EVP_PKEY_get_type(EVP_PKEY *pkey)
> +{
> +    if (!pkey)
> +        return EVP_PKEY_NONE;
> +
> +    return EVP_PKEY_type(pkey->type);
> +}
> +

This seems to do almost exactly the same as EVP_PKEY_base_id().

>  int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
>  {
>      int ret;
> diff --git a/doc/crypto/EVP_PKEY_get_type.pod b/doc/crypto/EVP_PKEY_get_type.pod
> new file mode 100644
> index 0000000..1faaae5
> --- /dev/null
> +++ b/doc/crypto/EVP_PKEY_get_type.pod
> @@ -0,0 +1,65 @@
> +=pod
> +
> +=head1 NAME
> +
> +EVP_PKEY_get_type - queries the EVP_PKEY for the type of key
> +
> +=head1 SYNOPSIS
> +
> + #include <openssl/evp.h>
> +
> + int EVP_PKEY_get_type(EVP_PKEY *pkey);
> +
> +=head1 DESCRIPTION
> +
> +B<EVP_PKEY_get_type> queries the EVP_PKEY for the type of key.

I think I prefer that to be written as EVP_PKEY_get_type() instead
of B<EVP_PKEY_get_type>.

> +Though B<EVP_PKEY_get_type> is available, its use is discouraged
> because it peeks into implementation specific details.

This doesn't make sense.  You're discouraging the function you
add?  Maybe you mean EVP_PKEY_type(pkey->type)?

I don't know if there are plans to run the EVP_PKEY into a opaque
struct soon, but it probably should.  I would avoid talking about
implementation details unless it's important for the user to know,
and that doesn't seem to be the case.

> +==head1 RETURN VALUES
> +
> +If B<pkey> is B<NULL>, then the function returns B<EVP_PKEY_NONE>.
> +
> +If B<pkey> is not B<NULL>, then the return value will be one of the
> following values from B<evp.h>:
> +
> + * EVP_PKEY_NONE
> + * EVP_PKEY_RSA
> + * EVP_PKEY_RSA2
> + * EVP_PKEY_DSA
> + * EVP_PKEY_DSA1
> + * EVP_PKEY_DSA2
> + * EVP_PKEY_DSA3
> + * EVP_PKEY_DSA4
> + * EVP_PKEY_DH
> + * EVP_PKEY_DHX
> + * EVP_PKEY_EC
> + * EVP_PKEY_HMAC
> + * EVP_PKEY_CMAC

EVP_PKEY_type() currently documents:

EVP_PKEY_type() returns the type of key corresponding to
the value type. The type of a key can be obtained with
EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding key
types or NID_undef if the key type is unassigned.

I'm guessing one of them is wrong.


Kurt



From noloader at gmail.com  Thu Jun  4 20:52:22 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 4 Jun 2015 16:52:22 -0400
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
 EVP_PKEY_get_type (new function)
In-Reply-To: <rt-4.0.19-6285-1433444990-1381.3894-6-0@openssl.org>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
 <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
 <20150604190941.GA8688@roeckx.be>
 <rt-4.0.19-6285-1433444990-1381.3894-6-0@openssl.org>
Message-ID: <CAH8yC8m_ZKSo4_wUfNd8s_w5JbW0Wpkd2Ba0yTH4HZkopyQDjw@mail.gmail.com>

Thanks Kurt. I think I'll need to think about this some more because I
don't recall EVP_PKEY_id.

I think I never considered it because I could not find it when
searching for something to return the inner type ('id' does not make a
lot of sense to me, even now).

Maybe I should back up a bit. What is 'id' supposed to do above and
beyond providing the 'type'?

*****

> I don't know if there are plans to run the EVP_PKEY into a opaque
> struct soon, but it probably should.

That's fine as long as we have an accessor to ensure we are working
with what we expect. Otherwise, we can't validate which means we can't
use the value.

*****

> This doesn't make sense.  You're discouraging the function you
> add?  Maybe you mean EVP_PKEY_type(pkey->type)?

Yeah, you're kind of right. On one hand, its lower level and its use
is discouraged (see the NOTES in evp,h). On the other hand, we need it
for use.

*****

According to the man pages for EVP_PKEY_type:

       EVP_PKEY_type() returns the type of key corresponding to the value
       type. The type of a key can be obtained with EVP_PKEY_type(pkey->type).

Reading the man pages, it appears there's no accessor for
`pkey->type`. Otherwise, we would have been told to use `EVP_PKEY_id`.

*****

> This seems to do almost exactly the same as EVP_PKEY_base_id().

Actually, I think its closer to EVP_PKEY_id().

Also, we have a NULL pointer dereference in the existing function:

    int EVP_PKEY_id(const EVP_PKEY *pkey)
    {
        return pkey->type;
    }

(Sorry, I did not recall seeing that function).

*****

> EVP_PKEY_type() currently documents:
>
> EVP_PKEY_type() returns the type of key corresponding to
> the value type. The type of a key can be obtained with
> EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
> EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding key
> types or NID_undef if the key type is unassigned.
>
> I'm guessing one of them is wrong.

key->type appears to be able to return both EVP_PKEY_RSA and
EVP_PKEY_RSA2. So what should be done here?

Perhaps something like:

    int EVP_PKEY_id(const EVP_PKEY *pkey)
    {
        if(!pkey) return EVP_PKEY_NONE;

        const int type= pkey->type;

        if(type == EVP_PKEY_RSA || type == EVP_PKEY_RSA2)
            return EVP_PKEY_RSA;

        ...
    }

Jeff

On Thu, Jun 4, 2015 at 3:09 PM, Kurt Roeckx via RT <rt at openssl.org> wrote:
> On Wed, Jun 03, 2015 at 08:50:25PM +0000, noloader at gmail.com via RT wrote:
>> Here's an updated patch that includes the documentation changes. `git
>> diff master` is needed after `git add` because adding doesn't seem to
>> really add things for git :)
>>
>> riemann::openssl-git$ cat evp_pkey_get_type.diff
>> diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
>> index 1fdde9a..0cd8a42 100644
>> --- a/crypto/evp/evp_lib.c
>> +++ b/crypto/evp/evp_lib.c
>> @@ -61,6 +61,15 @@
>>  #include <openssl/evp.h>
>>  #include <openssl/objects.h>
>>
>> +/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
>> +int EVP_PKEY_get_type(EVP_PKEY *pkey)
>> +{
>> +    if (!pkey)
>> +        return EVP_PKEY_NONE;
>> +
>> +    return EVP_PKEY_type(pkey->type);
>> +}
>> +
>
> This seems to do almost exactly the same as EVP_PKEY_base_id().
>
>>  int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
>>  {
>>      int ret;
>> diff --git a/doc/crypto/EVP_PKEY_get_type.pod b/doc/crypto/EVP_PKEY_get_type.pod
>> new file mode 100644
>> index 0000000..1faaae5
>> --- /dev/null
>> +++ b/doc/crypto/EVP_PKEY_get_type.pod
>> @@ -0,0 +1,65 @@
>> +=pod
>> +
>> +=head1 NAME
>> +
>> +EVP_PKEY_get_type - queries the EVP_PKEY for the type of key
>> +
>> +=head1 SYNOPSIS
>> +
>> + #include <openssl/evp.h>
>> +
>> + int EVP_PKEY_get_type(EVP_PKEY *pkey);
>> +
>> +=head1 DESCRIPTION
>> +
>> +B<EVP_PKEY_get_type> queries the EVP_PKEY for the type of key.
>
> I think I prefer that to be written as EVP_PKEY_get_type() instead
> of B<EVP_PKEY_get_type>.
>
>> +Though B<EVP_PKEY_get_type> is available, its use is discouraged
>> because it peeks into implementation specific details.
>
> This doesn't make sense.  You're discouraging the function you
> add?  Maybe you mean EVP_PKEY_type(pkey->type)?
>
> I don't know if there are plans to run the EVP_PKEY into a opaque
> struct soon, but it probably should.  I would avoid talking about
> implementation details unless it's important for the user to know,
> and that doesn't seem to be the case.
>
>> +==head1 RETURN VALUES
>> +
>> +If B<pkey> is B<NULL>, then the function returns B<EVP_PKEY_NONE>.
>> +
>> +If B<pkey> is not B<NULL>, then the return value will be one of the
>> following values from B<evp.h>:
>> +
>> + * EVP_PKEY_NONE
>> + * EVP_PKEY_RSA
>> + * EVP_PKEY_RSA2
>> + * EVP_PKEY_DSA
>> + * EVP_PKEY_DSA1
>> + * EVP_PKEY_DSA2
>> + * EVP_PKEY_DSA3
>> + * EVP_PKEY_DSA4
>> + * EVP_PKEY_DH
>> + * EVP_PKEY_DHX
>> + * EVP_PKEY_EC
>> + * EVP_PKEY_HMAC
>> + * EVP_PKEY_CMAC
>
> EVP_PKEY_type() currently documents:
>
> EVP_PKEY_type() returns the type of key corresponding to
> the value type. The type of a key can be obtained with
> EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
> EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding key
> types or NID_undef if the key type is unassigned.
>
> I'm guessing one of them is wrong.

From rt at openssl.org  Thu Jun  4 20:52:36 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Thu, 04 Jun 2015 20:52:36 +0000
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
	EVP_PKEY_get_type (new function)
In-Reply-To: <CAH8yC8m_ZKSo4_wUfNd8s_w5JbW0Wpkd2Ba0yTH4HZkopyQDjw@mail.gmail.com>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
 <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
 <20150604190941.GA8688@roeckx.be>
 <rt-4.0.19-6285-1433444990-1381.3894-6-0@openssl.org>
 <CAH8yC8m_ZKSo4_wUfNd8s_w5JbW0Wpkd2Ba0yTH4HZkopyQDjw@mail.gmail.com>
Message-ID: <rt-4.0.19-18362-1433451156-1305.3894-6-0@openssl.org>

Thanks Kurt. I think I'll need to think about this some more because I
don't recall EVP_PKEY_id.

I think I never considered it because I could not find it when
searching for something to return the inner type ('id' does not make a
lot of sense to me, even now).

Maybe I should back up a bit. What is 'id' supposed to do above and
beyond providing the 'type'?

*****

> I don't know if there are plans to run the EVP_PKEY into a opaque
> struct soon, but it probably should.

That's fine as long as we have an accessor to ensure we are working
with what we expect. Otherwise, we can't validate which means we can't
use the value.

*****

> This doesn't make sense.  You're discouraging the function you
> add?  Maybe you mean EVP_PKEY_type(pkey->type)?

Yeah, you're kind of right. On one hand, its lower level and its use
is discouraged (see the NOTES in evp,h). On the other hand, we need it
for use.

*****

According to the man pages for EVP_PKEY_type:

       EVP_PKEY_type() returns the type of key corresponding to the value
       type. The type of a key can be obtained with EVP_PKEY_type(pkey->type).

Reading the man pages, it appears there's no accessor for
`pkey->type`. Otherwise, we would have been told to use `EVP_PKEY_id`.

*****

> This seems to do almost exactly the same as EVP_PKEY_base_id().

Actually, I think its closer to EVP_PKEY_id().

Also, we have a NULL pointer dereference in the existing function:

    int EVP_PKEY_id(const EVP_PKEY *pkey)
    {
        return pkey->type;
    }

(Sorry, I did not recall seeing that function).

*****

> EVP_PKEY_type() currently documents:
>
> EVP_PKEY_type() returns the type of key corresponding to
> the value type. The type of a key can be obtained with
> EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
> EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding key
> types or NID_undef if the key type is unassigned.
>
> I'm guessing one of them is wrong.

key->type appears to be able to return both EVP_PKEY_RSA and
EVP_PKEY_RSA2. So what should be done here?

Perhaps something like:

    int EVP_PKEY_id(const EVP_PKEY *pkey)
    {
        if(!pkey) return EVP_PKEY_NONE;

        const int type= pkey->type;

        if(type == EVP_PKEY_RSA || type == EVP_PKEY_RSA2)
            return EVP_PKEY_RSA;

        ...
    }

Jeff

On Thu, Jun 4, 2015 at 3:09 PM, Kurt Roeckx via RT <rt at openssl.org> wrote:
> On Wed, Jun 03, 2015 at 08:50:25PM +0000, noloader at gmail.com via RT wrote:
>> Here's an updated patch that includes the documentation changes. `git
>> diff master` is needed after `git add` because adding doesn't seem to
>> really add things for git :)
>>
>> riemann::openssl-git$ cat evp_pkey_get_type.diff
>> diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
>> index 1fdde9a..0cd8a42 100644
>> --- a/crypto/evp/evp_lib.c
>> +++ b/crypto/evp/evp_lib.c
>> @@ -61,6 +61,15 @@
>>  #include <openssl/evp.h>
>>  #include <openssl/objects.h>
>>
>> +/* Returns the key type or EVP_PKEY_NONE if pkey is NULL */
>> +int EVP_PKEY_get_type(EVP_PKEY *pkey)
>> +{
>> +    if (!pkey)
>> +        return EVP_PKEY_NONE;
>> +
>> +    return EVP_PKEY_type(pkey->type);
>> +}
>> +
>
> This seems to do almost exactly the same as EVP_PKEY_base_id().
>
>>  int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
>>  {
>>      int ret;
>> diff --git a/doc/crypto/EVP_PKEY_get_type.pod b/doc/crypto/EVP_PKEY_get_type.pod
>> new file mode 100644
>> index 0000000..1faaae5
>> --- /dev/null
>> +++ b/doc/crypto/EVP_PKEY_get_type.pod
>> @@ -0,0 +1,65 @@
>> +=pod
>> +
>> +=head1 NAME
>> +
>> +EVP_PKEY_get_type - queries the EVP_PKEY for the type of key
>> +
>> +=head1 SYNOPSIS
>> +
>> + #include <openssl/evp.h>
>> +
>> + int EVP_PKEY_get_type(EVP_PKEY *pkey);
>> +
>> +=head1 DESCRIPTION
>> +
>> +B<EVP_PKEY_get_type> queries the EVP_PKEY for the type of key.
>
> I think I prefer that to be written as EVP_PKEY_get_type() instead
> of B<EVP_PKEY_get_type>.
>
>> +Though B<EVP_PKEY_get_type> is available, its use is discouraged
>> because it peeks into implementation specific details.
>
> This doesn't make sense.  You're discouraging the function you
> add?  Maybe you mean EVP_PKEY_type(pkey->type)?
>
> I don't know if there are plans to run the EVP_PKEY into a opaque
> struct soon, but it probably should.  I would avoid talking about
> implementation details unless it's important for the user to know,
> and that doesn't seem to be the case.
>
>> +==head1 RETURN VALUES
>> +
>> +If B<pkey> is B<NULL>, then the function returns B<EVP_PKEY_NONE>.
>> +
>> +If B<pkey> is not B<NULL>, then the return value will be one of the
>> following values from B<evp.h>:
>> +
>> + * EVP_PKEY_NONE
>> + * EVP_PKEY_RSA
>> + * EVP_PKEY_RSA2
>> + * EVP_PKEY_DSA
>> + * EVP_PKEY_DSA1
>> + * EVP_PKEY_DSA2
>> + * EVP_PKEY_DSA3
>> + * EVP_PKEY_DSA4
>> + * EVP_PKEY_DH
>> + * EVP_PKEY_DHX
>> + * EVP_PKEY_EC
>> + * EVP_PKEY_HMAC
>> + * EVP_PKEY_CMAC
>
> EVP_PKEY_type() currently documents:
>
> EVP_PKEY_type() returns the type of key corresponding to
> the value type. The type of a key can be obtained with
> EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
> EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding key
> types or NID_undef if the key type is unassigned.
>
> I'm guessing one of them is wrong.



From rt at openssl.org  Thu Jun  4 22:36:25 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 04 Jun 2015 22:36:25 +0000
Subject: [openssl-dev] [openssl.org #3895] fprintf in ssl library
References: <RT-Ticket-3895@openssl.org>
Message-ID: <rt-4.0.19-18362-1433457385-1313.3895-21-0@openssl.org>

Summarizing some email from the team-internal thread.


> rsalz>
> rsalz> In record/ssl3_record.c:
> rsalz> fprintf(stderr,
> rsalz> "%s:%d: rec->data != rec->input\n",
> rsalz> __FILE__, __LINE__);
>
> From the comment above it, I'd say it's elligible to an abort() (I
> thoroughly hate abort() and avoid it like the plague, but there are
> times when I have to admit its usefulness):
>
> /*
> * we can't write into the input stream: Can this ever
> * happen?? (steve)
> */
>
drH: That code came with the initial DTLS stuff and I wasn't sure if that
condition could ever happen, hence the comment from way back. If it does then
the explicit IV handling wont work IIRC.

> rsalz> In s3_srvr.c:
> rsalz> if (i != 64) {
> rsalz> fprintf(stderr, "GOST signature length is %d", i);
> rsalz> }
>
> This looks weird to me. The code following this seems to assume a 64
> byte signature, BUT the comment around line 2916 suggests that a GOST
> signature can have other lengths as well. That suggests that this
> fprintf() is a debugging print... However, it does look to me like
> we're still only handling 64-byte long GOST signatures, so something
> isn't quite complete.
> ... and I need to read up on GOST.
>
> rsalz> In d1_both.c
> rsalz> if (code > 0) {
> rsalz> fprintf(stderr, "invalid state reached %s:%d", __FILE__, __LINE__);
> rsalz> return 1;
> rsalz> }
>
> This is in dtls1_read_failed(), which doesn't seem to be used anywhere...

Matt: It *is* used. It's called from the record layer. Actually this function
should probably be *in* the record layer since its only used from there.

The instance above is a "should never happen" scenario. We should probably just
log it as an internal error and remove the fprintf.
Probably the return code should be 0 not 1.

>
> rsalz> &found) <= 0 && found) {
> rsalz> fprintf(stderr, "dtls1_retransmit_message() failed\n");
> rsalz> return -1;
> rsalz> }

Matt: This could actually occur. But I think the correct thing to do is just
ignore the error, i.e. delete the fprintf altogether (and continue to return
-1).

>
> rsalz> if (item == NULL) {
> rsalz> fprintf(stderr, "retransmit: message %d non-existant\n", seq);
> rsalz> *found = 0;
> rsalz> return 0;
> rsalz> }
>

Matt: This one is another "should never happen". Log it as an internal error
and remove the fprintf.


From rt at openssl.org  Fri Jun  5 05:01:03 2015
From: rt at openssl.org (nick@mozilla.com via RT)
Date: Fri, 05 Jun 2015 05:01:03 +0000
Subject: [openssl-dev] [openssl.org #3896] unable to install to openssldir
In-Reply-To: <5570D131.4070808@mozilla.com>
References: <RT-Ticket-3896@openssl.org> <5570D131.4070808@mozilla.com>
Message-ID: <rt-4.0.19-18362-1433480463-316.3896-21-0@openssl.org>

Hi all, I'm trying to build openssl-1.0.2a as a static lib out of 
source.  I'm on OSX 10.10.3.  Here's what I'm trying:

curl -O https://www.openssl.org/source/openssl-1.0.2a.tar.gz
tar xvfz openssl-1.0.2a.tar.gz
cd openssl-1.0.2a
mkdir build
./Configure darwin64-x86_64-cc no-ssl2 no-ssl3 no-idea no-shared no-npn 
no-psk no-srp --openssldir=./build
make depend
make
make install_sw

`make install_sw` fails with:

...
making install in crypto...
cp: build/include/openssl/crypto.h: No such file or directory
chmod: build/include/openssl/crypto.h: No such file or directory
cp: build/include/openssl/opensslv.h: No such file or directory
chmod: build/include/openssl/opensslv.h: No such file or directory
cp: build/include/openssl/opensslconf.h: No such file or directory
chmod: build/include/openssl/opensslconf.h: No such file or directory
cp: build/include/openssl/ebcdic.h: No such file or directory
chmod: build/include/openssl/ebcdic.h: No such file or directory
cp: build/include/openssl/symhacks.h: No such file or directory
chmod: build/include/openssl/symhacks.h: No such file or directory
cp: build/include/openssl/ossl_typ.h: No such file or directory
chmod: build/include/openssl/ossl_typ.h: No such file or directory
make[1]: *** [install] Error 1
make: *** [install_sw] Error 1

when I ran `make depend` I saw lots of what looked like lots of errors 
printed out:

making depend in crypto...
makedepend: warning:  cannot open "x86_64"
makedepend: warning:  cryptlib.c (reading ../include/openssl/bio.h, line 
67): cannot find include file "stdarg.h"
   not in ./stdarg.h
   not in ../stdarg.h
   not in ../include/stdarg.h
   not in /usr/include/stdarg.h
...

I'm sure I'm doing something wrong, but what?

-- 
Thanks,
~Nick Desaulniers
Open Source Zealot
Mozilla Corporation

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From beldmit at gmail.com  Fri Jun  5 08:14:34 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 5 Jun 2015 11:14:34 +0300
Subject: [openssl-dev] [openssl.org #3895] fprintf in ssl library
In-Reply-To: <rt-4.0.19-18362-1433457385-1313.3895-21-0@openssl.org>
References: <RT-Ticket-3895@openssl.org>
 <rt-4.0.19-18362-1433457385-1313.3895-21-0@openssl.org>
Message-ID: <CADqLbzJ+9JM-t8aJ-wcD1cLt8mcCJRpzFPuH+zEua6oSg1BdHw@mail.gmail.com>

Dear Rich,

Here are some clarifications regarding GOST.

On Fri, Jun 5, 2015 at 1:36 AM, Rich Salz via RT <rt at openssl.org> wrote:

> Summarizing some email from the team-internal thread.
>
>
> > rsalz> In s3_srvr.c:
> > rsalz> if (i != 64) {
> > rsalz> fprintf(stderr, "GOST signature length is %d", i);
> > rsalz> }
> >
> > This looks weird to me. The code following this seems to assume a 64
> > byte signature, BUT the comment around line 2916 suggests that a GOST
> > signature can have other lengths as well. That suggests that this
> > fprintf() is a debugging print... However, it does look to me like
> > we're still only handling 64-byte long GOST signatures, so something
> > isn't quite complete.
> > ... and I need to read up on GOST.
>

Yes, it seems to exist here for mostly debugging purposes from the ancient
time. And it is rather weird.

Both GOST 94 (deprecated) and GOST 2001 signature algorithms have 64-byte
signatures, but GOST 2012 (implemented in a separate patch) has both 64
bytes and 128 bytes variants.

BTW, we are interested in providing the GOST 2012 support for openssl and
have a comprehensive patch implementing it.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150605/d1a9fc4b/attachment-0001.html>

From rt at openssl.org  Fri Jun  5 08:14:46 2015
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Fri, 05 Jun 2015 08:14:46 +0000
Subject: [openssl-dev] [openssl.org #3895] fprintf in ssl library
In-Reply-To: <CADqLbzJ+9JM-t8aJ-wcD1cLt8mcCJRpzFPuH+zEua6oSg1BdHw@mail.gmail.com>
References: <RT-Ticket-3895@openssl.org>
 <rt-4.0.19-18362-1433457385-1313.3895-21-0@openssl.org>
 <CADqLbzJ+9JM-t8aJ-wcD1cLt8mcCJRpzFPuH+zEua6oSg1BdHw@mail.gmail.com>
Message-ID: <rt-4.0.19-6285-1433492086-593.3895-6-0@openssl.org>

Dear Rich,

Here are some clarifications regarding GOST.

On Fri, Jun 5, 2015 at 1:36 AM, Rich Salz via RT <rt at openssl.org> wrote:

> Summarizing some email from the team-internal thread.
>
>
> > rsalz> In s3_srvr.c:
> > rsalz> if (i != 64) {
> > rsalz> fprintf(stderr, "GOST signature length is %d", i);
> > rsalz> }
> >
> > This looks weird to me. The code following this seems to assume a 64
> > byte signature, BUT the comment around line 2916 suggests that a GOST
> > signature can have other lengths as well. That suggests that this
> > fprintf() is a debugging print... However, it does look to me like
> > we're still only handling 64-byte long GOST signatures, so something
> > isn't quite complete.
> > ... and I need to read up on GOST.
>

Yes, it seems to exist here for mostly debugging purposes from the ancient
time. And it is rather weird.

Both GOST 94 (deprecated) and GOST 2001 signature algorithms have 64-byte
signatures, but GOST 2012 (implemented in a separate patch) has both 64
bytes and 128 bytes variants.

BTW, we are interested in providing the GOST 2012 support for openssl and
have a comprehensive patch implementing it.

Thank you!

-- 
SY, Dmitry Belyavsky


From rt at openssl.org  Fri Jun  5 11:23:42 2015
From: rt at openssl.org (Hidalgo Eguiagaray, Rafael via RT)
Date: Fri, 05 Jun 2015 11:23:42 +0000
Subject: [openssl-dev] [openssl.org #3864] OS390 Bug: Make fails
In-Reply-To: <A9162E604233B146B0146C132184818509697F174C@MADARRMAILBOX01.indra.es>
References: <RT-Ticket-3864@openssl.org>
 <A9162E604233B146B0146C1321848185026F7506A0@MADARRMAILBOX01.indra.es>
 <rt-4.0.4-21768-1433091566-391.3864-6-0@openssl.org>
 <A9162E604233B146B0146C132184818509697F174C@MADARRMAILBOX01.indra.es>
Message-ID: <rt-4.0.19-18362-1433503422-1434.3864-6-0@openssl.org>

That is what I would like to know.
make clean gives the same error, in the same place.
I am sort of newbie to this and can?t find out where to touch nor how to find out.

It  seems make , when
@[ -n "$(THIS)" ] && $(CLEARENV) && $(MAKE) $(THIS) -e $(BUILDENV)

 decides  $(BUILD_CMD) expands Doubling the parms in error.

The previous assignment is:

>>> Makefile: line 0: Defined macro INCDEPTH=0
>>> Makefile: line 7: Defined macro VERSION=1.0.2a
>>> Makefile: line 8: Defined macro MAJOR=1
>>> Makefile: line 9: Defined macro MINOR=0.2
>>> Makefile: line 10: Defined macro SHLIB_VERSION_NUMBER=1.0.0
>>> Makefile: line 11: Defined macro SHLIB_VERSION_HISTORY=
>>> Makefile: line 12: Defined macro SHLIB_MAJOR=1
>>> Makefile: line 13: Defined macro SHLIB_MINOR=0.0
>>> Makefile: line 14: Defined macro SHLIB_EXT=
>>> Makefile: line 15: Defined macro PLATFORM=OS390-Unix
>>> Makefile: line 16: Defined macro OPTIONS=-zlib no-ec_nistp_64_gcc_128 no-gmp no-jpake no-krb5 no-libunbound no-md2 no-rc5 no-rfc3779 no-sctp no-shared no-ssl-trace no-store no-unit-test no-zlib no-zlib-dynamic static-engine
>>> Makefile: line 17: Defined macro CONFIGURE_ARGS=OS390-Unix -no-krb5 -zlib
>>> Makefile: line 18: Defined macro SHLIB_TARGET=
>>> Makefile: line 23: Defined macro HERE=.
>>> Makefile: line 28: Defined macro INSTALL_PREFIX=
>>> Makefile: line 29: Defined macro INSTALLTOP=/usr/local/ssl
>>> Makefile: line 32: Defined macro OPENSSLDIR=/usr/local/ssl
>>> Makefile: line 62: Defined macro CC=c89.sh
>>> Makefile: line 63: Defined macro CFLAG=-zlib -O -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H  -D_ALL_SOURCE
>>> Makefile: line 64: Defined macro DEPFLAG=-DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST
>>> Makefile: line 65: Defined macro PEX_LIBS=
>>> Makefile: line 66: Defined macro EX_LIBS=
>>> Makefile: line 67: Defined macro EXE_EXT=
>>> Makefile: line 68: Defined macro ARFLAGS=
>>> Makefile: line 69: Defined macro AR=ar $(ARFLAGS) r
>>> Makefile: line 70: Defined macro RANLIB=true
>>> Makefile: line 71: Defined macro NM=nm
>>> Makefile: line 72: Defined macro PERL=/usr/local/perl-5.16.2/bin/perl
>>> Makefile: line 73: Defined macro TAR=tar
>>> Makefile: line 74: Defined macro TARFLAGS=--no-recursion
>>> Makefile: line 75: Defined macro MAKEDEPPROG=makedepend
>>> Makefile: line 76: Defined macro LIBDIR=lib
>>> Makefile: line 83: Defined macro AS=$(CC) -c
>>> Makefile: line 84: Defined macro ASFLAG=$(CFLAG)
>>> Makefile: line 88: Defined macro PROCESSOR=
>>> Makefile: line 91: Defined macro CPUID_OBJ=mem_clr.o
>>> Makefile: line 92: Defined macro BN_ASM=bn_asm.o
>>> Makefile: line 93: Defined macro EC_ASM=
>>> Makefile: line 94: Defined macro DES_ENC=des_enc.o fcrypt_b.o
>>> Makefile: line 95: Defined macro AES_ENC=aes_core.o aes_cbc.o
>>> Makefile: line 96: Defined macro BF_ENC=bf_enc.o
>>> Makefile: line 97: Defined macro CAST_ENC=c_enc.o
>>> Makefile: line 98: Defined macro RC4_ENC=rc4_enc.o rc4_skey.o
>>> Makefile: line 99: Defined macro RC5_ENC=rc5_enc.o
>>> Makefile: line 100: Defined macro MD5_ASM_OBJ=
>>> Makefile: line 101: Defined macro SHA1_ASM_OBJ=
>>> Makefile: line 102: Defined macro RMD160_ASM_OBJ=
>>> Makefile: line 103: Defined macro WP_ASM_OBJ=wp_block.o
>>> Makefile: line 104: Defined macro CMLL_ENC=camellia.o cmll_misc.o cmll_cbc.o
>>> Makefile: line 105: Defined macro MODES_ASM_OBJ=
>>> Makefile: line 106: Defined macro ENGINES_ASM_OBJ=
>>> Makefile: line 107: Defined macro PERLASM_SCHEME=
>>> Makefile: line 110: Defined macro KRB5_INCLUDES=
>>> Makefile: line 111: Defined macro LIBKRB5=
>>> Makefile: line 114: Defined macro ZLIB_INCLUDE=
>>> Makefile: line 115: Defined macro LIBZLIB=
>>> Makefile: line 118: Defined macro FIPSDIR=/usr/local/ssl/fips-2.0
>>> Makefile: line 127: Defined macro FIPSLIBDIR=
>>> Makefile: line 134: Defined macro FIPSCANLIB=
>>> Makefile: line 139: Defined macro BASEADDR=0xFB00000
>>> Makefile: line 141: Defined macro DIRS=crypto ssl engines apps test tools
>>> Makefile: line 142: Defined macro ENGDIRS=ccgost
>>> Makefile: line 143: Defined macro SHLIBDIRS=crypto ssl
>>> Makefile: line 153: Defined macro SDIRS=objects  md4 md5 sha mdc2 hmac ripemd whrlpool  des aes rc2 rc4 idea bf cast camellia seed modes  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio stack lhash rand err  evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp ui krb5  cms pqueue ts srp cmac
>>> Makefile: line 159: Defined macro TESTS=alltests
>>> Makefile: line 161: Defined macro MAKEFILE=Makefile
>>> Makefile: line 163: Defined macro MANDIR=$(OPENSSLDIR)/man
>>> Makefile: line 164: Defined macro MAN1=1
>>> Makefile: line 165: Defined macro MAN3=3
>>> Makefile: line 166: Defined macro MANSUFFIX=
>>> Makefile: line 167: Defined macro HTMLSUFFIX=html
>>> Makefile: line 168: Defined macro HTMLDIR=$(OPENSSLDIR)/html
>>> Makefile: line 169: Defined macro SHELL=/bin/sh
>>> Makefile: line 171: Defined macro TOP=.
>>> Makefile: line 172: Defined macro ONEDIRS=out tmp
>>> Makefile: line 173: Defined macro EDIRS=times doc bugs util include certs ms shlib mt demos perl sf dep VMS
>>> Makefile: line 174: Defined macro WDIRS=windows
>>> Makefile: line 175: Defined macro LIBS=libcrypto.a libssl.a
>>> Makefile: line 176: Defined macro SHARED_CRYPTO=libcrypto$(SHLIB_EXT)
>>> Makefile: line 177: Defined macro SHARED_SSL=libssl$(SHLIB_EXT)
>>> Makefile: line 178: Defined macro SHARED_LIBS=
>>> Makefile: line 179: Defined macro SHARED_LIBS_LINK_EXTS=
>>> Makefile: line 180: Defined macro SHARED_LDFLAGS=
>>> Makefile: line 182: Defined macro GENERAL=Makefile
>>> Makefile: line 183: Defined macro BASENAME=openssl
>>> Makefile: line 184: Defined macro NAME=$(BASENAME)-$(VERSION)
>>> Makefile: line 185: Defined macro TARFILE=$(NAME).tar
>>> Makefile: line 186: Defined macro WTARFILE=$(NAME)-win.tar
>>> Makefile: line 187: Defined macro EXHEADER=e_os2.h
>>> Makefile: line 188: Defined macro HEADER=e_os.h




-----Mensaje original-----
De: Richard Levitte via RT [mailto:rt at openssl.org]
Enviado el: domingo, 31 de mayo de 2015 18:59
Para: Hidalgo Eguiagaray, Rafael
CC: openssl-dev at openssl.org
Asunto: [openssl.org #3864] OS390 Bug: Make fails

It's unclear to me what needs to change. Would you mind helping us figure it out?

On Tue May 26 20:06:21 2015, rhidalgo at indra.es wrote:
> Make Output (tail ):
>
> >>> Makefile: line 206: Defined macro CLEARENV=TOP= && unset TOP
> $${LIB+LIB} $${LIBS+LIBS} $${INCLUDE+INCLUDE} $${INCLUDES+INCLUDES}
> $${DIR+DIR} $${DIRS+DIRS} $${SRC+SRC} $${LIBSRC+LIBSRC}
> $${LIBOBJ+LIBOBJ} $${ALL+ALL} $${EXHEADER+EXHEADER} $${HEADER+HEADER}
> $${GENERAL+GENERAL} $${CFLAGS+CFLAGS} $${ASFLAGS+ASFLAGS}
> $${AFLAGS+AFLAGS} $${LDCMD+LDCMD} $${LDFLAGS+LDFLAGS}
> $${SCRIPTS+SCRIPTS} $${SHAREDCMD+SHAREDCMD}
> $${SHAREDFLAGS+SHAREDFLAGS} $${SHARED_LIB+SHARED_LIB}
> $${LIBEXTRAS+LIBEXTRAS}
> >>> Makefile: line 242: Defined macro BUILDENV=PLATFORM='$(PLATFORM)'
> PROCESSOR='$(PROCESSOR)' CC='$(CC)' CFLAG='$(CFLAG)'
> AS='$(CC)' ASFLAG='$(CFLAG) -c' AR='$(AR)'
> NM='$(NM)' RANLIB='$(RANLIB)'
> CROSS_COMPILE='$(CROSS_COMPILE)' PERL='$(PERL)'
> ENGDIRS='$(ENGDIRS)' SDIRS='$(SDIRS)'
> LIBRPATH='$(INSTALLTOP)/$(LIBDIR)'
> INSTALL_PREFIX='$(INSTALL_PREFIX)'
> INSTALLTOP='$(INSTALLTOP)' OPENSSLDIR='$(OPENSSLDIR)'
> LIBDIR='$(LIBDIR)'
> MAKEDEPEND='$$$${TOP}/util/domd $$$${TOP} -MD $(MAKEDEPPROG)'
> DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)'
> MAKEDEPPROG='$(MAKEDEPPROG)'
> SHARED_LDFLAGS='$(SHARED_LDFLAGS)'
> KRB5_INCLUDES='$(KRB5_INCLUDES)' LIBKRB5='$(LIBKRB5)'
> ZLIB_INCLUDE='$(ZLIB_INCLUDE)' LIBZLIB='$(LIBZLIB)'
> EXE_EXT='$(EXE_EXT)' SHARED_LIBS='$(SHARED_LIBS)'
> SHLIB_EXT='$(SHLIB_EXT)' SHLIB_TARGET='$(SHLIB_TARGET)'
> PEX_LIBS='$(PEX_LIBS)' EX_LIBS='$(EX_LIBS)'
> CPUID_OBJ='$(CPUID_OBJ)' BN_ASM='$(BN_ASM)' EC_ASM='$(EC_ASM)'
> DES_ENC='$(DES_ENC)' AES_ENC='$(AES_ENC)'
> CMLL_ENC='$(CMLL_ENC)' BF_ENC='$(BF_ENC)' CAST_ENC='$(CAST_ENC)'
> RC4_ENC='$(RC4_ENC)' RC5_ENC='$(RC5_ENC)'
> SHA1_ASM_OBJ='$(SHA1_ASM_OBJ)'
> MD5_ASM_OBJ='$(MD5_ASM_OBJ)'
> RMD160_ASM_OBJ='$(RMD160_ASM_OBJ)'
> WP_ASM_OBJ='$(WP_ASM_OBJ)'
> MODES_ASM_OBJ='$(MODES_ASM_OBJ)'
> ENGINES_ASM_OBJ='$(ENGINES_ASM_OBJ)'
> PERLASM_SCHEME='$(PERLASM_SCHEME)'
> FIPSLIBDIR='${FIPSLIBDIR}'
> FIPSDIR='${FIPSDIR}' FIPSCANLIB="$${FIPSCANLIB:-$(FIPSCANLIB)}"
> THIS=$${THIS:-$@} MAKEFILE=Makefile MAKEOVERRIDES=
> >>> Makefile: line 264: Defined macro BUILD_CMD=if [ -d "$$dir" ];
> then ( cd $$dir && echo "making $$target in $$dir..." &&
> $(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target )
> || exit 1; fi
> >>> Makefile: line 266: Defined macro RECURSIVE_BUILD_CMD=for dir in
> $(DIRS); do $(BUILD_CMD); done
> >>> Makefile: line 267: Defined macro BUILD_ONE_CMD=if expr " $(DIRS)
> " : ".* $$dir " >/dev/null 2>&1; then $(BUILD_CMD); fi
> make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [&&] in
> target list
> make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [&&] in
> target list
> make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-O] in
> target list
> make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-
> DB_ENDIAN] in target list
> make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-
> DCHARSET_EBCDIC] in target list
> make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-
> DNO_SYS_PARAM_H] in target list
> >>> Defined macro INCDEPTH=0
> make: Error -- FSUM8229 Incomplete rule recipe group detected
>
> Operating System : OS3090-Unix == zOS 1.13
>
> Open SSL 1.02a, from openssl-1.0.2a.tar untared with : pax -rf
> openssl-1.0.2a.tar -ofrom=ISO8859-1,to=IBM-1047
>
>
> ________________________________
> Este correo electr?nico y, en su caso, cualquier fichero anexo al
> mismo, contiene informaci?n de car?cter confidencial exclusivamente
> dirigida a su destinatario o destinatarios. Si no es vd. el
> destinatario indicado, queda notificado que la lectura, utilizaci?n,
> divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la
> legislaci?n vigente. En el caso de haber recibido este correo
> electr?nico por error, se ruega notificar inmediatamente esta
> circunstancia mediante reenv?o a la direcci?n electr?nica del
> remitente.
> Evite imprimir este mensaje si no es estrictamente necesario.
>
> This email and any file attached to it (when applicable) contain(s)
> confidential information that is exclusively addressed to its
> recipient(s). If you are not the indicated recipient, you are informed
> that reading, using, disseminating and/or copying it without
> authorisation is forbidden in accordance with the legislation in
> effect. If you have received this email by mistake, please immediately
> notify the sender of the situation by resending it to their email
> address.
> Avoid printing this message if it is not absolutely necessary.


--
Richard Levitte
levitte at openssl.org


Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address.
Avoid printing this message if it is not absolutely necessary.


From rt at openssl.org  Fri Jun  5 16:39:36 2015
From: rt at openssl.org (Zooko Wilcox-OHearn via RT)
Date: Fri, 05 Jun 2015 16:39:36 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function
	(let's kill md5sum!)
In-Reply-To: <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
Message-ID: <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>

Dear OpenSSL folks:

I'm one of the authors of the BLAKE2 hash function
(https://blake2.net). I've been working with the maintainers of GNU
coreutils to make a tool named "b2sum", which I hope will eventually
replace md5sum.

md5sum is the most widely-used tool in the world for data integrity
but, as you know, MD5 is weak in ways that could endanger the users of
md5sum, depending on how they use it. I want to see md5sum phased out
entirely in our lifetimes!

BLAKE2 is a secure hash function, while being faster than MD5 (at
least on 64-bit CPUs). BLAKE2 is being used in new software projects
(https://blake2.net/#us) and there is recently an Internet Draft to
specify it (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).

One of the coreutils maintainers suggested that we should ask OpenSSL
to add BLAKE2, because coreutils itself will probably just use a
portable C implementation, but it would use an optimized
implementation if openssl provided it. Here's that thread:
http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html

We, the BLAKE2 maintainers, offer both reference C code and optimized
implementations: https://blake2.net/#dl . There are also other
implementations with various virtues available: https://blake2.net/#sw

Here's my blog post extolling the virtues of BLAKE2 as a
high-performance hash function:

https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

Regards,

Zooko

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Fri Jun  5 21:27:17 2015
From: rt at openssl.org (Jonathan Larmour via RT)
Date: Fri, 05 Jun 2015 21:27:17 +0000
Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add
	IPv4/IPv6:port-based client cache
In-Reply-To: <557212C3.4050907@eCosCentric.com>
References: <RT-Ticket-3883@openssl.org>
 <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com>
 <rt-4.0.4-5720-1432972092-1373.3883-21-0@openssl.org>
 <20150531060603.GX2342@mournblade.imrryr.org>
 <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.4-19811-1433078843-1044.3883-6-0@openssl.org>
 <F818FABD-FA03-4581-9DEC-AFC130763362@akamai.com>
 <rt-4.0.4-31106-1433168518-1655.3883-6-0@openssl.org>
 <557212C3.4050907@eCosCentric.com>
Message-ID: <rt-4.0.19-24771-1433539637-862.3883-6-0@openssl.org>

On 01/06/15 15:22, Short, Todd via RT wrote:
> Re: copyrights:
> 
> Planning to copy the (109-line) main copyright from another source file and append to it:
> 
> /* ====================================================================
>  * Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
>  * This code was originally developed by Akamai Technologies and
>  * and contributed to the OpenSSL project.
>  */
> 
> Acceptable?

Just a little thing I noticed, but your text has "and and" (separated by a
newline).

Jifl



From rt at openssl.org  Fri Jun  5 21:32:38 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Fri, 05 Jun 2015 21:32:38 +0000
Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add
	IPv4/IPv6:port-based client cache
In-Reply-To: <ADE20152-B653-47AC-BE51-F322D2A6BA23@akamai.com>
References: <RT-Ticket-3883@openssl.org>
 <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com>
 <rt-4.0.4-5720-1432972092-1373.3883-21-0@openssl.org>
 <20150531060603.GX2342@mournblade.imrryr.org>
 <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.4-19811-1433078843-1044.3883-6-0@openssl.org>
 <F818FABD-FA03-4581-9DEC-AFC130763362@akamai.com>
 <rt-4.0.4-31106-1433168518-1655.3883-6-0@openssl.org>
 <557212C3.4050907@eCosCentric.com>,
 <rt-4.0.19-24771-1433539637-862.3883-6-0@openssl.org>
 <ADE20152-B653-47AC-BE51-F322D2A6BA23@akamai.com>
Message-ID: <rt-4.0.19-24771-1433539958-1037.3883-6-0@openssl.org>

Yup, we noticed that too. 

--
-Todd Short
// tshort at akamai.com
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


> On Jun 5, 2015, at 5:27 PM, Jonathan Larmour via RT <rt at openssl.org> wrote:
> 
>> On 01/06/15 15:22, Short, Todd via RT wrote:
>> Re: copyrights:
>> 
>> Planning to copy the (109-line) main copyright from another source file and append to it:
>> 
>> /* ====================================================================
>> * Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
>> * This code was originally developed by Akamai Technologies and
>> * and contributed to the OpenSSL project.
>> */
>> 
>> Acceptable?
> 
> Just a little thing I noticed, but your text has "and and" (separated by a
> newline).
> 
> Jifl
> 
> 



From kurt at roeckx.be  Sat Jun  6 01:48:55 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 6 Jun 2015 03:48:55 +0200
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
 EVP_PKEY_get_type (new function)
In-Reply-To: <CAH8yC8m_ZKSo4_wUfNd8s_w5JbW0Wpkd2Ba0yTH4HZkopyQDjw@mail.gmail.com>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
 <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
 <20150604190941.GA8688@roeckx.be>
 <rt-4.0.19-6285-1433444990-1381.3894-6-0@openssl.org>
 <CAH8yC8m_ZKSo4_wUfNd8s_w5JbW0Wpkd2Ba0yTH4HZkopyQDjw@mail.gmail.com>
Message-ID: <20150606014855.GA1214@roeckx.be>

On Thu, Jun 04, 2015 at 04:52:22PM -0400, Jeffrey Walton wrote:
> Thanks Kurt. I think I'll need to think about this some more because I
> don't recall EVP_PKEY_id.
> 
> I think I never considered it because I could not find it when
> searching for something to return the inner type ('id' does not make a
> lot of sense to me, even now).
> 
> Maybe I should back up a bit. What is 'id' supposed to do above and
> beyond providing the 'type'?
> 
> *****
> 
> > I don't know if there are plans to run the EVP_PKEY into a opaque
> > struct soon, but it probably should.
> 
> That's fine as long as we have an accessor to ensure we are working
> with what we expect. Otherwise, we can't validate which means we can't
> use the value.
> 
> *****
> 
> > This doesn't make sense.  You're discouraging the function you
> > add?  Maybe you mean EVP_PKEY_type(pkey->type)?
> 
> Yeah, you're kind of right. On one hand, its lower level and its use
> is discouraged (see the NOTES in evp,h). On the other hand, we need it
> for use.
> 
> *****
> 
> According to the man pages for EVP_PKEY_type:
> 
>        EVP_PKEY_type() returns the type of key corresponding to the value
>        type. The type of a key can be obtained with EVP_PKEY_type(pkey->type).
> 
> Reading the man pages, it appears there's no accessor for
> `pkey->type`. Otherwise, we would have been told to use `EVP_PKEY_id`.
> 
> *****
> 
> > This seems to do almost exactly the same as EVP_PKEY_base_id().
> 
> Actually, I think its closer to EVP_PKEY_id().
> 
> Also, we have a NULL pointer dereference in the existing function:
> 
>     int EVP_PKEY_id(const EVP_PKEY *pkey)
>     {
>         return pkey->type;
>     }
> 
> (Sorry, I did not recall seeing that function).

I think you're getting confused.  There is:
int EVP_PKEY_id(const EVP_PKEY *pkey)
{
    return pkey->type;
}

int EVP_PKEY_base_id(const EVP_PKEY *pkey)
{
    return EVP_PKEY_type(pkey->type);
}


And you had:
int EVP_PKEY_get_type(EVP_PKEY *pkey)
{
    if (!pkey)
        return EVP_PKEY_NONE;

    return EVP_PKEY_type(pkey->type);
}


Kurt


From rt at openssl.org  Sat Jun  6 01:49:22 2015
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Sat, 06 Jun 2015 01:49:22 +0000
Subject: [openssl-dev] [openssl.org #3894] AutoReply: PATCH:
	EVP_PKEY_get_type (new function)
In-Reply-To: <20150606014855.GA1214@roeckx.be>
References: <RT-Ticket-3894@openssl.org>
 <CAH8yC8nuNdNPCJfEJ1bXN+_tw0UsjSvgY4aZ009VvJd_Hj_Z6w@mail.gmail.com>
 <rt-4.0.19-6285-1433358057-742.3894-3-0@openssl.org>
 <CAH8yC8n42kTHAXKx3t9cqDt0U=duN6-U70qkkbkLOObzy0swRQ@mail.gmail.com>
 <rt-4.0.19-6285-1433364625-1687.3894-6-0@openssl.org>
 <20150604190941.GA8688@roeckx.be>
 <rt-4.0.19-6285-1433444990-1381.3894-6-0@openssl.org>
 <CAH8yC8m_ZKSo4_wUfNd8s_w5JbW0Wpkd2Ba0yTH4HZkopyQDjw@mail.gmail.com>
 <20150606014855.GA1214@roeckx.be>
Message-ID: <rt-4.0.19-25072-1433555362-1077.3894-6-0@openssl.org>

On Thu, Jun 04, 2015 at 04:52:22PM -0400, Jeffrey Walton wrote:
> Thanks Kurt. I think I'll need to think about this some more because I
> don't recall EVP_PKEY_id.
> 
> I think I never considered it because I could not find it when
> searching for something to return the inner type ('id' does not make a
> lot of sense to me, even now).
> 
> Maybe I should back up a bit. What is 'id' supposed to do above and
> beyond providing the 'type'?
> 
> *****
> 
> > I don't know if there are plans to run the EVP_PKEY into a opaque
> > struct soon, but it probably should.
> 
> That's fine as long as we have an accessor to ensure we are working
> with what we expect. Otherwise, we can't validate which means we can't
> use the value.
> 
> *****
> 
> > This doesn't make sense.  You're discouraging the function you
> > add?  Maybe you mean EVP_PKEY_type(pkey->type)?
> 
> Yeah, you're kind of right. On one hand, its lower level and its use
> is discouraged (see the NOTES in evp,h). On the other hand, we need it
> for use.
> 
> *****
> 
> According to the man pages for EVP_PKEY_type:
> 
>        EVP_PKEY_type() returns the type of key corresponding to the value
>        type. The type of a key can be obtained with EVP_PKEY_type(pkey->type).
> 
> Reading the man pages, it appears there's no accessor for
> `pkey->type`. Otherwise, we would have been told to use `EVP_PKEY_id`.
> 
> *****
> 
> > This seems to do almost exactly the same as EVP_PKEY_base_id().
> 
> Actually, I think its closer to EVP_PKEY_id().
> 
> Also, we have a NULL pointer dereference in the existing function:
> 
>     int EVP_PKEY_id(const EVP_PKEY *pkey)
>     {
>         return pkey->type;
>     }
> 
> (Sorry, I did not recall seeing that function).

I think you're getting confused.  There is:
int EVP_PKEY_id(const EVP_PKEY *pkey)
{
    return pkey->type;
}

int EVP_PKEY_base_id(const EVP_PKEY *pkey)
{
    return EVP_PKEY_type(pkey->type);
}


And you had:
int EVP_PKEY_get_type(EVP_PKEY *pkey)
{
    if (!pkey)
        return EVP_PKEY_NONE;

    return EVP_PKEY_type(pkey->type);
}


Kurt



From veredz72 at gmail.com  Sat Jun  6 21:17:06 2015
From: veredz72 at gmail.com (Zvi Vered)
Date: Sun, 7 Jun 2015 00:17:06 +0300
Subject: [openssl-dev] ssl_sess.c : compilation error
Message-ID: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>

Dear Members,

In the file openssl-1.0.1g\ssl\ssl_sess.c contains the following code:

int (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx))(SSL *ssl, SSL_SESSION *sess)
    {
    return ctx->new_session_cb;
    }

The return value of this routine is a ?pointer to function?.
But the code : 

ctx->new_session_cb

uses a parameter of the return value. How this is possible ?

I?m trying to compile this code using diab compiler for vxworks6.3 and 
I have a syntax error.

Using this compiler for vxWorks 6.9 (newer compiler) gives no syntax 
error.

Is there another way to write this code ?

Best regards,
Z.V


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150607/77cdf9ab/attachment.html>

From kurt at roeckx.be  Sat Jun  6 21:51:28 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 6 Jun 2015 23:51:28 +0200
Subject: [openssl-dev] ssl_sess.c : compilation error
In-Reply-To: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>
References: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>
Message-ID: <20150606215128.GA14200@roeckx.be>

On Sun, Jun 07, 2015 at 12:17:06AM +0300, Zvi Vered wrote:
> Dear Members,
> 
> In the file openssl-1.0.1g\ssl\ssl_sess.c contains the following code:
> 
> int (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx))(SSL *ssl, SSL_SESSION *sess)
>     {
>     return ctx->new_session_cb;
>     }
> 
> The return value of this routine is a "pointer to function".
> But the code : 
> 
> ctx->new_session_cb
> 
> uses a parameter of the return value. How this is possible ?

The function without return type is:
SSL_CTX_sess_get_new_cb(SSL_CTX *ctx)

The return value is a function that looks like:
int new_session_cb(struct ssl_st *ssl, SSL_SESSION *sess)

I hope that explains it.

> I'm trying to compile this code using diab compiler for vxworks6.3 and 
> I have a syntax error.
> 
> Using this compiler for vxWorks 6.9 (newer compiler) gives no syntax 
> error.
> 
> Is there another way to write this code ?

You can make typedefs that might make it easier for you to
understand it, but I would hope that makes no differences for a
compiler.

You could also try to just remove that function in case you don't
need it in your application.


Kurt


From rt at openssl.org  Sun Jun  7 01:22:41 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Sun, 07 Jun 2015 01:22:41 +0000
Subject: [openssl-dev] [openssl.org #3899] PATCH: Update to
	EVP_BytesToKey.pod documentation
In-Reply-To: <CAH8yC8mYogMXwRdW9Y57gUBB--zQQiebV6hx9z0Ti0tXrarEDQ@mail.gmail.com>
References: <RT-Ticket-3899@openssl.org>
 <CAH8yC8mYogMXwRdW9Y57gUBB--zQQiebV6hx9z0Ti0tXrarEDQ@mail.gmail.com>
Message-ID: <rt-4.0.19-28135-1433640160-856.3899-21-0@openssl.org>

Another small issue revealed on Stack Overflow: "Utilizing PBKDF2 with
OpenSSL library," http://stackoverflow.com/q/22795471.

In the question the OP cited the man page for EVP_BytesToKey. He knew
he needed to use PBKDF2 from the man page, but the man page did not
explicit call out OpenSSL's function to do so. So he did not know whet
he was supposed to use.

This patch updates the recommendation by explicitly calling out
PKCS5_PBKDF2_HMAC.

*****

diff --git a/doc/crypto/EVP_BytesToKey.pod b/doc/crypto/EVP_BytesToKey.pod
index e6df57d..dca5239 100644
--- a/doc/crypto/EVP_BytesToKey.pod
+++ b/doc/crypto/EVP_BytesToKey.pod
@@ -36,8 +36,8 @@ If the total key and IV length is less than the
digest length and
 B<MD5> is used then the derivation algorithm is compatible with PKCS#5 v1.5
 otherwise a non standard extension is used to derive the extra data.

-Newer applications should use more standard algorithms such as PBKDF2 as
-defined in PKCS#5v2.1 for key derivation.
+Newer applications should use a more modern algorithm such as PBKDF2 as
+defined in PKCS#5v2.1 and provided by PKCS5_PBKDF2_HMAC.

 =head1 KEY DERIVATION ALGORITHM

-------------- next part --------------
diff --git a/doc/crypto/EVP_BytesToKey.pod b/doc/crypto/EVP_BytesToKey.pod
index e6df57d..dca5239 100644
--- a/doc/crypto/EVP_BytesToKey.pod
+++ b/doc/crypto/EVP_BytesToKey.pod
@@ -36,8 +36,8 @@ If the total key and IV length is less than the digest length and
 B<MD5> is used then the derivation algorithm is compatible with PKCS#5 v1.5
 otherwise a non standard extension is used to derive the extra data.
 
-Newer applications should use more standard algorithms such as PBKDF2 as
-defined in PKCS#5v2.1 for key derivation.
+Newer applications should use a more modern algorithm such as PBKDF2 as
+defined in PKCS#5v2.1 and provided by PKCS5_PBKDF2_HMAC.
 
 =head1 KEY DERIVATION ALGORITHM
 
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From veredz72 at gmail.com  Sun Jun  7 18:36:20 2015
From: veredz72 at gmail.com (Zvi Vered)
Date: Sun, 7 Jun 2015 21:36:20 +0300
Subject: [openssl-dev] ssl_sess.c : compilation error
In-Reply-To: <20150606215128.GA14200@roeckx.be>
References: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>
 <20150606215128.GA14200@roeckx.be>
Message-ID: <69BF357489854FBC8E96B7F0C77BF03B@ZviVeredPC>

Hi Kurt,

I think I have a C problem.

I do not understand how the compiler enable to use the pointer ctx.
ctx is not declared in the routine parameters nor in the routine body.

What is the purpose of:
int (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx))(SSL *ssl, SSL_SESSION *sess)
    {
     return ctx->new_session_cb;
     }

Is it part of the ssl infrastructure or for external user who links with ssl 
library ?

Best reagrds,
Zvika

-----Original Message----- 
From: Kurt Roeckx
Sent: Sunday, June 07, 2015 12:51 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] ssl_sess.c : compilation error

On Sun, Jun 07, 2015 at 12:17:06AM +0300, Zvi Vered wrote:
> Dear Members,
>
> In the file openssl-1.0.1g\ssl\ssl_sess.c contains the following code:
>
> int (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx))(SSL *ssl, SSL_SESSION *sess)
>     {
>     return ctx->new_session_cb;
>     }
>
> The return value of this routine is a "pointer to function".
> But the code :
>
> ctx->new_session_cb
>
> uses a parameter of the return value. How this is possible ?

The function without return type is:
SSL_CTX_sess_get_new_cb(SSL_CTX *ctx)

The return value is a function that looks like:
int new_session_cb(struct ssl_st *ssl, SSL_SESSION *sess)

I hope that explains it.

> I'm trying to compile this code using diab compiler for vxworks6.3 and
> I have a syntax error.
>
> Using this compiler for vxWorks 6.9 (newer compiler) gives no syntax
> error.
>
> Is there another way to write this code ?

You can make typedefs that might make it easier for you to
understand it, but I would hope that makes no differences for a
compiler.

You could also try to just remove that function in case you don't
need it in your application.


Kurt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 


From kurt at roeckx.be  Sun Jun  7 20:16:24 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 7 Jun 2015 22:16:24 +0200
Subject: [openssl-dev] ssl_sess.c : compilation error
In-Reply-To: <69BF357489854FBC8E96B7F0C77BF03B@ZviVeredPC>
References: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>
 <20150606215128.GA14200@roeckx.be>
 <69BF357489854FBC8E96B7F0C77BF03B@ZviVeredPC>
Message-ID: <20150607201624.GA3441@roeckx.be>

On Sun, Jun 07, 2015 at 09:36:20PM +0300, Zvi Vered wrote:
> Hi Kurt,
> 
> I think I have a C problem.
> 
> I do not understand how the compiler enable to use the pointer ctx.
> ctx is not declared in the routine parameters nor in the routine body.

As I already explained, ctx *is* the only parameter to the
function.

Rewriting that code with a typedef could look like:
typedef int (*session_cb_type)(SSL *ssl, SSL_SESSION *sess);
session_cb_type SSL_CTX_sess_get_new_cb(SSL_CTX *ctx)
{
        return ctx->new_session_cb;
}

That does exactly the same thing.

> What is the purpose of:
> int (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx))(SSL *ssl, SSL_SESSION *sess)
>    {
>     return ctx->new_session_cb;
>     }
> 
> Is it part of the ssl infrastructure or for external user who links with ssl
> library ?

You can set a callback on the creation of a new session.  See the
SSL_CTX_sess_set_new_cb() manpage.  The SSL_CTX_sess_get_new_cb()
get function returns that callback function back.

There are no internal users in OpenSSL as far as I can see.  There
might be code using OpenSSL that uses it, but I don't think that's
very likely.


Kurt


From rt at openssl.org  Mon Jun  8 10:37:45 2015
From: rt at openssl.org (Hubert Kario via RT)
Date: Mon, 08 Jun 2015 10:37:45 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <1635649.MzKP0c4us7@pintsize.usersys.redhat.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <1635649.MzKP0c4us7@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.19-5412-1433759865-1167.3897-6-0@openssl.org>

On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote:
> Dear OpenSSL folks:
> 
> I'm one of the authors of the BLAKE2 hash function
> (https://blake2.net). I've been working with the maintainers of GNU
> coreutils to make a tool named "b2sum", which I hope will eventually
> replace md5sum.
> 
> md5sum is the most widely-used tool in the world for data integrity
> but, as you know, MD5 is weak in ways that could endanger the users of
> md5sum, depending on how they use it. I want to see md5sum phased out
> entirely in our lifetimes!
> 
> BLAKE2 is a secure hash function, while being faster than MD5 (at
> least on 64-bit CPUs). BLAKE2 is being used in new software projects
> (https://blake2.net/#us) and there is recently an Internet Draft to
> specify it
> (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).
> 
> One of the coreutils maintainers suggested that we should ask OpenSSL
> to add BLAKE2, because coreutils itself will probably just use a
> portable C implementation, but it would use an optimized
> implementation if openssl provided it. Here's that thread:
> http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html
> 
> We, the BLAKE2 maintainers, offer both reference C code and optimized
> implementations: https://blake2.net/#dl . There are also other
> implementations with various virtues available: https://blake2.net/#sw
> 
> Here's my blog post extolling the virtues of BLAKE2 as a
> high-performance hash function:
> 
> https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD
> 5.html
> 

how resistant is it against side channel attacks?

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150608/3f0b7f57/attachment-0001.sig>

From ynir.ietf at gmail.com  Mon Jun  8 11:05:00 2015
From: ynir.ietf at gmail.com (Yoav Nir)
Date: Mon, 8 Jun 2015 14:05:00 +0300
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-5412-1433759865-1167.3897-6-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <1635649.MzKP0c4us7@pintsize.usersys.redhat.com>
 <rt-4.0.19-5412-1433759865-1167.3897-6-0@openssl.org>
Message-ID: <D59591C0-D1BB-4C57-97AB-C04B88C918E0@gmail.com>


> On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT <rt at openssl.org> wrote:
> 
> On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote:
>> Dear OpenSSL folks:
>> 
>> I'm one of the authors of the BLAKE2 hash function
>> (https://blake2.net). I've been working with the maintainers of GNU
>> coreutils to make a tool named "b2sum", which I hope will eventually
>> replace md5sum.
>> 
>> md5sum is the most widely-used tool in the world for data integrity
>> but, as you know, MD5 is weak in ways that could endanger the users of
>> md5sum, depending on how they use it. I want to see md5sum phased out
>> entirely in our lifetimes!
>> 
>> BLAKE2 is a secure hash function, while being faster than MD5 (at
>> least on 64-bit CPUs). BLAKE2 is being used in new software projects
>> (https://blake2.net/#us) and there is recently an Internet Draft to
>> specify it
>> (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).
>> 
>> One of the coreutils maintainers suggested that we should ask OpenSSL
>> to add BLAKE2, because coreutils itself will probably just use a
>> portable C implementation, but it would use an optimized
>> implementation if openssl provided it. Here's that thread:
>> http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html
>> 
>> We, the BLAKE2 maintainers, offer both reference C code and optimized
>> implementations: https://blake2.net/#dl . There are also other
>> implementations with various virtues available: https://blake2.net/#sw
>> 
>> Here's my blog post extolling the virtues of BLAKE2 as a
>> high-performance hash function:
>> 
>> https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD
>> 5.html
>> 
> 
> how resistant is it against side channel attacks?

Since it?s based on ChaCha, it?s very resistant to timing (and power) based side channel leakage.

Yoav


From rt at openssl.org  Mon Jun  8 11:05:24 2015
From: rt at openssl.org (Yoav Nir via RT)
Date: Mon, 08 Jun 2015 11:05:24 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <D59591C0-D1BB-4C57-97AB-C04B88C918E0@gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <1635649.MzKP0c4us7@pintsize.usersys.redhat.com>
 <rt-4.0.19-5412-1433759865-1167.3897-6-0@openssl.org>
 <D59591C0-D1BB-4C57-97AB-C04B88C918E0@gmail.com>
Message-ID: <rt-4.0.19-1776-1433761524-1624.3897-6-0@openssl.org>


> On Jun 8, 2015, at 1:37 PM, Hubert Kario via RT <rt at openssl.org> wrote:
> 
> On Friday 05 June 2015 16:39:36 Zooko Wilcox-OHearn via RT wrote:
>> Dear OpenSSL folks:
>> 
>> I'm one of the authors of the BLAKE2 hash function
>> (https://blake2.net). I've been working with the maintainers of GNU
>> coreutils to make a tool named "b2sum", which I hope will eventually
>> replace md5sum.
>> 
>> md5sum is the most widely-used tool in the world for data integrity
>> but, as you know, MD5 is weak in ways that could endanger the users of
>> md5sum, depending on how they use it. I want to see md5sum phased out
>> entirely in our lifetimes!
>> 
>> BLAKE2 is a secure hash function, while being faster than MD5 (at
>> least on 64-bit CPUs). BLAKE2 is being used in new software projects
>> (https://blake2.net/#us) and there is recently an Internet Draft to
>> specify it
>> (https://datatracker.ietf.org/doc/draft-saarinen-blake2/?include_text=1).
>> 
>> One of the coreutils maintainers suggested that we should ask OpenSSL
>> to add BLAKE2, because coreutils itself will probably just use a
>> portable C implementation, but it would use an optimized
>> implementation if openssl provided it. Here's that thread:
>> http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html
>> 
>> We, the BLAKE2 maintainers, offer both reference C code and optimized
>> implementations: https://blake2.net/#dl . There are also other
>> implementations with various virtues available: https://blake2.net/#sw
>> 
>> Here's my blog post extolling the virtues of BLAKE2 as a
>> high-performance hash function:
>> 
>> https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD
>> 5.html
>> 
> 
> how resistant is it against side channel attacks?

Since it?s based on ChaCha, it?s very resistant to timing (and power) based side channel leakage.

Yoav



From foleyj at cisco.com  Mon Jun  8 12:27:40 2015
From: foleyj at cisco.com (John Foley)
Date: Mon, 08 Jun 2015 08:27:40 -0400
Subject: [openssl-dev] FreeBSD build broken?
Message-ID: <55758A3C.1020904@cisco.com>

Is anyone having problems building 1.0.2-stable on FreeBSD?  It appears
the following commit may have broken the build:

https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc

Here's the error we're seeing:

[jenkins at freebird ~/tmp/openssl-OpenSSL_1_0_2-stable]$ gmake depend
making depend in crypto...
gmake[1]: Entering directory
'/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto'
../util/domd: makedepend: not found
mv: Makefile.new: No such file or directory
Makefile:136: recipe for target 'local_depend' failed
gmake[1]: *** [local_depend] Error 127
gmake[1]: Leaving directory
'/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto'
Makefile:466: recipe for target 'depend' failed
gmake: *** [depend] Error 1


From waywardgeek at google.com  Mon Jun  8 13:44:56 2015
From: waywardgeek at google.com (Bill Cox)
Date: Mon, 8 Jun 2015 06:44:56 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-1776-1433761524-1624.3897-6-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <1635649.MzKP0c4us7@pintsize.usersys.redhat.com>
 <rt-4.0.19-5412-1433759865-1167.3897-6-0@openssl.org>
 <D59591C0-D1BB-4C57-97AB-C04B88C918E0@gmail.com>
 <rt-4.0.19-1776-1433761524-1624.3897-6-0@openssl.org>
Message-ID: <CAH9QtQG6_hR4PfzDXa_-uM7=MDfuJ9vuwCBCiMT6W9jrpnN9yw@mail.gmail.com>

Not that my opinion here counts, but I'll second the call for BLAKE2
support.  The SIMD implementation is one of the finest works of efficient
cryptographic code I've run across.  It's so efficient, it became by far
the most popular hash function in the Password Hashing Competition.  BLAKE2
rocks.  It leaves SHA256 in the dust.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150608/647fed7e/attachment.html>

From rt at openssl.org  Mon Jun  8 13:45:08 2015
From: rt at openssl.org (Bill Cox via RT)
Date: Mon, 08 Jun 2015 13:45:08 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAH9QtQG6_hR4PfzDXa_-uM7=MDfuJ9vuwCBCiMT6W9jrpnN9yw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <1635649.MzKP0c4us7@pintsize.usersys.redhat.com>
 <rt-4.0.19-5412-1433759865-1167.3897-6-0@openssl.org>
 <D59591C0-D1BB-4C57-97AB-C04B88C918E0@gmail.com>
 <rt-4.0.19-1776-1433761524-1624.3897-6-0@openssl.org>
 <CAH9QtQG6_hR4PfzDXa_-uM7=MDfuJ9vuwCBCiMT6W9jrpnN9yw@mail.gmail.com>
Message-ID: <rt-4.0.19-1776-1433771108-585.3897-6-0@openssl.org>

Not that my opinion here counts, but I'll second the call for BLAKE2
support.  The SIMD implementation is one of the finest works of efficient
cryptographic code I've run across.  It's so efficient, it became by far
the most popular hash function in the Password Hashing Competition.  BLAKE2
rocks.  It leaves SHA256 in the dust.

Bill


From ben at links.org  Mon Jun  8 15:08:22 2015
From: ben at links.org (Ben Laurie)
Date: Mon, 8 Jun 2015 16:08:22 +0100
Subject: [openssl-dev] FreeBSD build broken?
In-Reply-To: <55758A3C.1020904@cisco.com>
References: <55758A3C.1020904@cisco.com>
Message-ID: <CAG5KPzyorX_O00r7ddvp8d16Qjse_hSvQiP8KBzFr7WMb9BfgA@mail.gmail.com>

On 8 June 2015 at 13:27, John Foley <foleyj at cisco.com> wrote:

> Is anyone having problems building 1.0.2-stable on FreeBSD?  It appears
> the following commit may have broken the build:
>
>
> https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc
>
> Here's the error we're seeing:
>
> [jenkins at freebird ~/tmp/openssl-OpenSSL_1_0_2-stable]$ gmake depend
> making depend in crypto...
> gmake[1]: Entering directory
> '/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto'
> ../util/domd: makedepend: not found
> mv: Makefile.new: No such file or directory
> Makefile:136: recipe for target 'local_depend' failed
> gmake[1]: *** [local_depend] Error 127
> gmake[1]: Leaving directory
> '/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto'
> Makefile:466: recipe for target 'depend' failed
> gmake: *** [depend] Error 1
>

makedepend is provided by the port devel/makedepend.


>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150608/950f4b73/attachment.html>

From kurt at roeckx.be  Mon Jun  8 17:11:15 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 8 Jun 2015 19:11:15 +0200
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
Message-ID: <20150608171115.GA26759@roeckx.be>

On Fri, Jun 05, 2015 at 04:39:36PM +0000, Zooko Wilcox-OHearn via RT wrote:
> 
> One of the coreutils maintainers suggested that we should ask OpenSSL
> to add BLAKE2, because coreutils itself will probably just use a
> portable C implementation, but it would use an optimized
> implementation if openssl provided it. Here's that thread:
> http://lists.gnu.org/archive/html/coreutils/2015-06/msg00011.html

So which "blake2" are we talking about?  I understand that there
are many variations.

Anyway, I think we should add it.


Kurt


From matt at openssl.org  Mon Jun  8 19:32:47 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 08 Jun 2015 20:32:47 +0100
Subject: [openssl-dev] Forthcoming OpenSSL releases
Message-ID: <5575EDDF.1070009@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2b, 1.0.1n, 1.0.0s and 0.9.8zg.

These releases will be made available on Thursday 11th June. They will
fix a number of security defects. The highest severity defect fixed by
these releases is classified as "moderate" severity (see
https://www.openssl.org/about/secpolicy.html).

Yours

The OpenSSL Project Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVde3fAAoJENnE0m0OYESRIokH+QFLMvyyCxztRQGRm54oxOGA
WugDkHsonM6meJp8TPqjnSrvk5xmKT1FFL+9lZ/7V/Y/ImhjSkxAp1j3mbA3Drw0
UoDEO59hA2ZuKtLMIIgSRH+BTUIO0wHuVDURiVRBkj0A1shlI21uoRcJFNoAuGMQ
9wymbc5lIkN3OEUYKh5QW/izmdTFEYeNBDSndTO0kg5koymRTf68gCEtQ5sh3zFB
Hnmx3rEsEr8NbWxrvHly2rPLcy8TluIe/uiIG3FBF/acyW/4KWFqvf994eCQYenw
JG57Hv64TZa7dTmmjBNZgkrN8wM89SEW3pLCRmqkbBfQ12IByJC8dYNR8ieOp9g=
=eGiv
-----END PGP SIGNATURE-----

From waywardgeek at google.com  Mon Jun  8 21:26:06 2015
From: waywardgeek at google.com (Bill Cox)
Date: Mon, 8 Jun 2015 14:26:06 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <20150608171115.GA26759@roeckx.be>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
Message-ID: <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>

On Mon, Jun 8, 2015 at 10:11 AM, Kurt Roeckx <kurt at roeckx.be> wrote:

> So which "blake2" are we talking about?  I understand that there
> are many variations.
>
> Anyway, I think we should add it.
>
>
> Kurt


Blake2s is 256-bit, while Blake2d is 512-bit.  These are the ones I assume
that would be best for addition.  The other two, Blake2sp and Blake2bp are
multi-threaded, and are optimized for multi-core CPUs.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150608/b527dfaa/attachment.html>

From rsalz at akamai.com  Mon Jun  8 23:10:32 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 8 Jun 2015 23:10:32 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <20150608171115.GA26759@roeckx.be>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
Message-ID: <88faded305244a8fa61a2125c1a291a6@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Anyway, I think we should add it.

I am in favor of doing that, too.  But there's some work that needs to be done:  hooking it up to the EVP API, and tweaking the assembler stuff to use our perl-based structure, right?

From rt at openssl.org  Mon Jun  8 23:32:55 2015
From: rt at openssl.org (Salz, Rich via RT)
Date: Mon, 08 Jun 2015 23:32:55 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>

>Blake2s is 256-bit, while Blake2d is 512-bit.? These are the ones I assume that would be best for addition.? The other two, Blake2sp and Blake2bp are multi-threaded, and are optimized for multi-core CPUs.

It is unfortunate that 's' and 'd' mean different algorithms, while 2sp and 2bp are, presumably, alternative versions of 2s and 2d, respectively.  Nobody outside the implementation should know about that second class of difference.  And note that one of the longer OpenSSL members, who is very experienced in implementations of crypto, was confused.

And is it really 2d and 2bp?  Or is one of those [db] letters a typo?  Either way, I think it makes a case for changing the names.

It is pretty common to use the size as a suffix.  I would really like to see blake2-256 and blake2-512 as the common names.  And the implementation names, as I said, need never be seen outside of, well, the implementation. :)


From rt at openssl.org  Mon Jun  8 23:47:10 2015
From: rt at openssl.org (bittwister2@gmail.com via RT)
Date: Mon, 08 Jun 2015 23:47:10 +0000
Subject: [openssl-dev] [openssl.org #3900] openssl returns success on bad
	arguments
In-Reply-To: <20150608140858.6A8A11C344A@wb.home.test>
References: <RT-Ticket-3900@openssl.org>
 <20150608140858.6A8A11C344A@wb.home.test>
Message-ID: <rt-4.0.19-7129-1433807230-328.3900-21-0@openssl.org>


$ openssl version -a
OpenSSL 1.0.2a 19 Mar 2015
built on: reproducible build, date unspecified
platform: linux-x86_64
options:  bn(64,64) rc4(8x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -fPIC -Wa,--noexecstack -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/etc/pki/tls"
engines:  dynamic

$ cat /etc/product.id
vendor=Mageia.Org,distribution=Mageia,type=Basic,version=5,branch=Official,release=5,arch=x86_64,product=Default

$ get_src_rpm openssl

      Installed rpm : openssl-1.0.2a-1.mga5
      Source rpm    : openssl-1.0.2a-1.mga5.src.rpm
      Information   : http://www.openssl.org/


Problem: openssl returns success code on bad arguments

Steps to Reproduce:

openssl -cert no.way xx yy
echo $?

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Tue Jun  9 00:09:24 2015
From: rt at openssl.org (Zooko Wilcox-OHearn via RT)
Date: Tue, 09 Jun 2015 00:09:24 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
Message-ID: <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>

Dear Rich Salz et al.:

"b" is for "big" ? fits well with 64-bit architectures, and "s" is for
"small" ? fits well with 32-bit architectures.

"p" is for "parallel" ? has several parallel threads that each compute
the hash of a different subset of the input data, and then those
hashes get hashed together to result in the final output. Therefore it
isn't just an internal implementation different ? blake2sp generates
different hash values than blake2s does, and blake2b and blake2bp are
all different ? each of the four would produce a  different value.

In practice the parallel mode works nicely on modern systems. Hashing
a 1 GiB file on my Intel Core i5 laptop:

md5: 2.1s
sha256: 5.7s
blake2b: 1.8s
blake2sp: 1.1s

(from https://mail.google.com/mail/u/0/#label/coreutils/14d96872a0e9d1b3 )

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com ? Freedom matters.



From rt at openssl.org  Tue Jun  9 00:15:35 2015
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 09 Jun 2015 00:15:35 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>

So it's really a request to add four hash functions.  Bummer.

> In practice the parallel mode works nicely on modern systems.

Well, on clients.  On servers, presumably, those cores would be busy ;)

I'd support adding 2b and 2s, in spite of the fact that the names are really really bad.  I'm less interested in seeing the parallel variants added.  FWIW.


From rt at openssl.org  Tue Jun  9 00:17:38 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 09 Jun 2015 00:17:38 +0000
Subject: [openssl-dev] [openssl.org #3900] openssl returns success on bad
	arguments
In-Reply-To: <20150608140858.6A8A11C344A@wb.home.test>
References: <RT-Ticket-3900@openssl.org>
 <20150608140858.6A8A11C344A@wb.home.test>
Message-ID: <rt-4.0.19-5412-1433809058-1272.3900-6-0@openssl.org>

Fixed in 1.1:
prompt$ ./openssl -cert no.way xx yy ; echo $?
Invalid command '-cert'; type "help" for a list.
1
prompt$
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From zooko at leastauthority.com  Tue Jun  9 00:18:36 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Tue, 9 Jun 2015 00:18:36 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
Message-ID: <CAM_a8Jw0f68Qd=Znvyzj--Xz5wdsE=y9vPks9MA04Z1F287sfg@mail.gmail.com>

(re-sent because I wasn't subscribed to openssl-dev first time and it
bounced from there but went through to rt at .)


Dear Rich Salz et al.:

"b" is for "big" ? fits well with 64-bit architectures, and "s" is for
"small" ? fits well with 32-bit architectures.

"p" is for "parallel" ? has several parallel threads that each compute
the hash of a different subset of the input data, and then those
hashes get hashed together to result in the final output. Therefore it
isn't just an internal implementation different ? blake2sp generates
different hash values than blake2s does, and blake2b and blake2bp are
all different ? each of the four would produce a  different value.

In practice the parallel mode works nicely on modern systems. Hashing
a 1 GiB file on my Intel Core i5 laptop:

md5: 2.1s
sha256: 5.7s
blake2b: 1.8s
blake2sp: 1.1s

(from https://mail.google.com/mail/u/0/#label/coreutils/14d96872a0e9d1b3 )

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com ? Freedom matters.

From rt at openssl.org  Tue Jun  9 00:18:51 2015
From: rt at openssl.org (Zooko Wilcox-OHearn via RT)
Date: Tue, 09 Jun 2015 00:18:51 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAM_a8Jw0f68Qd=Znvyzj--Xz5wdsE=y9vPks9MA04Z1F287sfg@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8Jw0f68Qd=Znvyzj--Xz5wdsE=y9vPks9MA04Z1F287sfg@mail.gmail.com>
Message-ID: <rt-4.0.19-7129-1433809131-482.3897-6-0@openssl.org>

(re-sent because I wasn't subscribed to openssl-dev first time and it
bounced from there but went through to rt at .)


Dear Rich Salz et al.:

"b" is for "big" ? fits well with 64-bit architectures, and "s" is for
"small" ? fits well with 32-bit architectures.

"p" is for "parallel" ? has several parallel threads that each compute
the hash of a different subset of the input data, and then those
hashes get hashed together to result in the final output. Therefore it
isn't just an internal implementation different ? blake2sp generates
different hash values than blake2s does, and blake2b and blake2bp are
all different ? each of the four would produce a  different value.

In practice the parallel mode works nicely on modern systems. Hashing
a 1 GiB file on my Intel Core i5 laptop:

md5: 2.1s
sha256: 5.7s
blake2b: 1.8s
blake2sp: 1.1s

(from https://mail.google.com/mail/u/0/#label/coreutils/14d96872a0e9d1b3 )

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com ? Freedom matters.



From zooko at leastauthority.com  Tue Jun  9 00:19:56 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Tue, 9 Jun 2015 00:19:56 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
Message-ID: <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>

> I'd support adding 2b and 2s, in spite of the fact that the names are really really bad.  I'm less interested in seeing the parallel variants added.  FWIW.

Well, the reason I'm here is that the GNU coreutils maintainers rely
on openssl for high-performance crypto, and blake2sp might be the best
algorithm for the new "b2sum" tool, which I hope will replace "md5sum"
in the toolboxes of system administrators everywhere.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com ? Freedom matters.

From rt at openssl.org  Tue Jun  9 00:20:29 2015
From: rt at openssl.org (Zooko Wilcox-OHearn via RT)
Date: Tue, 09 Jun 2015 00:20:29 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
Message-ID: <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>

> I'd support adding 2b and 2s, in spite of the fact that the names are really really bad.  I'm less interested in seeing the parallel variants added.  FWIW.

Well, the reason I'm here is that the GNU coreutils maintainers rely
on openssl for high-performance crypto, and blake2sp might be the best
algorithm for the new "b2sum" tool, which I hope will replace "md5sum"
in the toolboxes of system administrators everywhere.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com ? Freedom matters.



From rsalz at akamai.com  Tue Jun  9 00:34:21 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jun 2015 00:34:21 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2
	hash	function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
Message-ID: <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Well, the reason I'm here is that the GNU coreutils maintainers rely on
> openssl for high-performance crypto, and blake2sp might be the best
> algorithm for the new "b2sum" tool, which I hope will replace "md5sum"
> in the toolboxes of system administrators everywhere.

Yes, I went and read the thread over there.  I think this is an interesting and worthwhile discussion to have, but I took "rt" off the list as I'm not sure the ticket-tracking system is the best place for that :)

If the goal is replace md5sum, then one thing to think about is which digest will have the widest reach for everyone?  Can all four versions be implemented in (mostly?) portable C code?  Is performance the only real difference?  Suppose we took just blake2s?

From zooko at leastauthority.com  Tue Jun  9 00:54:55 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Tue, 9 Jun 2015 00:54:55 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>

> If the goal is replace md5sum, then one thing to think about is which digest will have the widest reach for everyone?  Can all four versions be implemented in (mostly?) portable C code?  Is performance the only real difference?  Suppose we took just blake2s?

All four are available in mostly-portable C code, as well as in
various optimized versions: https://blake2.net/#dl and
https://blake2.net/#sw .

The differences are:

1. The b's are more efficient on 64-bit architectures, the s's are
more efficient on 32-bit architectures. Search for "blake2b" and
"blake2s" in http://bench.cr.yp.to/results-hash.html .

   For example on an Intel x86-64 Xeon E3-1275 V3
(http://bench.cr.yp.to/results-hash.html#amd64-titan0), blake2b costs
3.09 cpb and blake2s costs 5.35 cpb.

   On the other hand on an NVIDIA ARM Tegra 250
(http://bench.cr.yp.to/results-hash.html#armeabi-h2tegra), blake2b
costs 37.43 cpb and blake2s costs 13.49 cpb.

   (I looked at the worst-case quartile for 4096-byte inputs for those
measurements.)

2. The b's can emit up to 512 bits of output, the s's can emit up to
256 bits of output.

3. The 'p' versions use more cores and finish faster.

Interestingly, on my 64-bit, 4-CPU Intel Core i5 system (a Google
Chromebook Pixel 1) blake2sp is slightly faster than blake2bp. This
might be because with hyperthreading I have effectively 8 (?)
efficient threads. blake2sp is 8-way while blake2bp is 4-way. Or maybe
it is for some other reason.

Regards,

Zooko

From rsalz at akamai.com  Tue Jun  9 00:57:26 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jun 2015 00:57:26 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
Message-ID: <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>

So if you're going to replace md5sum... which one should you use?  Which ONE HASH should replace MD5?

Or why not just use sha256 and sha512.

From zooko at leastauthority.com  Tue Jun  9 01:07:31 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Tue, 9 Jun 2015 01:07:31 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>

On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich <rsalz at akamai.com> wrote:
> So if you're going to replace md5sum... which one should you use?  Which ONE HASH should replace MD5?

I'd suggest blake2sp. It's currently the fastest on my machine, and I
guess that there will often be multiple cores in systems where hash
performance matters (i.e. hashing large files or many files).

But, if for some reason blake2sp is problematic, then any of the other
BLAKE2 variants would also work.

> Or why not just use sha256 and sha512.

It seems like we can get people to migrate off of MD5 by offering them
better performance *and* improved security, but not by offering them
worse performance and improved security.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com ? Freedom matters.

From waywardgeek at google.com  Tue Jun  9 01:17:04 2015
From: waywardgeek at google.com (Bill Cox)
Date: Mon, 8 Jun 2015 18:17:04 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAH9QtQEi-kb7VLzX3uDzR1J4Fbath4JnuG7N+=-YrLKawkLBrw@mail.gmail.com>

As a SHA256 upgrade, I think Blake2s.  As a SHA512 upgrade, Blake2b.  The
parallel versions are interesting, but maybe harder to justify.  Maybe add
a generic parallel wrapper algorithm for hashing?  Does it have to be
specific to the hash code?
On Jun 8, 2015 5:58 PM, "Salz, Rich" <rsalz at akamai.com> wrote:

> So if you're going to replace md5sum... which one should you use?  Which
> ONE HASH should replace MD5?
>
> Or why not just use sha256 and sha512.
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150608/51435a5c/attachment-0001.html>

From waywardgeek at google.com  Tue Jun  9 01:32:55 2015
From: waywardgeek at google.com (Bill Cox)
Date: Mon, 8 Jun 2015 18:32:55 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <88faded305244a8fa61a2125c1a291a6@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <88faded305244a8fa61a2125c1a291a6@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAH9QtQFGBeGTujR5t72vWD3tU0TcHjeW9A=X5c2SC49Xn8P8=w@mail.gmail.com>

I could be wrong, but I did not see any assembler. SIMD is done with
standard Intel macros.

Hooking up looks simple to me. So you need a volunteer? I've been poking
around the code lately.
On Jun 8, 2015 4:11 PM, "Salz, Rich" <rsalz at akamai.com> wrote:

>
> > Anyway, I think we should add it.
>
> I am in favor of doing that, too.  But there's some work that needs to be
> done:  hooking it up to the EVP API, and tweaking the assembler stuff to
> use our perl-based structure, right?
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150608/e72126f1/attachment.html>

From dkg at fifthhorseman.net  Tue Jun  9 03:09:43 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 08 Jun 2015 23:09:43 -0400
Subject: [openssl-dev] ssl_sess.c : compilation error
In-Reply-To: <20150607201624.GA3441@roeckx.be>
References: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>
 <20150606215128.GA14200@roeckx.be>
 <69BF357489854FBC8E96B7F0C77BF03B@ZviVeredPC>
 <20150607201624.GA3441@roeckx.be>
Message-ID: <873821shl4.fsf@alice.fifthhorseman.net>

On Sun 2015-06-07 16:16:24 -0400, Kurt Roeckx wrote:
> You can set a callback on the creation of a new session.  See the
> SSL_CTX_sess_set_new_cb() manpage.  The SSL_CTX_sess_get_new_cb()
> get function returns that callback function back.
>
> There are no internal users in OpenSSL as far as I can see.  There
> might be code using OpenSSL that uses it, but I don't think that's
> very likely.

The only mentions of SSL_CTX_sess_get_new_cb are packages that bundle or
replicate OpenSSL code:

  https://codesearch.debian.net/results/SSL_CTX_sess_get_new_cb

SSL_CTX_sess_set_new_cb, otoh, is widely used (ruby, apache, courier, etc):

  https://codesearch.debian.net/results/SSL_CTX_sess_set_new_cb

Debian's archive, of course, is not all free software.  But it's a
pretty wide sampling of a lot of useful free software.

        --dkg

From naynjain at in.ibm.com  Tue Jun  9 04:21:52 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Tue, 9 Jun 2015 09:51:52 +0530
Subject: [openssl-dev] Is there openssl API to verify certificate content is
	DER or PEM format ?
Message-ID: <OF04312994.4A822603-ON65257E5F.0017A49C-65257E5F.0017F964@in.ibm.com>


Hi,

I need to verify if the certifiate I have received is having its content in
PEM/DER format.

Is there any API which if given file pointer like (fp) will tell me whether
it has valid format of certificate and if yes then whether it is PEM/DER
format ?

If no API, then what is the other way to verify this ?

Thanks & Regards,
Nayna Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/ce39189b/attachment.html>

From ynir.ietf at gmail.com  Tue Jun  9 05:02:21 2015
From: ynir.ietf at gmail.com (Yoav Nir)
Date: Tue, 9 Jun 2015 08:02:21 +0300
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
Message-ID: <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>


> On Jun 9, 2015, at 4:07 AM, Zooko Wilcox-OHearn <zooko at leastauthority.com> wrote:
> 
> On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich <rsalz at akamai.com> wrote:
>> So if you're going to replace md5sum... which one should you use?  Which ONE HASH should replace MD5?
> 
> I'd suggest blake2sp. It's currently the fastest on my machine, and I
> guess that there will often be multiple cores in systems where hash
> performance matters (i.e. hashing large files or many files).

As a replacement for md5sum (like it says in the title) - I agree.

If we also want blake for protocols (like TLS_RSA_WITH_AES_128_GCM_BLAKE or something), the non-parallel versions would be more suitable.

Yoav


From dhirajbhor21 at gmail.com  Tue Jun  9 05:08:57 2015
From: dhirajbhor21 at gmail.com (Dhiraj Bhor)
Date: Tue, 9 Jun 2015 10:38:57 +0530
Subject: [openssl-dev] Simple program to print openssl library version
Message-ID: <CAMqKDv5aXcKwQuba+y0+C36LTsU8KZcLQePO6XxFcUxORqRLrQ@mail.gmail.com>

Hi,

I am writing an application which will configure, make and copy libssl.so
to custom location. Since tester does not know which version of openssl he
is testing, i wanted to know that is there any api which will be used
through C code to print openssl full version string.
NOTE: i have only libssl.so, libcrypto.so with me while running the
application.

Thanks,
dhiraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/cfe55611/attachment.html>

From matt at openssl.org  Tue Jun  9 07:12:18 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 09 Jun 2015 08:12:18 +0100
Subject: [openssl-dev] Simple program to print openssl library version
In-Reply-To: <CAMqKDv5aXcKwQuba+y0+C36LTsU8KZcLQePO6XxFcUxORqRLrQ@mail.gmail.com>
References: <CAMqKDv5aXcKwQuba+y0+C36LTsU8KZcLQePO6XxFcUxORqRLrQ@mail.gmail.com>
Message-ID: <557691D2.203@openssl.org>



On 09/06/15 06:08, Dhiraj Bhor wrote:
> Hi,
> 
> I am writing an application which will configure, make and copy
> libssl.so to custom location. Since tester does not know which version
> of openssl he is testing, i wanted to know that is there any api which
> will be used through C code to print openssl full version string.
> NOTE: i have only libssl.so, libcrypto.so with me while running the
> application.

See:

https://www.openssl.org/docs/crypto/OPENSSL_VERSION_NUMBER.html

You can also use the values defined in opensslv.h

Note: For future reference, openssl-users would be a better list for API
usage questions.

Matt


From dhirajbhor21 at gmail.com  Tue Jun  9 08:33:19 2015
From: dhirajbhor21 at gmail.com (Dhiraj Bhor)
Date: Tue, 9 Jun 2015 14:03:19 +0530
Subject: [openssl-dev] Simple program to print openssl library version
In-Reply-To: <557691D2.203@openssl.org>
References: <CAMqKDv5aXcKwQuba+y0+C36LTsU8KZcLQePO6XxFcUxORqRLrQ@mail.gmail.com>
 <557691D2.203@openssl.org>
Message-ID: <CAMqKDv4OjjmYxrKwyKm4zS61T4k_uLpMJujQA_s6KZ+jiQGpwg@mail.gmail.com>

Thanks.
And yes i will keep in mind about openssl-users mailing list.

dhiraj

On Tue, Jun 9, 2015 at 12:42 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 09/06/15 06:08, Dhiraj Bhor wrote:
> > Hi,
> >
> > I am writing an application which will configure, make and copy
> > libssl.so to custom location. Since tester does not know which version
> > of openssl he is testing, i wanted to know that is there any api which
> > will be used through C code to print openssl full version string.
> > NOTE: i have only libssl.so, libcrypto.so with me while running the
> > application.
>
> See:
>
> https://www.openssl.org/docs/crypto/OPENSSL_VERSION_NUMBER.html
>
> You can also use the values defined in opensslv.h
>
> Note: For future reference, openssl-users would be a better list for API
> usage questions.
>
> Matt
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/17df8e57/attachment.html>

From rsalz at akamai.com  Tue Jun  9 13:51:14 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jun 2015 13:51:14 +0000
Subject: [openssl-dev] ssl_sess.c : compilation error
In-Reply-To: <873821shl4.fsf@alice.fifthhorseman.net>
References: <CFA21A8494F04437AC7D33C156CBEFBF@ZviVeredPC>
 <20150606215128.GA14200@roeckx.be>
 <69BF357489854FBC8E96B7F0C77BF03B@ZviVeredPC>
 <20150607201624.GA3441@roeckx.be> <873821shl4.fsf@alice.fifthhorseman.net>
Message-ID: <b957361052664f6aa776d438a3ca9937@ustx2ex-dag1mb2.msg.corp.akamai.com>


> The only mentions of SSL_CTX_sess_get_new_cb are packages that bundle
> or replicate OpenSSL code:

It's not surprising; code that sets the callback should first get and store the old callback so that they can explicitly chain them.  But that's not well-explained, fragile with dynamic libraries that can unload, and... well... not really needed.  When is more than one callback ever set?

:) 

From waywardgeek at google.com  Tue Jun  9 16:33:51 2015
From: waywardgeek at google.com (Bill Cox)
Date: Tue, 9 Jun 2015 09:33:51 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
Message-ID: <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>

On Mon, Jun 8, 2015 at 10:02 PM, Yoav Nir <ynir.ietf at gmail.com> wrote:

>
> > On Jun 9, 2015, at 4:07 AM, Zooko Wilcox-OHearn <
> zooko at leastauthority.com> wrote:
> >
> > On Tue, Jun 9, 2015 at 12:57 AM, Salz, Rich <rsalz at akamai.com> wrote:
> >> So if you're going to replace md5sum... which one should you use?
> Which ONE HASH should replace MD5?
> >
> > I'd suggest blake2sp. It's currently the fastest on my machine, and I
> > guess that there will often be multiple cores in systems where hash
> > performance matters (i.e. hashing large files or many files).
>
> As a replacement for md5sum (like it says in the title) - I agree.
>
> If we also want blake for protocols (like TLS_RSA_WITH_AES_128_GCM_BLAKE
> or something), the non-parallel versions would be more suitable.
>
> Yoav


Zooko only asked for supporting Blake2 as an MD5 replacement, but he's
being too modest.  I can't stress enough how important the speed of Blake2
is.  Even at it's default of 12 rounds (6 is probably perfectly secure from
what I've heard), it stomps every other hash function.  This will make a
big difference for the future of crypto, making it more usable and
accessible in the real world.  I personally will only use SHA256/SHA512 in
the future when speed is absolutely a non-issue.  Blake2 is simply better.

Here's my dumb thoughts about why OpenSSL should support more modern hashes
like Blake2, rather than keeping things simple by relying on older crypto.

OpenSSL has become the crypto platform of choice for crypto algorithms.
For example, in considering how to rewrite TrueCrypt, replacing its custom
crypto with OpenSSL is a no brainer.  OpenSSL has more options, better
timing attack resistance, faster implementations, more real-world testing,
etc.  The Password Hashing Competition's call for submissions said,
"OpenSSL's libcrypto may be used (e.g. for AES, SHA-256)."  If you wanted
to include any crypto not in OpenSSL, you were required to submit the
source code.  OpenSSL is where crypto algorithms go to grow up, and if an
algorithm is not there, people assume it's not ready for prime-time.

I think this is a role OpenSSL should embrace.  In the race to be the
world's #1 crypto library, OpenSSL won.  To extend it's lead, OpenSSL needs
to add modern algorithms like Blake2, SHA3, and ChaCha.  This is where I
imagine OpenSSL continuing to evolve and thrive, even if forks like
LibreSSL become popular.

The world is improved every time OpenSSL makes these difficult calls, and
blesses a new worthy crypto algorithm.  Blake2 seems like a simple call,
based on it's performance, pedigree, history, and cryptanalysis.  I'd say
that passing on Blake2 would be a mistake, for both the world and OpenSSL.
The world needs Blake2, and OpenSSL is how that happens.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/9889cfdf/attachment.html>

From kurt at roeckx.be  Tue Jun  9 16:34:25 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 9 Jun 2015 18:34:25 +0200
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
References: <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <7b63cc25a2b346a2af73ae6b66a44154@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
Message-ID: <20150609163425.GA14786@roeckx.be>

On Tue, Jun 09, 2015 at 12:19:56AM +0000, Zooko Wilcox-OHearn wrote:
> > I'd support adding 2b and 2s, in spite of the fact that the names are really really bad.  I'm less interested in seeing the parallel variants added.  FWIW.
> 
> Well, the reason I'm here is that the GNU coreutils maintainers rely
> on openssl for high-performance crypto, and blake2sp might be the best
> algorithm for the new "b2sum" tool, which I hope will replace "md5sum"
> in the toolboxes of system administrators everywhere.

It seems your b2sum currently defaults to b, not sp.


Kurt


From rt at openssl.org  Tue Jun  9 16:34:51 2015
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Tue, 09 Jun 2015 16:34:51 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <20150609163425.GA14786@roeckx.be>
References: <RT-Ticket-3897@openssl.org>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <CAH9QtQFwvhrdCWkyV8paMYdxdp_SW1ZQ6i2eBQ-qMe4caNA10g@mail.gmail.com>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <20150609163425.GA14786@roeckx.be>
Message-ID: <rt-4.0.19-10987-1433867691-1969.3897-6-0@openssl.org>

On Tue, Jun 09, 2015 at 12:19:56AM +0000, Zooko Wilcox-OHearn wrote:
> > I'd support adding 2b and 2s, in spite of the fact that the names are really really bad.  I'm less interested in seeing the parallel variants added.  FWIW.
> 
> Well, the reason I'm here is that the GNU coreutils maintainers rely
> on openssl for high-performance crypto, and blake2sp might be the best
> algorithm for the new "b2sum" tool, which I hope will replace "md5sum"
> in the toolboxes of system administrators everywhere.

It seems your b2sum currently defaults to b, not sp.


Kurt



From rsalz at akamai.com  Tue Jun  9 16:38:05 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jun 2015 16:38:05 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
 <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
Message-ID: <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Zooko only asked for supporting Blake2 as an MD5 replacement, but he's being too modest.? I can't stress enough how important the speed of Blake2

The problem is that when you say "Blake2" everyone (yes, everyone in the entire world:) thinks it's one digest.  What's really meant is a family of four.

That's not insurmountable, but it is confusing.

From waywardgeek at google.com  Tue Jun  9 16:43:17 2015
From: waywardgeek at google.com (Bill Cox)
Date: Tue, 9 Jun 2015 09:43:17 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
 <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
 <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>

On Tue, Jun 9, 2015 at 9:38 AM, Salz, Rich <rsalz at akamai.com> wrote:

>
> > Zooko only asked for supporting Blake2 as an MD5 replacement, but he's
> being too modest.  I can't stress enough how important the speed of Blake2
>
> The problem is that when you say "Blake2" everyone (yes, everyone in the
> entire world:) thinks it's one digest.  What's really meant is a family of
> four.
>
> That's not insurmountable, but it is confusing.


I agree.  How about Blake256 and Blake512, and leave out the parallel
versions?  That's not confusing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/feb7231c/attachment.html>

From rsalz at akamai.com  Tue Jun  9 16:44:38 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jun 2015 16:44:38 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150608171115.GA26759@roeckx.be>
 <rt-4.0.19-7129-1433806375-1198.3897-6-0@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
 <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
 <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>
Message-ID: <500e86c0cd984feda2dc6036e085f73b@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I agree.? How about Blake256 and Blake512, and leave out the parallel versions?? That's not confusing.?

My original proposal :)

I don't think supporting some of the Blake family is in any doubt.

From kurt at roeckx.be  Tue Jun  9 16:56:31 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 9 Jun 2015 18:56:31 +0200
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
Message-ID: <20150609165631.GA14469@roeckx.be>

On Fri, Jun 05, 2015 at 04:39:36PM +0000, Zooko Wilcox-OHearn via RT wrote:
> We, the BLAKE2 maintainers, offer both reference C code and optimized
> implementations: https://blake2.net/#dl . There are also other
> implementations with various virtues available: https://blake2.net/#sw

So it's my understanding that you would like to see atleast the sp
version, and would of course like to see this used with threads.
We currently do not make use of threads in OpenSSL, as in we do not
create them, but it should be multithread safe if you set up
locking.

Your implementation seems to be making use of OpenMP, and it seems
it can be used both with and without OpenMP support and I
understand that it should just work on older compilers that don't
support it.  There seem to be various compilers that support it
including gcc and Microsoft Visual C++.

I'm wondering if we should also use OpenMP.  It clearly looks very
useful.


Kurt


From rainer.jung at kippdata.de  Tue Jun  9 16:57:38 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Tue, 09 Jun 2015 18:57:38 +0200
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
 <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
 <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>
Message-ID: <55771B02.7000809@kippdata.de>

Am 09.06.2015 um 18:43 schrieb Bill Cox:
> On Tue, Jun 9, 2015 at 9:38 AM, Salz, Rich <rsalz at akamai.com
> <mailto:rsalz at akamai.com>> wrote:
>
>
>     > Zooko only asked for supporting Blake2 as an MD5 replacement, but he's being too modest.  I can't stress enough how important the speed of Blake2
>
>     The problem is that when you say "Blake2" everyone (yes, everyone in
>     the entire world:) thinks it's one digest.  What's really meant is a
>     family of four.
>
>     That's not insurmountable, but it is confusing.
>
>
> I agree.  How about Blake256 and Blake512, and leave out the parallel
> versions?  That's not confusing.

Not an expert here, but according to

https://131002.net/blake/

and

http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29

the terms BLAKE-256 and BLAKE-512 were already used by BLAKE, the 
predecessor of BLAKE2.

Regards,

Rainer


From waywardgeek at google.com  Tue Jun  9 17:20:47 2015
From: waywardgeek at google.com (Bill Cox)
Date: Tue, 9 Jun 2015 10:20:47 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <55771B02.7000809@kippdata.de>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
 <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
 <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>
 <55771B02.7000809@kippdata.de>
Message-ID: <CAH9QtQE9Rr4RbWX5jBgfJjPP-mdiovfFTcA=iexgoE-vzxgpGg@mail.gmail.com>

On Tue, Jun 9, 2015 at 9:57 AM, Rainer Jung <rainer.jung at kippdata.de> wrote:

> Not an expert here, but according to
>
> https://131002.net/blake/
>
> and
>
> http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29
>
> the terms BLAKE-256 and BLAKE-512 were already used by BLAKE, the
> predecessor of BLAKE2.
>
> Regards,
>
> Rainer
>

I guess we could ask the main original Blake author, Jean-Philippe, if he
would mind OpenSSL renaming Blake2b and Blake2s to Blake256 and Blake512.
Jean-Philippe, would you mind?  The names Blake2b and Blake2s are both
confusing and not similar to other names in OpenSSL.  Another alternative
might be Blake2-256 and Blake2-512, but Blake256 and Blake512 will be
simpler for OpenSSL users to grok.  What do you and Zooko think?

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/124dd811/attachment.html>

From jeanphilippe.aumasson at gmail.com  Tue Jun  9 17:23:45 2015
From: jeanphilippe.aumasson at gmail.com (Jean-Philippe Aumasson)
Date: Tue, 09 Jun 2015 17:23:45 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQE9Rr4RbWX5jBgfJjPP-mdiovfFTcA=iexgoE-vzxgpGg@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JxPsvkBCOz7j75A+QYESZQUuzqz_2j251T1haHFwmNzSw@mail.gmail.com>
 <rt-4.0.19-7129-1433808564-1557.3897-6-0@openssl.org>
 <b443f6af73c941d696c700c23a08826a@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-5412-1433808935-642.3897-6-0@openssl.org>
 <CAM_a8Jwyt22wJ-cLyg6UuZRfsJPzOHcvOaD7svasHvLRWT40mg@mail.gmail.com>
 <rt-4.0.19-5412-1433809229-1131.3897-6-0@openssl.org>
 <3d870debde234b65979e0ecd5a9487e7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JxjwuMsBpYrNhaF9B4Q1nzjv7TX3Vetuj0S9fr489OGvA@mail.gmail.com>
 <3e654b2436c34c8b853c394226910194@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAM_a8JyQ7222KXujfCiM47URKRR5hVDduPeFyXCGpHatQxpHqA@mail.gmail.com>
 <C39A61AA-33E7-4060-89D1-6F0DCA07B8C4@gmail.com>
 <CAH9QtQHT_S0r+=SsnDrKuxFsn9TN+3XdT59f1ZGzJm6KDPW_oQ@mail.gmail.com>
 <58ac98968f374ade86ee3c14d11a5120@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAH9QtQGcmMx1z7OMitg=W7EE7TDwWwwCs=BtOdebTghe7GCLYw@mail.gmail.com>
 <55771B02.7000809@kippdata.de>
 <CAH9QtQE9Rr4RbWX5jBgfJjPP-mdiovfFTcA=iexgoE-vzxgpGg@mail.gmail.com>
Message-ID: <CAGiyFdd_v7pOCBn4FrHz956BbJDYiG3z+BDxFseV-BjJkq7fvQ@mail.gmail.com>

Hi Bill,

First of all, it's spelled "BLAKE", with capitals :-)

BLAKE-256 is the 256-bit version of BLAKE. Calling BLAKE2 BLAKE would be
confusing.

What about B2-256 and B2-512?

ccing other B2 codesigners

On Tue 9 Jun 2015 at 19:20 Bill Cox <waywardgeek at google.com> wrote:

> On Tue, Jun 9, 2015 at 9:57 AM, Rainer Jung <rainer.jung at kippdata.de>
> wrote:
>
>> Not an expert here, but according to
>>
>> https://131002.net/blake/
>>
>> and
>>
>> http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29
>>
>> the terms BLAKE-256 and BLAKE-512 were already used by BLAKE, the
>> predecessor of BLAKE2.
>>
>> Regards,
>>
>> Rainer
>>
>
> I guess we could ask the main original Blake author, Jean-Philippe, if he
> would mind OpenSSL renaming Blake2b and Blake2s to Blake256 and Blake512.
> Jean-Philippe, would you mind?  The names Blake2b and Blake2s are both
> confusing and not similar to other names in OpenSSL.  Another alternative
> might be Blake2-256 and Blake2-512, but Blake256 and Blake512 will be
> simpler for OpenSSL users to grok.  What do you and Zooko think?
>
> Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/9857c032/attachment.html>

From zooko at leastauthority.com  Tue Jun  9 17:35:47 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Tue, 9 Jun 2015 17:35:47 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <20150609165631.GA14469@roeckx.be>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
Message-ID: <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>

Dear Kurt:

Another option is to include BLAKE2sp but use the single-threaded
reference implementation of BLAKE2sp. (Thanks to Samuel Neves for
reminding me about this.)

That way the hash values produced would be compatible with other
people's implementations, or possible future implementations, that
used multithreading, or used some fancy SIMD to compute the parallel
hashes in a single CPU core.

All of these are good options in my opinion:

BLAKE2b ? widely used, very efficient on modern 64-bit Intel CPUs and
on ARM chips with NEON, simpler than the "p" versions

BLAKE2s ? more efficient on 32-bit chips (e.g. ARMs) which do *not* have NEON

BLAKE2sp, multithreaded ? fastest option on my laptop today

BLAKE2sp, singlethreaded ? simpler than multithreading and compatible
with faster implementations

Regards,

Zooko

From zooko at leastauthority.com  Tue Jun  9 18:13:06 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Tue, 9 Jun 2015 18:13:06 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
Message-ID: <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>

> All of these are good options in my opinion:
>
> BLAKE2b ? widely used, very efficient on modern 64-bit Intel CPUs and
> on ARM chips with NEON, simpler than the "p" versions
>
> BLAKE2s ? more efficient on 32-bit chips (e.g. ARMs) which do *not* have NEON
>
> BLAKE2sp, multithreaded ? fastest option on my laptop today
>
> BLAKE2sp, singlethreaded ? simpler than multithreading and compatible
> with faster implementations

I would suggest that we move ahead with the last option ? the
reference implementation of BLAKE2sp. Reasons to choose that option:

1. Then we don't need to mess with compiling in the ASM code, adding
OpenMP support, or anything else for now.

2. It is compatible with faster versions in other tools or in future
versions of openssl.

3. BLAKE2sp (the OpenMP multithreaded version) is the fastest version
on my laptop today).

4. My crystal ball tells me that BLAKE2sp is going to turn out to be
the most efficient version for most uses in the long run, over the
coming decade, because it works well on tiny cheap devices and it also
works well on multicore systems. My crystal ball says that both of
those kinds of things are going to proliferate like locusts after the
rain.

Regards,

Zooko

From waywardgeek at google.com  Tue Jun  9 22:00:02 2015
From: waywardgeek at google.com (Bill Cox)
Date: Tue, 9 Jun 2015 15:00:02 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
Message-ID: <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>

On Tue, Jun 9, 2015 at 11:13 AM, Zooko Wilcox-OHearn <
zooko at leastauthority.com> wrote:

> > All of these are good options in my opinion:
> >
> > BLAKE2b ? widely used, very efficient on modern 64-bit Intel CPUs and
> > on ARM chips with NEON, simpler than the "p" versions
> >
> > BLAKE2s ? more efficient on 32-bit chips (e.g. ARMs) which do *not* have
> NEON
> >
> > BLAKE2sp, multithreaded ? fastest option on my laptop today
> >
> > BLAKE2sp, singlethreaded ? simpler than multithreading and compatible
> > with faster implementations
>
> I would suggest that we move ahead with the last option ? the
> reference implementation of BLAKE2sp. Reasons to choose that option:
>
> 1. Then we don't need to mess with compiling in the ASM code, adding
> OpenMP support, or anything else for now.
>
> 2. It is compatible with faster versions in other tools or in future
> versions of openssl.
>
> 3. BLAKE2sp (the OpenMP multithreaded version) is the fastest version
> on my laptop today).
>
> 4. My crystal ball tells me that BLAKE2sp is going to turn out to be
> the most efficient version for most uses in the long run, over the
> coming decade, because it works well on tiny cheap devices and it also
> works well on multicore systems. My crystal ball says that both of
> those kinds of things are going to proliferate like locusts after the
> rain.


I have trouble agreeing with this.  First, BLAKE2sp is more than 10X slower
than BLAKE2s for 256 bit inputs on my machine.  Small input hashing happens
frequently, in places such as PBKDF2, Merkel hash trees, MACs, and such.
One of Blake2's main strengths is performance across the board, in pretty
much every application, big or small.  On my machine, BLAKE2sp only wins
for data sizes over 1 KiB.  Also, OpenSSL should provide the SIMD version
anyway, so we'll need to deal with that regardless.  Finally, BLAKE2sp is a
simple OpenMP wrapper around BLAKE2s.  It can be rewritten in an generic
way that allows it to apply to any hash, such as SHA256.  I think this
parallel wrapper would be a valuable library routine.  In this way, we
could have sha256sump, and blake256sump, for the parallel versions, which
are faster.

I agree the future looks likely to have a ton of Blake2 everywhere.  It
also should have parallel hashing everywhere.  I just see these as two
independent upgrades.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/dfbc38ec/attachment-0001.html>

From uri at ll.mit.edu  Tue Jun  9 22:13:08 2015
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 9 Jun 2015 22:13:08 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
Message-ID: <20150609221251.17879106.56648.2093@ll.mit.edu>

Bill, I agree.

Sent?from?my?BlackBerry?10?smartphone?on?the?Verizon Wireless?4G?LTE?network.
From: Bill Cox
Sent: Tuesday, June 9, 2015 18:00
To: openssl-dev at openssl.org
Reply To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

On Tue, Jun 9, 2015 at 11:13 AM, Zooko Wilcox-OHearn <zooko at leastauthority.com> wrote:
> All of these are good options in my opinion:
>
> BLAKE2b ? widely used, very efficient on modern 64-bit Intel CPUs and
> on ARM chips with NEON, simpler than the "p" versions
>
> BLAKE2s ? more efficient on 32-bit chips (e.g. ARMs) which do *not* have NEON
>
> BLAKE2sp, multithreaded ? fastest option on my laptop today
>
> BLAKE2sp, singlethreaded ? simpler than multithreading and compatible
> with faster implementations

I would suggest that we move ahead with the last option ? the
reference implementation of BLAKE2sp. Reasons to choose that option:

1. Then we don't need to mess with compiling in the ASM code, adding
OpenMP support, or anything else for now.

2. It is compatible with faster versions in other tools or in future
versions of openssl.

3. BLAKE2sp (the OpenMP multithreaded version) is the fastest version
on my laptop today).

4. My crystal ball tells me that BLAKE2sp is going to turn out to be
the most efficient version for most uses in the long run, over the
coming decade, because it works well on tiny cheap devices and it also
works well on multicore systems. My crystal ball says that both of
those kinds of things are going to proliferate like locusts after the
rain.

I have trouble agreeing with this.? First, BLAKE2sp is more than 10X slower than BLAKE2s for 256 bit inputs on my machine.? Small input hashing happens frequently, in places such as PBKDF2, Merkel hash trees, MACs, and such.? One of Blake2's main strengths is performance across the board, in pretty much every application, big or small.? On my machine, BLAKE2sp only wins for data sizes over 1 KiB.? Also, OpenSSL should provide the SIMD version anyway, so we'll need to deal with that regardless.? Finally, BLAKE2sp is a simple OpenMP wrapper around BLAKE2s.? It can be rewritten in an generic way that allows it to apply to any hash, such as SHA256.? I think this parallel wrapper would be a valuable library routine.? In this way, we could have sha256sump, and blake256sump, for the parallel versions, which are faster.

I agree the future looks likely to have a ton of Blake2 everywhere.? It also should have parallel hashing everywhere.? I just see these as two independent upgrades.

Bill


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/f1ccf607/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/f1ccf607/attachment.bin>

From waywardgeek at google.com  Tue Jun  9 22:37:41 2015
From: waywardgeek at google.com (Bill Cox)
Date: Tue, 9 Jun 2015 15:37:41 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
Message-ID: <CAH9QtQGDJhe-jZqy_Zq=YFNzi4Be9CCniaqUr9vJ+SeexhTvdg@mail.gmail.com>

By the way, parallel hashing works much better than I thought it would.
For a memory-hard password hashing such as Scrypt, parallel threads need to
operate on very different areas of memory, or performance goes out the
window.  Apparently the overhead in cache coherency dominates if multiple
threads are writing to the same page.  Also, using OpenMP on memory-hard
hashing works poorly compared to manually managing pthreads, and I expected
to see that with parallel hashing, but didn't.  I think what happens is
that when one thread starts outpacing the others, it sees cache misses and
slows down.  A thread that falls behind never sees a cache miss, and
quickly catches up.  Interleaved multi-threaded hashing is a very cool
algorithm!  It looks simple to write for any of the OpenSSL hash functions.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150609/2da1cc61/attachment.html>

From naynjain at in.ibm.com  Wed Jun 10 03:18:41 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Wed, 10 Jun 2015 08:48:41 +0530
Subject: [openssl-dev] [openssl-users] Is there openssl API to verify
 certificate content is DER or PEM format ?
In-Reply-To: <20150609050347.GM5512@mournblade.imrryr.org>
References: <OF04312994.4A822603-ON65257E5F.0017A49C-65257E5F.0017F964@in.ibm.com>
 <20150609050347.GM5512@mournblade.imrryr.org>
Message-ID: <OFCE5A81E7.08C1A23A-ON65257E60.0011F481-65257E60.00123010@in.ibm.com>


Thanks..

I think I will try with X509_read_xxx and d2i_, then probably do not have
to read throu first character as 0x30.

I had few more questions.

Are all d2i_xxx type of APIs for DER format.

And if I have to operate on DER formatted certs, do I need to first convert
it to PEM and then user PEM APIs. or there are DER specific APIs also, I
didn't find though, unless they are d2i_xxx types.


Thanks & Regards,
Nayna Jain



From:	Viktor Dukhovni <openssl-users at dukhovni.org>
To:	openssl-users at openssl.org
Date:	06/09/2015 10:34 AM
Subject:	Re: [openssl-users] Is there openssl API to verify certificate
            content is DER or PEM format ?
Sent by:	"openssl-users" <openssl-users-bounces at openssl.org>



[ Please DO NOT post user questions to openssl-dev, that's rude. ]

On Tue, Jun 09, 2015 at 09:51:52AM +0530, Nayna Jain wrote:

> I need to verify if the certifiate I have received is having its content
in
> PEM/DER format.
>
> Is there any API which if given file pointer like (fp) will tell me
whether
> it has valid format of certificate and if yes then whether it is PEM/DER
> format ?
>
> If no API, then what is the other way to verify this ?

If the first character of the file is 0x30 (ASN.1 sequence) it is
likely in DER form.  With stdio you can peek at that character and
use ungetc() to put it back.

The only false positives for DER will be files in which the PEM
'-----BEGIN ...-----' line is preceded by "comment" text that
happens to start with a '0'.  If your PEM files contain no "comments",
the test is always accurate.

A more robust test is to try PEM_read_X509() or PEM_read_bio_X509()
and if that fails, rewind the file, and try d2i_X509_fp() or
d2i_X509_bio().  The latter need not be tried if the first character
of the file is not 0x30.

--
		 Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/ed8914a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/ed8914a0/attachment-0001.gif>

From naynjain at in.ibm.com  Wed Jun 10 03:22:05 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Wed, 10 Jun 2015 08:52:05 +0530
Subject: [openssl-dev] X509_STORE_free() and X509_LOOKUP_free() also frees
 the X509 certificates inside it
Message-ID: <OF2512B4B1.C5A5D333-ON65257E60.00123A5A-65257E60.00127F9D@in.ibm.com>


Hi all,

I am using X509_STORE and X509_LOOKUP to verify the certificate and its
chain.

But at the end when I do X509_STORE_free(store)  and X509_LOOKUP_free
(lookup), it is also doing free of the X509* certificate which I added.
But I don't want that, because after that when I immediately try to access
X509* certificate for further operation, then it results in core dump

And if I don't do X509_STORE_free() then it will leave the memory leak.

Let me know how to resolve this and if I misunderstood something.

Thanks & Regards,
Nayna Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/fe3d2a68/attachment.html>

From openssl-users at dukhovni.org  Wed Jun 10 04:47:24 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 10 Jun 2015 04:47:24 +0000
Subject: [openssl-dev] [openssl-users] Is there openssl API to verify
 certificate content is DER or PEM format ?
In-Reply-To: <OFCE5A81E7.08C1A23A-ON65257E60.0011F481-65257E60.00123010@in.ibm.com>
References: <OF04312994.4A822603-ON65257E5F.0017A49C-65257E5F.0017F964@in.ibm.com>
 <20150609050347.GM5512@mournblade.imrryr.org>
 <OFCE5A81E7.08C1A23A-ON65257E60.0011F481-65257E60.00123010@in.ibm.com>
Message-ID: <20150610044723.GB2050@mournblade.imrryr.org>

On Wed, Jun 10, 2015 at 08:48:41AM +0530, Nayna Jain wrote:

> I think I will try with PEM_read_xxx and d2i_, then probably do not have
> to read throu first character as 0x30.

That works, provided you rewind or re-open the file.

> Are all d2i_xxx type of APIs for DER format.

Yes, they decode binary ASN.1 encodings of the relevant structures.
And conversely i2d_... encodes a C structure to ASN.1 (typically
DER) form.
> 
> And if I have to operate on DER formatted certs, do I need to first convert
> it to PEM and then user PEM APIs. or there are DER specific APIs also, I
> didn't find though, unless they are d2i_xxx types.

I don't see why you would need to convert to PEM first, though
there are legitimate reasons to do so when you need to write
configuration files to disk, as PEM is easier to work with as a
configuration format.

-- 
	Viktor.

From hkario at redhat.com  Wed Jun 10 11:53:19 2015
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 10 Jun 2015 13:53:19 +0200
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAH9QtQE9Rr4RbWX5jBgfJjPP-mdiovfFTcA=iexgoE-vzxgpGg@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org> <55771B02.7000809@kippdata.de>
 <CAH9QtQE9Rr4RbWX5jBgfJjPP-mdiovfFTcA=iexgoE-vzxgpGg@mail.gmail.com>
Message-ID: <1543195.fqriQnG3YJ@pintsize.usersys.redhat.com>

On Tuesday 09 June 2015 10:20:47 Bill Cox wrote:
> On Tue, Jun 9, 2015 at 9:57 AM, Rainer Jung <rainer.jung at kippdata.de> wrote:
> > Not an expert here, but according to
> > 
> > https://131002.net/blake/
> > 
> > and
> > 
> > http://en.wikipedia.org/wiki/BLAKE_%28hash_function%29
> > 
> > the terms BLAKE-256 and BLAKE-512 were already used by BLAKE, the
> > predecessor of BLAKE2.
> > 
> > Regards,
> > 
> > Rainer
> 
> I guess we could ask the main original Blake author, Jean-Philippe, if he
> would mind OpenSSL renaming Blake2b and Blake2s to Blake256 and Blake512.
> Jean-Philippe, would you mind?  The names Blake2b and Blake2s are both
> confusing and not similar to other names in OpenSSL.  Another alternative
> might be Blake2-256 and Blake2-512, but Blake256 and Blake512 will be
> simpler for OpenSSL users to grok.  What do you and Zooko think?

we'll soon get sha3-256 and sha3-512 (among others), "BLAKE2-256" (or to 
continue the lower case naming scheme - blake2-256) doesn't look bad compared 
to those

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/bb3af7e2/attachment.sig>

From waywardgeek at google.com  Wed Jun 10 13:17:35 2015
From: waywardgeek at google.com (Bill Cox)
Date: Wed, 10 Jun 2015 06:17:35 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <1543195.fqriQnG3YJ@pintsize.usersys.redhat.com>
References: <RT-Ticket-3897@openssl.org> <55771B02.7000809@kippdata.de>
 <CAH9QtQE9Rr4RbWX5jBgfJjPP-mdiovfFTcA=iexgoE-vzxgpGg@mail.gmail.com>
 <1543195.fqriQnG3YJ@pintsize.usersys.redhat.com>
Message-ID: <CAH9QtQF6Lj7_SUAj9G7Qq+0DgeQO3gjLF5LSeNMZoundzK3hYw@mail.gmail.com>

On Wed, Jun 10, 2015 at 4:53 AM, Hubert Kario <hkario at redhat.com> wrote:

> we'll soon get sha3-256 and sha3-512 (among others), "BLAKE2-256" (or to
> continue the lower case naming scheme - blake2-256) doesn't look bad
> compared
> to those
>


In that case, I prefer 2 new sets of hash functions:

    blake2-256/BLAKE2-256
    blake2-512/BLAKE2-512

based on BLAKE2s and BLAKE2b respectively.  For the basic BLAKE2
integration, I would leave the parallel versions out.

And that's it.  Nice and simple :-)  I'll offer to do the integration if no
one beats me to it.

...

However, as a separate proposal, should we discuss parallel hashing APIs?
Should it be on a different thread?  I'm commenting here for now:

First, I think Zooko's intuition is right.  Parallel hashing should be
offered by OpenSSL, simply because that will greatly increase it's use, and
there will be significant benefit to users.

As for implementation, I would like to see parallel APIs added for BLAKE2
and the SHA functions at a minimum.  The number of threads should be a
parameter rather than hard-coded, and it should be based on OpenMP.  Users
will need to understand that the resulting hash depends on the number of
threads used.

Before dealing with EVP extensions, there should be parallel APIs for the
standard hash functinos, such as:

int SHA256P_Init(SHA256P_CTX *c, unsigned int max_threads);
int SHA256P_Update(SHA256P_CTX *c, const void *data, size_t len);
int SHA256P_Final(unsigned char *md, SHA256P_CTX *c);
unsigned char *SHA256P(const unsigned char *d, size_t n, unsigned char *md,
unsigned int nax_threads);

and

int BLAKE2_256P_Init(BLAKE2_256P_CTX *c, unsigned int max_threads);
int BLAKE2_256P_Update(BLAKE2_256P_CTX *c, const void *data, size_t len);
int BLAKE2_256P_Final(unsigned char *md, BLAKE2_256P_CTX *c);
unsigned char *BLAKE2_256P(const unsigned char *d, size_t n, unsigned char
*md, unsigned int nax_threads);

I hate to recommend more macro-template madness for OpenSSL.  The ASN1
template macros in the 1.0.1 branch made me want to set my hair on fire (I
believe this has been cleaned up since).  Of the million-ish lines of
open-source code I've read over the years, this might win the prize for the
most obfuscated.  However, these parallel hash functions could easily be
generated with macros, or perhaps some more Perl madness.  The code
template is the same regardless of the hash used.  We could literally copy
the code from blake2sp.c to make the template.  Would it be better to just
copy+paste+edit the code for each hash function, and avoid more template
madness?

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/5e525001/attachment.html>

From rt at openssl.org  Wed Jun 10 16:05:57 2015
From: rt at openssl.org (Michal Bozon via RT)
Date: Wed, 10 Jun 2015 16:05:57 +0000
Subject: [openssl-dev] [openssl.org #3901] [PATCH] ts_rsp_print.c: fix
	TS_RESP_get_tst_info double call
In-Reply-To: <CAJ-1OcKb_nBLxSnxsr2Q+scu9gr=DaCDamjFXB4sT3n0KpiVqw@mail.gmail.com>
References: <RT-Ticket-3901@openssl.org>
 <CAJ-1OcKb_nBLxSnxsr2Q+scu9gr=DaCDamjFXB4sT3n0KpiVqw@mail.gmail.com>
Message-ID: <rt-4.0.19-10987-1433952356-915.3901-21-0@openssl.org>

Use tst_info instead of calling TS_RESP_get_tst_info(a) second time.

-- 
Michal Bozon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ts_rsp_print-TS_RESP_print_bio-dup_func_call.patch
Type: text/x-patch
Size: 427 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/e0054a08/attachment.bin>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From zooko at leastauthority.com  Wed Jun 10 22:19:10 2015
From: zooko at leastauthority.com (Zooko Wilcox-OHearn)
Date: Wed, 10 Jun 2015 22:19:10 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
Message-ID: <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>

On Tue, Jun 9, 2015 at 10:00 PM, Bill Cox <waywardgeek at google.com> wrote:
>>
>> I would suggest that we move ahead with the last option ? the
>> reference implementation of BLAKE2sp.

> I have trouble agreeing with this.  First, BLAKE2sp is more than 10X slower
> than BLAKE2s for 256 bit inputs on my machine.

Wow! I didn't measure that. What implementation of BLAKE2sp did you
try? What kind of machine is yours?

>  Small input hashing happens frequently, in places such as PBKDF2, Merkel hash trees, MACs, and such.

Agreed.

> One of Blake2's main strengths is performance across the board, in pretty
> much every application, big or small.

Agreed.

>  On my machine, BLAKE2sp only wins for data sizes over 1 KiB.

Hm, yeah, I'm mostly driven by the "b2sum" use case here, which almost
never gets used on inputs as small as 1 KiB, and often gets used on
inputs 3 or even 6 orders of magnitude bigger!

I agree with you that the short-input use case is really important. I
wonder how well we could do with an optimized, single-threaded
implementation of BLAKE2sp. Could you do an experiment of the
single-threaded implementation of BLAKE2sp with floodyberry's
optimized implementation: https://github.com/floodyberry/blake2b-opt ?


>  Also, OpenSSL should provide the SIMD version
> anyway, so we'll need to deal with that regardless.  Finally, BLAKE2sp is a
> simple OpenMP wrapper around BLAKE2s.  It can be rewritten in an generic way
> that allows it to apply to any hash, such as SHA256.  I think this parallel
> wrapper would be a valuable library routine.  In this way, we could have
> sha256sump, and blake256sump, for the parallel versions, which are faster.
>
> I agree the future looks likely to have a ton of Blake2 everywhere.  It also
> should have parallel hashing everywhere.  I just see these as two
> independent upgrades.

That sounds like a good idea!


Regards,

Zooko

From waywardgeek at google.com  Wed Jun 10 23:36:27 2015
From: waywardgeek at google.com (Bill Cox)
Date: Wed, 10 Jun 2015 16:36:27 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
Message-ID: <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>

On Wed, Jun 10, 2015 at 3:19 PM, Zooko Wilcox-OHearn <
zooko at leastauthority.com> wrote:

> On Tue, Jun 9, 2015 at 10:00 PM, Bill Cox <waywardgeek at google.com> wrote:
> >>
> >> I would suggest that we move ahead with the last option ? the
> >> reference implementation of BLAKE2sp.
>
> > I have trouble agreeing with this.  First, BLAKE2sp is more than 10X
> slower
> > than BLAKE2s for 256 bit inputs on my machine.
>
> Wow! I didn't measure that. What implementation of BLAKE2sp did you
> try? What kind of machine is yours?


My machine is a desktop with a Xeon E5-1650 v2 @ 3.50GHz.  I've attached
the code.  It's Samuel Neves' SSE4.1 optimized version, with a simple
wrapper to measure the speed.

>  On my machine, BLAKE2sp only wins for data sizes over 1 KiB.
>
> Hm, yeah, I'm mostly driven by the "b2sum" use case here, which almost
> never gets used on inputs as small as 1 KiB, and often gets used on
> inputs 3 or even 6 orders of magnitude bigger!
>

That's a _very_ important use case!


> I agree with you that the short-input use case is really important. I
> wonder how well we could do with an optimized, single-threaded
> implementation of BLAKE2sp. Could you do an experiment of the
> single-threaded implementation of BLAKE2sp with floodyberry's
> optimized implementation: https://github.com/floodyberry/blake2b-opt ?


I could benchmark it, but the basic problem is that BLAKE2sp initializes 8
BLAKE2s contexts, calls 8 finish methods, and then hashes 256*8 bits to
generate the 256 bit result.  There is no way to make this speed
competitive for small inputs on the order of 256 bits.

However, we could get fancier if we wanted a threaded algorithm with a
simple API, and no num_threads parameter.  I love these sorts of
optimizations :-)  Start out by hashing the first 512 bytes with 1 thread,
then switch to 2 threads for the next 1KiB.  After that, hash the next 2KiB
with 4 threads, and the rest with 8 threads.

This way, for large files, you would get the full 8-thread speed, while for
tiny hashes like 256 bits, you get the raw BLAKE2s speed.  Honestly,
BLAKE2sp and BLAKE2bp should already work this way.  I think I've just
talked myself into thinking that any OpenSSL parallel hash wrappers should
also work this way (possibly with a max_threads parameter).

Samuel Neves' SSE version is the one we all played with in the Password
Hashing Competition.  The speed is amazing.  Is there a faster version
available now?  Which version should we integrate into OpenSSL?

BLAKE2 rocks.  I'm looking forward to using it in many applications.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/2eb9e482/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blake2-sse.tar.gz
Type: application/x-gzip
Size: 9061 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/2eb9e482/attachment.bin>

From sneves at dei.uc.pt  Thu Jun 11 00:22:16 2015
From: sneves at dei.uc.pt (Samuel Neves)
Date: Thu, 11 Jun 2015 01:22:16 +0100
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
Message-ID: <5578D4B8.90901@dei.uc.pt>

On 11-06-2015 00:36, Bill Cox wrote:
> Samuel Neves' SSE version is the one we all played with in the Password
> Hashing Competition.  The speed is amazing.  Is there a faster version
> available now?  Which version should we integrate into OpenSSL?

The problem with my implementation is that it relies on compiler intrinsics. This means that depending on the compiler
version, flags, and the current moon phase performance can degrade significantly for no apparent reason. Some older
compilers do not have those intrinsics at all. This is not desirable for inclusion in a library such as OpenSSL, which
is meant to be compiled in all sorts of setups.

Of course, we can take a known-good compilation output and place the assembly directly into the library. Andrew Moon's
code, linked  by Zooko, appears to be that (though the implementation is different from mine) plus some extra massaging
to handle different calling conventions and ABIs. It is pretty good.

Regarding which version of BLAKE2 to include, I think people are conflating two different use cases here, which is
complicating things:

 - Use case #1 is for packet authentication. Seeing that BLAKE2 has now an IETF draft going meant primarily for that
purpose---in which the BLAKE2*p variants are not included---it seems obvious to me that the IETF versions are the ones
to include, since if new ciphersuites show up with BLAKE2 OpenSSL is forced to include them anyway.

 - Use case #2 is for large file integrity checks. This is where the parallel versions shine, largely benefiting from
multi-threading. OpenSSL does not natively support threading, as I understand it, so this is one downside. Another
downside is that the parallel implementations are slower for small messages, as Bill points out, which is unavoidable by
their tree structure. BLAKE2sp is likely the best option for large-scale hashing (as the WinRAR author also concluded),
but I'm not so sure that OpenSSL is ready for that.

Now, let's recall that the initial impetus for including BLAKE2 in OpenSSL---from Zooko's point of view---was so that
coreutils could trivially link to it and get great performance out of it. Since OpenSSL does not do threads, it's
unlikely that will happen without significant wrangling.

My personal recommendation is BLAKE2b. It is the fastest sequential variant on x86, ARMv7 with NEON, and also ARMv8. Are
there any supported OpenSSL platforms where this kind of speed is essential, but where BLAKE2s is significantly faster
than BLAKE2b (a reasonable proxy data point for this would be where SHA256 convincingly beats SHA512)?

Best regards,
Samuel Neves




From naynjain at in.ibm.com  Thu Jun 11 00:31:26 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Thu, 11 Jun 2015 06:01:26 +0530
Subject: [openssl-dev] [openssl-users] Is there openssl API to verify
 certificate content is DER or PEM format ?
In-Reply-To: <20150610044723.GB2050@mournblade.imrryr.org>
References: <OF04312994.4A822603-ON65257E5F.0017A49C-65257E5F.0017F964@in.ibm.com>
 <20150609050347.GM5512@mournblade.imrryr.org>
 <OFCE5A81E7.08C1A23A-ON65257E60.0011F481-65257E60.00123010@in.ibm.com>
 <20150610044723.GB2050@mournblade.imrryr.org>
Message-ID: <OFCE2F5514.7B32DA94-ON65257E61.0002C451-65257E61.0002E012@in.ibm.com>


Hi,

Thanks Victor, I am going to try these..

I have similar concern for private key.
If I have a pem file with private key in that, how do I check if that is
RSA/DSA ?

Thanks & Regards,
Nayna Jain



From:	Viktor Dukhovni <openssl-users at dukhovni.org>
To:	openssl-users at openssl.org, openssl-dev at openssl.org
Date:	06/10/2015 10:18 AM
Subject:	Re: [openssl-users] Is there openssl API to verify certificate
            content is DER or PEM format ?
Sent by:	"openssl-users" <openssl-users-bounces at openssl.org>



On Wed, Jun 10, 2015 at 08:48:41AM +0530, Nayna Jain wrote:

> I think I will try with PEM_read_xxx and d2i_, then probably do not have
> to read throu first character as 0x30.

That works, provided you rewind or re-open the file.

> Are all d2i_xxx type of APIs for DER format.

Yes, they decode binary ASN.1 encodings of the relevant structures.
And conversely i2d_... encodes a C structure to ASN.1 (typically
DER) form.
>
> And if I have to operate on DER formatted certs, do I need to first
convert
> it to PEM and then user PEM APIs. or there are DER specific APIs also, I
> didn't find though, unless they are d2i_xxx types.

I don't see why you would need to convert to PEM first, though
there are legitimate reasons to do so when you need to write
configuration files to disk, as PEM is easier to work with as a
configuration format.

--
		 Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/f43ea838/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/f43ea838/attachment-0001.gif>

From waywardgeek at google.com  Thu Jun 11 01:52:00 2015
From: waywardgeek at google.com (Bill Cox)
Date: Wed, 10 Jun 2015 18:52:00 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <5578D4B8.90901@dei.uc.pt>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <5578D4B8.90901@dei.uc.pt>
Message-ID: <CAH9QtQEtX8abymgHra2m8DuQ9EsMY8RiYJYQtVRbmmWiWUzyhQ@mail.gmail.com>

On Wed, Jun 10, 2015 at 5:22 PM, Samuel Neves <sneves at dei.uc.pt> wrote:

> On 11-06-2015 00:36, Bill Cox wrote:
> > Samuel Neves' SSE version is the one we all played with in the Password
> > Hashing Competition.  The speed is amazing.  Is there a faster version
> > available now?  Which version should we integrate into OpenSSL?
>
> The problem with my implementation is that it relies on compiler
> intrinsics. This means that depending on the compiler
> version, flags, and the current moon phase performance can degrade
> significantly for no apparent reason. Some older
> compilers do not have those intrinsics at all. This is not desirable for
> inclusion in a library such as OpenSSL, which
> is meant to be compiled in all sorts of setups.
>
> Of course, we can take a known-good compilation output and place the
> assembly directly into the library. Andrew Moon's
> code, linked  by Zooko, appears to be that (though the implementation is
> different from mine) plus some extra massaging
> to handle different calling conventions and ABIs. It is pretty good.
>

Got it.  Thanks for that confirmation.


> Regarding which version of BLAKE2 to include, I think people are
> conflating two different use cases here, which is
> complicating things:
>
>  - Use case #1 is for packet authentication. Seeing that BLAKE2 has now an
> IETF draft going meant primarily for that
> purpose---in which the BLAKE2*p variants are not included---it seems
> obvious to me that the IETF versions are the ones
> to include, since if new ciphersuites show up with BLAKE2 OpenSSL is
> forced to include them anyway.
>
>  - Use case #2 is for large file integrity checks. This is where the
> parallel versions shine, largely benefiting from
> multi-threading. OpenSSL does not natively support threading, as I
> understand it, so this is one downside. Another
> downside is that the parallel implementations are slower for small
> messages, as Bill points out, which is unavoidable by
> their tree structure. BLAKE2sp is likely the best option for large-scale
> hashing (as the WinRAR author also concluded),
> but I'm not so sure that OpenSSL is ready for that.
>
> Now, let's recall that the initial impetus for including BLAKE2 in
> OpenSSL---from Zooko's point of view---was so that
> coreutils could trivially link to it and get great performance out of it.
> Since OpenSSL does not do threads, it's
> unlikely that will happen without significant wrangling.
>

I think maybe the threaded hash functions for BLAKE2, SHA2, etc, could be
in a library on top of OpenSSL.  That might make more sense.


> My personal recommendation is BLAKE2b. It is the fastest sequential
> variant on x86, ARMv7 with NEON, and also ARMv8. Are
> there any supported OpenSSL platforms where this kind of speed is
> essential, but where BLAKE2s is significantly faster
> than BLAKE2b (a reasonable proxy data point for this would be where SHA256
> convincingly beats SHA512)?
>
> Best regards,
> Samuel Neves
>
>
If only one can be included, I agree it should be BLAKE2b.  However, I
would prefer to have both BLAKE2s and BLAKE2b, and call them BLAKE2_256 and
BLAKE2_512.  I think there are plenty of use cases for BLAKE2_256.  My own
TwoCats submission used it by default, because it's faster for my use
case.  If you only hash 256 bits and you do it often, BLAKE2_256 is a good
choice.

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/b587af95/attachment.html>

From rsalz at akamai.com  Thu Jun 11 03:45:00 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 11 Jun 2015 03:45:00 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQEtX8abymgHra2m8DuQ9EsMY8RiYJYQtVRbmmWiWUzyhQ@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <5578D4B8.90901@dei.uc.pt>
 <CAH9QtQEtX8abymgHra2m8DuQ9EsMY8RiYJYQtVRbmmWiWUzyhQ@mail.gmail.com>
Message-ID: <cc38c2379f0a454f99cfc32099a58a52@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Of course, we can take a known-good compilation output and place the assembly directly into the library. Andrew Moon's

That's not the way openssl works with assembler.  I expect that anything other than the perl-based assembler stuff will get pushback from our assembler guru.


From gmaheshwari24.6 at gmail.com  Thu Jun 11 05:41:11 2015
From: gmaheshwari24.6 at gmail.com (gaurav maheshwari)
Date: Thu, 11 Jun 2015 11:11:11 +0530
Subject: [openssl-dev] 32 bit compilation of armv8 assembly
	support(openssl-1.0.2a)
Message-ID: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>

Hi,
       Can we use armv8 assembly support provided in openssl-1.0.2a for 32
bit mode compilation.

Regards,
Gaurav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/22c04d37/attachment.html>

From waywardgeek at google.com  Thu Jun 11 05:52:00 2015
From: waywardgeek at google.com (Bill Cox)
Date: Wed, 10 Jun 2015 22:52:00 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <cc38c2379f0a454f99cfc32099a58a52@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <5578D4B8.90901@dei.uc.pt>
 <CAH9QtQEtX8abymgHra2m8DuQ9EsMY8RiYJYQtVRbmmWiWUzyhQ@mail.gmail.com>
 <cc38c2379f0a454f99cfc32099a58a52@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAH9QtQFAs9EGSJdTQdkAqcUi32cFC4HDYm2QxLz3Us8L+YUgxQ@mail.gmail.com>

On Wed, Jun 10, 2015 at 8:45 PM, Salz, Rich <rsalz at akamai.com> wrote:

>
> > Of course, we can take a known-good compilation output and place the
> assembly directly into the library. Andrew Moon's
>
> That's not the way openssl works with assembler.  I expect that anything
> other than the perl-based assembler stuff will get pushback from our
> assembler guru.


It will have to be supported with the perl-based assembler stuff.   Does
OpenSSL's assembler guru have a few cycles to point me in the right
direction for how to do that?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150610/f2d029c2/attachment.html>

From ynir.ietf at gmail.com  Thu Jun 11 08:14:23 2015
From: ynir.ietf at gmail.com (Yoav Nir)
Date: Thu, 11 Jun 2015 11:14:23 +0300
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
Message-ID: <46C2109D-5CCE-4342-ABA9-B92DEC093358@gmail.com>


> On Jun 11, 2015, at 2:36 AM, Bill Cox <waywardgeek at google.com> wrote:
> 
> BLAKE2 rocks.  I'm looking forward to using it in many applications.
> 

Sure. I would be glad to see that used as a hash in signatures and in TLS, as a PRF in TLS and IKE, etc.

Does anyone know what the status of draft-saarinen-blake2 is?  If that progresses we can propose things like TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.

Yoav

[*] I think we should call that ciphersuite ?Suite-C? with ?C? standing for civilian, because this is a whole bunch of algorithms, none of which came from the government of the (pseudo-)military.


From appro at openssl.org  Thu Jun 11 08:22:54 2015
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 11 Jun 2015 10:22:54 +0200
Subject: [openssl-dev] 32 bit compilation of armv8 assembly
	support(openssl-1.0.2a)
In-Reply-To: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
References: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
Message-ID: <5579455E.7070409@openssl.org>

Hi,

>        Can we use armv8 assembly support provided in openssl-1.0.2a for
> 32 bit mode compilation.

It *is* used in 32-bit compilation as-is. aesv8-armx and ghashv8-armx
are included in armv4_asm, and sha1-armv4-large and sha256-armv4 modules
incorporate support for ARMv8 SHA instructions. But don't miss
commentary in Configure prior linux-armv4 line.


From fweimer at redhat.com  Thu Jun 11 08:34:52 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 11 Jun 2015 10:34:52 +0200
Subject: [openssl-dev] A Question about CRYPTO_THREADID when upgrading
	to OpenSSL 1.0.1e
In-Reply-To: <1389679936706-48125.post@n7.nabble.com>
References: <1389679936706-48125.post@n7.nabble.com>
Message-ID: <5579482C.3050300@redhat.com>

On 01/14/2014 07:12 AM, Aaron wrote:
> Hi All,
> 
> We have upgraded our OpenSSL from 9.0.8b to OpenSSL 1.0.1e. We have
> encountered some thread issues. From releated OpenSSL document
> (http://www.openssl.org/docs/crypto/threads.html), we see the following
> description.
> 
> /CRYPTO_THREADID and associated functions were introduced in OpenSSL 1.0.0
> to replace (actually, deprecate) the previous CRYPTO_set_id_callback(),
> CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed
> thread IDs to always be represented by 'unsigned long'. /
> 
> We haven't change all calls to CRYPTO_set_id_callback(),
> CRYPTO_get_id_callback(), and CRYPTO_thread_id() in our code to
> CRYPTO_THREADID routines. 
> 
> The question I would like to ask is if we upgrade OpenSSL from 9.0.8b to
> OpenSSL 1.0.1e without making the above suggested change what the
> sebsequence is? Will this cause race conditions?

Which platform are you on?

-- 
Florian Weimer / Red Hat Product Security

From fweimer at redhat.com  Thu Jun 11 08:41:58 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 11 Jun 2015 10:41:58 +0200
Subject: [openssl-dev] Self-initialization of locking/threadid callbacks
 and auto-detection of features
In-Reply-To: <20131029231514.GA23539@gmail.com>
References: <CAK3OfOhgUAQirHZbb=KXbykjAigLXmmva1DK4-5Stau_eTd+bg@mail.gmail.com>
 <20131028020710.GA15554@gmail.com> <52702171.1060604@openssl.org>
 <20131029231514.GA23539@gmail.com>
Message-ID: <557949D6.9010506@redhat.com>

On 10/30/2013 12:15 AM, Nico Williams wrote:
> On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote:
>> pthreads and Windows, and one can indeed argue why wouldn't OpenSSL
>> simply default to either of the two when appropriate. While it's
>> more than appropriate on Windows as it is, on pthreads-powered
>> Unices it's not as obvious. Because pthreads can be undesired in
>> some situations. Basically it boils down to question whether or not
>> libcrypto may be linked with libpthread or not. And answer is
>> actually "not desired." Ideally libcrypto should *detect* if

Detecting things in libcrypto is very difficult on GNU/Linux due to the
way dynamic linking works.

> More details would be nice.  What follows is speculation of mine as to
> what you might have in mind (or even if you don't, it might be
> relevant).
> 
> To summarize the below:
> 
>     OpenSSL .so's should always be linked with -lpthread on OSes where
>     there's a standard libpthread that threaded apps are expected to
>     use; OpenSSL static link archives should assume no threading
>     libraries and rely on the callers to provide the threading
>     callbacks.

On GNU/Linux, you should try very hard to avoid linking -lpthread and
restrict yourself to the pthreads API subset which is available without
-lpthread.  If something is missing, we (as in glibc upstream) can move
additional functionality from libpthread to libc.

Linking -lpthread has a real performance hit for unthreaded
applications, so core libraries should avoid it.

If you have received advice to the contrary, your source of advice is
wrong. :-)

-- 
Florian Weimer / Red Hat Product Security

From jeanphilippe.aumasson at gmail.com  Thu Jun 11 08:50:54 2015
From: jeanphilippe.aumasson at gmail.com (Jean-Philippe Aumasson)
Date: Thu, 11 Jun 2015 08:50:54 +0000
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <46C2109D-5CCE-4342-ABA9-B92DEC093358@gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <46C2109D-5CCE-4342-ABA9-B92DEC093358@gmail.com>
Message-ID: <CAGiyFderL+pFSNOkuQHw3phnaRDYT3HtzF1O8UF-S2BL+xBciw@mail.gmail.com>

The status of the draft is unchanged ("Finding Reviewers"). Perhaps OpenSSL
can speed up the review process.

BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace Poly1305. A
BLAKE2 MAC can be customized wrt key or tag size, and can provide the
highest security level for a give key/tag size combination.



On Thu, Jun 11, 2015 at 10:15 AM Yoav Nir <ynir.ietf at gmail.com> wrote:

>
> > On Jun 11, 2015, at 2:36 AM, Bill Cox <waywardgeek at google.com> wrote:
> >
> > BLAKE2 rocks.  I'm looking forward to using it in many applications.
> >
>
> Sure. I would be glad to see that used as a hash in signatures and in TLS,
> as a PRF in TLS and IKE, etc.
>
> Does anyone know what the status of draft-saarinen-blake2 is?  If that
> progresses we can propose things like
> TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.
>
> Yoav
>
> [*] I think we should call that ciphersuite ?Suite-C? with ?C? standing
> for civilian, because this is a whole bunch of algorithms, none of which
> came from the government of the (pseudo-)military.
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/f424125a/attachment.html>

From dthompson at prinpay.com  Thu Jun 11 10:03:39 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Thu, 11 Jun 2015 06:03:39 -0400
Subject: [openssl-dev] [openssl-users] Is there openssl API to verify
	certificate content is DER or PEM format ?
In-Reply-To: <OFCE2F5514.7B32DA94-ON65257E61.0002C451-65257E61.0002E012@in.ibm.com>
References: <OF04312994.4A822603-ON65257E5F.0017A49C-65257E5F.0017F964@in.ibm.com>
 <20150609050347.GM5512@mournblade.imrryr.org>
 <OFCE5A81E7.08C1A23A-ON65257E60.0011F481-65257E60.00123010@in.ibm.com>
 <20150610044723.GB2050@mournblade.imrryr.org>
 <OFCE2F5514.7B32DA94-ON65257E61.0002C451-65257E61.0002E012@in.ibm.com>
Message-ID: <000d01d0a42d$e7698440$b63c8cc0$@prinpay.com>

> From: openssl-dev On Behalf Of Nayna Jain
> Sent: Wednesday, June 10, 2015 20:31

> If I have a pem file with private key in that, how do I check if that is
RSA/DSA ?

If it uses a "legacy" format, the BEGIN line specifies the algorithm
-----BEGIN RSA PRIVATE KEY-----
-----BEGIN DSA PRIVATE KEY-----
-----BEGIN EC PRIVATE KEY-----

If it uses either PKCS#8 format: if unencrypted there is an
AlgorithmIdentifier 
field near the beginning that specifies the type of the key; if encrypted,
you 
must first decrypt and the decrypted value contains the AlgorithmIdentifier.

It's usually easier to let PEM_read_PrivateKey figure out for you. It reads
all 
formats (encrypted only if you provide the correct passphrase) and returns 
an EVP_PKEY object whose type you can check with EVP_PKEY_type 
following the instructions on the manpage for EVP_PKEY_type.




From ynir.ietf at gmail.com  Thu Jun 11 10:15:38 2015
From: ynir.ietf at gmail.com (Yoav Nir)
Date: Thu, 11 Jun 2015 13:15:38 +0300
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
	function (let's kill md5sum!)
In-Reply-To: <CAGiyFderL+pFSNOkuQHw3phnaRDYT3HtzF1O8UF-S2BL+xBciw@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <46C2109D-5CCE-4342-ABA9-B92DEC093358@gmail.com>
 <CAGiyFderL+pFSNOkuQHw3phnaRDYT3HtzF1O8UF-S2BL+xBciw@mail.gmail.com>
Message-ID: <3BF10419-323B-4387-96EC-96777BB6DB68@gmail.com>

That shouldn?t be too difficult (finding reviewers, I mean).

Is the ISE asking for volunteers to review? What kind of volunteers?  IMO what a reviewer needs to be able to say is:
 - The document is clear (you can implement based on this)
 - The algorithm might be useful in the IETF
 - The security claims are sufficient to what IETF protocols need
 - The security claims are backed up by either peer-reviewed academic papers or equivalent

So there?s a lot of people who can do all that. You don?t even need real cryptographers, although having at least one would be good. What is holding things up?

Yoav

> On Jun 11, 2015, at 11:50 AM, Jean-Philippe Aumasson <jeanphilippe.aumasson at gmail.com> wrote:
> 
> The status of the draft is unchanged ("Finding Reviewers"). Perhaps OpenSSL can speed up the review process.
> 
> BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace Poly1305. A BLAKE2 MAC can be customized wrt key or tag size, and can provide the highest security level for a give key/tag size combination.
> 
> 
> 
> On Thu, Jun 11, 2015 at 10:15 AM Yoav Nir <ynir.ietf at gmail.com <mailto:ynir.ietf at gmail.com>> wrote:
> 
> > On Jun 11, 2015, at 2:36 AM, Bill Cox <waywardgeek at google.com <mailto:waywardgeek at google.com>> wrote:
> >
> > BLAKE2 rocks.  I'm looking forward to using it in many applications.
> >
> 
> Sure. I would be glad to see that used as a hash in signatures and in TLS, as a PRF in TLS and IKE, etc.
> 
> Does anyone know what the status of draft-saarinen-blake2 is?  If that progresses we can propose things like TLS_ECDHE_EdDSA_WITH_CHACHA20_POLY1305_BLAKE2[*] or PRF_BLAKE2.
> 
> Yoav
> 
> [*] I think we should call that ciphersuite ?Suite-C? with ?C? standing for civilian, because this is a whole bunch of algorithms, none of which came from the government of the (pseudo-)military.
> 
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/2bf61bb6/attachment.html>

From openssl-users at dukhovni.org  Thu Jun 11 12:29:07 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 11 Jun 2015 12:29:07 +0000
Subject: [openssl-dev] [openssl-users] Is there openssl API to verify
 certificate content is DER or PEM format ?
In-Reply-To: <OFCE2F5514.7B32DA94-ON65257E61.0002C451-65257E61.0002E012@in.ibm.com>
References: <OF04312994.4A822603-ON65257E5F.0017A49C-65257E5F.0017F964@in.ibm.com>
 <20150609050347.GM5512@mournblade.imrryr.org>
 <OFCE5A81E7.08C1A23A-ON65257E60.0011F481-65257E60.00123010@in.ibm.com>
 <20150610044723.GB2050@mournblade.imrryr.org>
 <OFCE2F5514.7B32DA94-ON65257E61.0002C451-65257E61.0002E012@in.ibm.com>
Message-ID: <20150611122907.GI2050@mournblade.imrryr.org>

On Thu, Jun 11, 2015 at 06:01:26AM +0530, Nayna Jain wrote:

> I have similar concern for private key.
> If I have a pem file with private key in that, how do I check if that is
> RSA/DSA ?

In almost all cases don't check.  Just load and use the key as a
generic EVP_PKEY.

-- 
	Viktor.

From jimis at gmx.net  Thu Jun 11 13:37:11 2015
From: jimis at gmx.net (Dimitrios Apostolou)
Date: Thu, 11 Jun 2015 15:37:11 +0200 (CEST)
Subject: [openssl-dev] Build failure on SLES11
Message-ID: <alpine.DEB.2.11.1506111532080.3850@localhost>

Hello list,

I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system. 
It fails unless I configure with "no-asm". Here is the relevant output:

gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
ghash-x86_64.s: Assembler messages:
ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1'
ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0'
[ ... many identical errors omitted ]


I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is failing. 
Here is relevant output that might be of help:

$ uname -a
Linux buildslave3-sles-11-x86_64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU Binutils; SUSE Linux Enterprise 11) 2.19


Thanks in advance,
Dimitris


From foleyj at cisco.com  Thu Jun 11 13:47:20 2015
From: foleyj at cisco.com (John Foley)
Date: Thu, 11 Jun 2015 09:47:20 -0400
Subject: [openssl-dev] Build failure on SLES11
In-Reply-To: <alpine.DEB.2.11.1506111532080.3850@localhost>
References: <alpine.DEB.2.11.1506111532080.3850@localhost>
Message-ID: <55799168.2080705@cisco.com>

It could be the gcc version is too old.  Trying to recall, gcc needs to
be something like 4.4 or newer to support the Intel carry-less multiply
instruction.



On 06/11/2015 09:37 AM, Dimitrios Apostolou wrote:
> Hello list,
>
> I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
> It fails unless I configure with "no-asm". Here is the relevant output:
>
> gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
> -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
> ghash-x86_64.s: Assembler messages:
> ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
> $17,%xmm2,%xmm0,%xmm1'
> ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
> $0,%xmm2,%xmm0,%xmm0'
> [ ... many identical errors omitted ]
>
>
> I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
> failing. Here is relevant output that might be of help:
>
> $ uname -a
> Linux buildslave3-sles-11-x86_64 2.6.27.19-5-default #1 SMP 2009-02-28
> 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
> GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
> Binutils; SUSE Linux Enterprise 11) 2.19
>
>
> Thanks in advance,
> Dimitris
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


From yarlagadda-srinivasa.rao at hp.com  Thu Jun 11 13:57:31 2015
From: yarlagadda-srinivasa.rao at hp.com (Rao, Yarlagadda Srinivasa (MCOU))
Date: Thu, 11 Jun 2015 13:57:31 +0000
Subject: [openssl-dev] [PATCH] logjam vulnerability changes for 0.9.8f
	version
Message-ID: <3FE41DD5335EE44C9B8CE38861849F3F81C4C9BD@G4W3305.americas.hpqcorp.net>

Hello All,

This patch fixes/back port the DH parameters changes from 1.0.1 stable branch to 0.9.8f version.

-----------------------------------------------------------------------------------
$ cat /tmp/patch.txt
--- s3_clnt.c_org       2015-06-10 14:27:54.000000000 +0530
+++ s3_clnt.c   2015-06-11 08:05:46.000000000 +0530
@@ -2575,22 +2575,31 @@
     }
#endif
#ifndef OPENSSL_NO_DH
-    if ((algs & SSL_kEDH) &&
-        !(has_bits(i, EVP_PK_DH | EVP_PKT_EXCH) || (dh != NULL))) {
-        SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, SSL_R_MISSING_DH_KEY);
+    if ((algs & SSL_kEDH) && dh == NULL) {
+        SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, ERR_R_INTERNAL_ERROR);
         goto f_err;
-    } else if ((algs & SSL_kDHr) && !has_bits(i, EVP_PK_DH | EVP_PKS_RSA)) {
+    }
+    if ((algs & SSL_kDHr) && !has_bits(i, EVP_PK_DH | EVP_PKS_RSA)) {
         SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,
                SSL_R_MISSING_DH_RSA_CERT);
         goto f_err;
     }
# ifndef OPENSSL_NO_DSA
-    else if ((algs & SSL_kDHd) && !has_bits(i, EVP_PK_DH | EVP_PKS_DSA)) {
+    if ((algs & SSL_kDHd) && !has_bits(i, EVP_PK_DH | EVP_PKS_DSA)) {
         SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM,
                SSL_R_MISSING_DH_DSA_CERT);
         goto f_err;
     }
# endif
+    /* Check DHE only: static DH not implemented. */
+    if (algs & SSL_kEDH) {
+        int dh_size = BN_num_bits(dh->p);
+        if ((!SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && dh_size < 768)
+            || (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && dh_size < 512)) {
+            SSLerr(SSL_F_SSL3_CHECK_CERT_AND_ALGORITHM, SSL_R_DH_KEY_TOO_SMALL);
+            goto f_err;
+        }
+    }
#endif

     if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && !has_bits(i, EVP_PKT_EXP)) {
--- ssl.h_org   2015-06-10 14:24:27.000000000 +0530
+++ ssl.h       2015-06-11 08:05:28.000000000 +0530
@@ -2036,6 +2036,7 @@
# define SSL_R_DATA_LENGTH_TOO_LONG                       146
# define SSL_R_DECRYPTION_FAILED                          147
# define SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC        281
+# define SSL_R_DH_KEY_TOO_SMALL                           372
# define SSL_R_DH_PUBLIC_VALUE_LENGTH_IS_WRONG            148
# define SSL_R_DIGEST_CHECK_FAILED                        149
# define SSL_R_DTLS_MESSAGE_TOO_BIG                       318
--- ssl_err.c_org       2015-06-10 14:21:03.000000000 +0530
+++ ssl_err.c   2015-06-11 08:05:21.000000000 +0530
@@ -390,6 +390,7 @@
     {ERR_REASON(SSL_R_DECRYPTION_FAILED), "decryption failed"},
     {ERR_REASON(SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC),
      "decryption failed or bad record mac"},
+    {ERR_REASON(SSL_R_DH_KEY_TOO_SMALL), "dh key too small"},
     {ERR_REASON(SSL_R_DH_PUBLIC_VALUE_LENGTH_IS_WRONG),
      "dh public value length is wrong"},
     {ERR_REASON(SSL_R_DIGEST_CHECK_FAILED), "digest check failed"},
--- dhparam.c_org       2015-06-10 14:17:53.000000000 +0530
+++ dhparam.c   2015-06-11 08:04:47.000000000 +0530
@@ -130,7 +130,7 @@
# undef PROG
# define PROG    dhparam_main

-# define DEFBITS 512
+# define DEFBITS 2048

/*-
  * -inform arg  - input format - default PEM (DER or PEM)
@@ -254,7 +254,7 @@
         BIO_printf(bio_err,
                    " -5            generate parameters using  5 as the generator value\n");
         BIO_printf(bio_err,
-                   " numbits       number of bits in to generate (default 512)\n");
+                   " numbits       number of bits in to generate (default 2048)\n");
# ifndef OPENSSL_NO_ENGINE
         BIO_printf(bio_err,
                    " -engine e     use engine e, possibly a hardware device.\n");
--- gendh.c_org 2015-06-10 14:18:31.000000000 +0530
+++ gendh.c     2015-06-11 08:04:55.000000000 +0530
@@ -80,7 +80,7 @@
# include <openssl/x509.h>
# include <openssl/pem.h>

-# define DEFBITS 512
+# define DEFBITS 2048
# undef PROG
# define PROG gendh_main

--- s_server.c_org      2015-06-10 14:16:40.000000000 +0530
+++ s_server.c  2015-06-11 08:04:38.000000000 +0530
@@ -197,7 +197,7 @@
                                unsigned int *id_len);
#ifndef OPENSSL_NO_DH
static DH *load_dh_param(const char *dhfile);
-static DH *get_dh512(void);
+static DH *get_dh2048(void);
#endif

#ifdef MONOLITH
@@ -213,30 +213,48 @@
#endif

#ifndef OPENSSL_NO_DH
-static unsigned char dh512_p[] = {
-    0xDA, 0x58, 0x3C, 0x16, 0xD9, 0x85, 0x22, 0x89, 0xD0, 0xE4, 0xAF, 0x75,
-    0x6F, 0x4C, 0xCA, 0x92, 0xDD, 0x4B, 0xE5, 0x33, 0xB8, 0x04, 0xFB, 0x0F,
-    0xED, 0x94, 0xEF, 0x9C, 0x8A, 0x44, 0x03, 0xED, 0x57, 0x46, 0x50, 0xD3,
-    0x69, 0x99, 0xDB, 0x29, 0xD7, 0x76, 0x27, 0x6B, 0xA2, 0xD3, 0xD4, 0x12,
-    0xE2, 0x18, 0xF4, 0xDD, 0x1E, 0x08, 0x4C, 0xF6, 0xD8, 0x00, 0x3E, 0x7C,
-    0x47, 0x74, 0xE8, 0x33,
+static unsigned char dh2048_p[] = {
+    0xF6,0x42,0x57,0xB7,0x08,0x7F,0x08,0x17,0x72,0xA2,0xBA,0xD6,
+    0xA9,0x42,0xF3,0x05,0xE8,0xF9,0x53,0x11,0x39,0x4F,0xB6,0xF1,
+    0x6E,0xB9,0x4B,0x38,0x20,0xDA,0x01,0xA7,0x56,0xA3,0x14,0xE9,
+    0x8F,0x40,0x55,0xF3,0xD0,0x07,0xC6,0xCB,0x43,0xA9,0x94,0xAD,
+    0xF7,0x4C,0x64,0x86,0x49,0xF8,0x0C,0x83,0xBD,0x65,0xE9,0x17,
+    0xD4,0xA1,0xD3,0x50,0xF8,0xF5,0x59,0x5F,0xDC,0x76,0x52,0x4F,
+    0x3D,0x3D,0x8D,0xDB,0xCE,0x99,0xE1,0x57,0x92,0x59,0xCD,0xFD,
+    0xB8,0xAE,0x74,0x4F,0xC5,0xFC,0x76,0xBC,0x83,0xC5,0x47,0x30,
+    0x61,0xCE,0x7C,0xC9,0x66,0xFF,0x15,0xF9,0xBB,0xFD,0x91,0x5E,
+    0xC7,0x01,0xAA,0xD3,0x5B,0x9E,0x8D,0xA0,0xA5,0x72,0x3A,0xD4,
+    0x1A,0xF0,0xBF,0x46,0x00,0x58,0x2B,0xE5,0xF4,0x88,0xFD,0x58,
+    0x4E,0x49,0xDB,0xCD,0x20,0xB4,0x9D,0xE4,0x91,0x07,0x36,0x6B,
+    0x33,0x6C,0x38,0x0D,0x45,0x1D,0x0F,0x7C,0x88,0xB3,0x1C,0x7C,
+    0x5B,0x2D,0x8E,0xF6,0xF3,0xC9,0x23,0xC0,0x43,0xF0,0xA5,0x5B,
+    0x18,0x8D,0x8E,0xBB,0x55,0x8C,0xB8,0x5D,0x38,0xD3,0x34,0xFD,
+    0x7C,0x17,0x57,0x43,0xA3,0x1D,0x18,0x6C,0xDE,0x33,0x21,0x2C,
+    0xB5,0x2A,0xFF,0x3C,0xE1,0xB1,0x29,0x40,0x18,0x11,0x8D,0x7C,
+    0x84,0xA7,0x0A,0x72,0xD6,0x86,0xC4,0x03,0x19,0xC8,0x07,0x29,
+    0x7A,0xCA,0x95,0x0C,0xD9,0x96,0x9F,0xAB,0xD0,0x0A,0x50,0x9B,
+    0x02,0x46,0xD3,0x08,0x3D,0x66,0xA4,0x5D,0x41,0x9F,0x9C,0x7C,
+    0xBD,0x89,0x4B,0x22,0x19,0x26,0xBA,0xAB,0xA2,0x5E,0xC3,0x55,
+    0xE9,0x32,0x0B,0x3B,
};

-static unsigned char dh512_g[] = {
+static unsigned char dh2048_g[] = {
     0x02,
};

-static DH *get_dh512(void)
+DH *get_dh2048(void)
{
-    DH *dh = NULL;
+    DH *dh;

     if ((dh = DH_new()) == NULL)
-        return (NULL);
-    dh->p = BN_bin2bn(dh512_p, sizeof(dh512_p), NULL);
-    dh->g = BN_bin2bn(dh512_g, sizeof(dh512_g), NULL);
-    if ((dh->p == NULL) || (dh->g == NULL))
-        return (NULL);
-    return (dh);
+        return NULL;
+    dh->p = BN_bin2bn(dh2048_p, sizeof(dh2048_p), NULL);
+    dh->g = BN_bin2bn(dh2048_g, sizeof(dh2048_g), NULL);
+    if (dh->p == NULL || dh->g == NULL) {
+        DH_free(dh);
+        return NULL;
+    }
+    return dh;
}
#endif

@@ -1343,7 +1361,11 @@
             BIO_printf(bio_s_out, "Setting temp DH parameters\n");
         } else {
             BIO_printf(bio_s_out, "Using default temp DH parameters\n");
-            dh = get_dh512();
+            dh = get_dh2048();
+            if (dh == NULL) {
+                ERR_print_errors(bio_err);
+                goto end;
+            }
         }
         (void)BIO_flush(bio_s_out);

$
---------------------------------------------------------------------

After applying the above patch to 0.9.8f, I could find the following o/p from the test logs.

Step-1: Generate DH parameters with 767 and 512 bits.
openssl dhparam -out dh767.pem 767
openssl dhparam -out dh512.pem 512

Step-2: Start openssl s_server with the above created DH parameters.
openssl   s_server  -dhparam  dh767.pem -accept 1234 -cert server.crt -key server.key

Step-3: connect s_client to the above server
openssl s_client -connect x.x.x.x:1234

Following error shows in the s_client side:
20422:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:2599:

And from s_server side shows following error message.
ERROR
23019:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1143:SSL alert number 40
shutting down SSL

Step-4: start s_server  with DH parameters more than 767 bits (Example 1024 and 768)
openssl   s_server  -dhparam  dh1024.pem -accept 1234 -cert server.crt -key server.key

Step-5: connect s_client to the above server

The connection succeeds without any error messages.

>From the above test logs, It looks like the changes are working fine.

Can someone help me to validate the changes?
If the changes are fine, then I can submit the same changes to 0.9.8 stable branch. So that it will be available in the next release.

Thanks & Regards,
Vasu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/27714fc0/attachment-0001.html>

From appro at openssl.org  Thu Jun 11 14:06:33 2015
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 11 Jun 2015 16:06:33 +0200
Subject: [openssl-dev] Build failure on SLES11
In-Reply-To: <55799168.2080705@cisco.com>
References: <alpine.DEB.2.11.1506111532080.3850@localhost>
 <55799168.2080705@cisco.com>
Message-ID: <557995E9.5090004@openssl.org>

> It could be the gcc version is too old.  Trying to recall, gcc needs to
> be something like 4.4 or newer to support the Intel carry-less multiply
> instruction.

It's pure assembler issue, not compiler. You can compile the module with
gcc 3.x if you wish (I actually do) as long as you have new enough 'as'
on your $PATH.

>> I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
>> It fails unless I configure with "no-asm". Here is the relevant output:
>>
>> ghash-x86_64.s: Assembler messages:
>> ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
>> $17,%xmm2,%xmm0,%xmm1'
>> ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
>> $0,%xmm2,%xmm0,%xmm0'
>> [ ... many identical errors omitted ]
>>
>>
>> I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
>> failing. Here is relevant output that might be of help:
>>
>> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
>> GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
>> Binutils; SUSE Linux Enterprise 11) 2.19

It's can as well be wrong. I mean it might have to be adjusted as
$1>=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
they might have omitted specifically vpclmulqdq. Can you confirm if it
works if you replace 2.19 with 2.20?


From uri at ll.mit.edu  Thu Jun 11 14:25:44 2015
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 11 Jun 2015 14:25:44 +0000
Subject: [openssl-dev] Build failure on SLES11
Message-ID: <20150611142552.17879106.63944.2476@ll.mit.edu>

Just to let you ?know that I thoroughly enjoyed your reply. :-)

Sent?from?my?BlackBerry?10?smartphone?on?the?Verizon Wireless?4G?LTE?network.

? Original Message ?
From: Andy Polyakov
Sent: Thursday, June 11, 2015 10:14
To: openssl-dev at openssl.org
Reply To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Build failure on SLES11

> It could be the gcc version is too old. Trying to recall, gcc needs to
> be something like 4.4 or newer to support the Intel carry-less multiply
> instruction.

It's pure assembler issue, not compiler. You can compile the module with
gcc 3.x if you wish (I actually do) as long as you have new enough 'as'
on your $PATH.

>> I've been trying to build OpenSSL-1.0.2a on an outdated SLES11 system.
>> It fails unless I configure with "no-asm". Here is the relevant output:
>>
>> ghash-x86_64.s: Assembler messages:
>> ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq
>> $17,%xmm2,%xmm0,%xmm1'
>> ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq
>> $0,%xmm2,%xmm0,%xmm0'
>> [ ... many identical errors omitted ]
>>
>>
>> I believe a check inside ./crypto/modes/asm/ghash-x86_64.pl is
>> failing. Here is relevant output that might be of help:
>>
>> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
>> GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU
>> Binutils; SUSE Linux Enterprise 11) 2.19

It's can as well be wrong. I mean it might have to be adjusted as
$1>=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
they might have omitted specifically vpclmulqdq. Can you confirm if it
works if you replace 2.19 with 2.20?

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/3526ed33/attachment.bin>

From openssl at openssl.org  Thu Jun 11 14:45:55 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 11 Jun 2015 14:45:55 +0000
Subject: [openssl-dev] OpenSSL version 0.9.8zg released
Message-ID: <20150611144555.GA15788@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 0.9.8zg 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.8zg of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-0.9.8-notes.html

   OpenSSL 0.9.8zg 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.8zg.tar.gz
      Size: 3826891
      MD5 checksum: 0a912b6623ac95a8627ea2bd0e0abf1b
      SHA1 checksum: a73005583ba8d5edc3bdcc1f99a1e33ee0ed41f8

   The checksums were calculated using the following commands:

    openssl md5 openssl-0.9.8zg.tar.gz
    openssl sha1 openssl-0.9.8zg.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZkpAAoJENnE0m0OYESRzLcIAKhsW3bm1latn1wLoQk0cJEf
GQVf9ztRkxivgodycUYhkuGhq2O+djeYHqKMXnedso+KnkgE/FnhTbDkyX6G12bs
H17ZMgWOIypjHnwGW6jT1GlH+qb9tlzJYAuqsIEbG+hwE5KIsUrwtjAb1MhUuZFC
f11jP5VFf4YXsN681TdyXxlhIdmeImiIDMjsVMGLIZ12zDV6AEJ4LrLkyyaaJxnd
cryKY+Ai4AqBW3Mnv/tVddDvUdgmvjyNHBXEyBUkhy8oIpHe33RMLmGyK6w4P6os
rTKsQzliZ8FSmBfbrOeFUTfPh/N1POqTcWV4VEBjD7mNZbnk3dHQZ3eFLBz8QGs=
=kj2n
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Jun 11 14:46:33 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 11 Jun 2015 14:46:33 +0000
Subject: [openssl-dev] OpenSSL version 1.0.0s released
Message-ID: <20150611144633.GA15893@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.0s 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 1.0.0s of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.0-notes.html

   OpenSSL 1.0.0s 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-1.0.0s.tar.gz
      Size: 4102101
      MD5 checksum: fe54d58a42c6aa1c7a587378e27072f3
      SHA1 checksum: 3df4b9a87c0a37e6fd589360f9d43a6be2252b62

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.0s.tar.gz
    openssl sha1 openssl-1.0.0s.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZeTAAoJENnE0m0OYESR/qoIAJRa63Si5UbI8hrJVsTCDAb6
VBfb40NrzOA3x7XpsS1MQxHK9ixPokdhMSHsjAkk4D3tz703I5ig9BDymWr8U2tF
2XvNKm4JBwn8SGfPgI/sy+YgaD0Adzt84eeAek+elPReAdQZGTJ83YFbycs8tSH5
g35JNrEOO8eXADq1WTsM3iqgPt4rXW7RJFQuI4yOtZZA1aqeD+d3WGQTopglt5Az
/+CVViskrnlBihRiOZKfEk4qinB0s7TIJPZifPRzDFdhvMqz6VIndYsPmFhgQMSn
jkhhwHhNB/NXZyNUGBdrxeq2ySX88ObXFlMvUAHFnj0CpaGuHyA2XIEL3vmHdtg=
=8O7B
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Jun 11 14:46:51 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 11 Jun 2015 14:46:51 +0000
Subject: [openssl-dev] OpenSSL version 1.0.1n released
Message-ID: <20150611144651.GA15919@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.1n 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 1.0.1n of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1n 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-1.0.1n.tar.gz
      Size: 4545564
      MD5 checksum: 139568bd5a56fa49b72a290d37113f30
      SHA1 checksum: 2f6ea1e0f2724aca1805392e4387df8361442ace

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.1n.tar.gz
    openssl sha1 openssl-1.0.1n.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZWaAAoJENnE0m0OYESRqlwIAJ1ncajYk0swYcFxXEbCs02q
dI220NF3q9ohvXSzUVvM18Az8Lrr4u/bkZUNhmWkW2GwY7HF6DHUzgg7yWTWZ3h3
pxz33OxxNhBdXA0bkIl4d8q8SW9m7Xo+JZ2Pky2BC8MO3FTd5N8p9zfyJY63dtYV
W9pOV0M/LzD3CkFMyX1NdAsoy3KNxB4NFoGKxuaYyOSwyrYCkHBXsBZM5O4BhvDt
JeZMAcZagu4kNZ9fdNDNo28AxSOQicGuCqW4SOYnC/XACcsVvpuZYvMFdoqDRBN4
vWS91UAoor1Ld2IsdNsqe2D7S/35NKokvxdeUjbPKzyxPMoX5sgtJJyQZ6IUM0s=
=d4VL
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Jun 11 14:47:08 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 11 Jun 2015 14:47:08 +0000
Subject: [openssl-dev] OpenSSL version 1.0.2b released
Message-ID: <20150611144708.GA16030@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.2b 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 1.0.2b of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2b 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-1.0.2b.tar.gz
      Size: 5281009
      MD5 checksum: 7729b259e2dea7d60b32fc3934d6984b
      SHA1 checksum: 9006e53ca56a14d041e3875320eedfa63d82aba7

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.2b.tar.gz
    openssl sha1 openssl-1.0.2b.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZNdAAoJENnE0m0OYESRYscIAKrJik5qyPifnVhWRHVTUXot
NYhfl+h+ooHequRyz9ug7Wz3vdUioftuOYlX0eJBBZ+YvskVk27U9tjY+plFnRjq
vpdNKfa6bSL9rjztZObupvbCnhYRdDkcJRqLi8HfPb53UlZS/ALIbpDi1FPqIErs
Bc7D/toD0nDoQUONLVQw/aSZNWWCaACO09326K2xX/jZGEsQbhCWdlkERfO3RzRW
RBN0RnR+k8XBaqy6TRELF1vlYdHe83Dqxg1h3KBTBJ+yOFXvQblPoZO4GnkAyoNA
8EGhbzgWsjg6OIroUbnbbq50avvya/2eDmY+N3gNg5wOrYBNZlWShy91WGZ4378=
=rcRW
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Jun 11 14:49:11 2015
From: openssl at openssl.org (OpenSSL)
Date: Thu, 11 Jun 2015 14:49:11 +0000
Subject: [openssl-dev] OpenSSL Security Advisory
Message-ID: <20150611144911.GA16575@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenSSL Security Advisory [11 Jun 2015]
=======================================

DHE man-in-the-middle protection (Logjam)
====================================================================

A vulnerability in the TLS protocol allows a man-in-the-middle
attacker to downgrade vulnerable TLS connections using ephemeral
Diffie-Hellman key exchange to 512-bit export-grade cryptography. This
vulnerability is known as Logjam (CVE-2015-4000).

OpenSSL has added protection for TLS clients by rejecting handshakes
with DH parameters shorter than 768 bits. This limit will be increased
to 1024 bits in a future release.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n

Fixes for this issue were developed by Emilia K??sper and Kurt Roeckx
of the OpenSSL development team.

Malformed ECParameters causes infinite loop (CVE-2015-1788)
===========================================================

Severity: Moderate

When processing an ECParameters structure OpenSSL enters an infinite loop if
the curve specified is over a specially malformed binary polynomial field.

This can be used to perform denial of service against any
system which processes public keys, certificate requests or
certificates.  This includes TLS clients and TLS servers with
client authentication enabled.

This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent
1.0.0 and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are
affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0d (and below) users should upgrade to 1.0.0s
OpenSSL 0.9.8r (and below) users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 6th April 2015 by Joseph Birr-Pixton. The
fix was developed by Andy Polyakov of the OpenSSL development team.

Exploitable out-of-bounds read in X509_cmp_time (CVE-2015-1789)
===============================================================

Severity: Moderate

X509_cmp_time does not properly check the length of the ASN1_TIME
string and can read a few bytes out of bounds. In addition,
X509_cmp_time accepts an arbitrary number of fractional seconds in the
time string.

An attacker can use this to craft malformed certificates and CRLs of
various sizes and potentially cause a segmentation fault, resulting in
a DoS on applications that verify certificates or CRLs. TLS clients
that verify CRLs are affected. TLS clients and servers with client
authentication enabled may be affected if they use custom verification
callbacks.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 8th April 2015 by Robert Swiecki
(Google), and independently on 11th April 2015 by Hanno B??ck. The fix
was developed by Emilia K??sper of the OpenSSL development team.

PKCS7 crash with missing EnvelopedContent (CVE-2015-1790)
=========================================================

Severity: Moderate

The PKCS#7 parsing code does not handle missing inner EncryptedContent
correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs
with missing content and trigger a NULL pointer dereference on parsing.

Applications that decrypt PKCS#7 data or otherwise parse PKCS#7
structures from untrusted sources are affected. OpenSSL clients and
servers are not affected.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 18th April 2015 by  Michal
Zalewski (Google). The fix was developed by Emilia K??sper of the
OpenSSL development team.

CMS verify infinite loop with unknown hash function (CVE-2015-1792)
===================================================================

Severity: Moderate

When verifying a signedData message the CMS code can enter an infinite loop
if presented with an unknown hash function OID.

This can be used to perform denial of service against any system which
verifies signedData messages using the CMS code.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 31st March 2015 by Johannes Bauer. The
fix was developed by Dr. Stephen Henson of the OpenSSL development team.

Race condition handling NewSessionTicket (CVE-2015-1791)
========================================================

Severity: Low

If a NewSessionTicket is received by a multi-threaded client when attempting to
reuse a previous ticket then a race condition can occur potentially leading to
a double free of the ticket data.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was discovered by Emilia K??sper of the OpenSSL development team. The
fix was developed by Matt Caswell of the OpenSSL development team.

Invalid free in DTLS (CVE-2014-8176)
====================================

Severity: Moderate

This vulnerability does not affect current versions of OpenSSL. It
existed in previous OpenSSL versions and was fixed in June 2014.

If a DTLS peer receives application data between the ChangeCipherSpec
and Finished messages, buffering of such data may cause an invalid
free, resulting in a segmentation fault or potentially, memory
corruption.

This issue affected older OpenSSL versions 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

This issue was originally reported on March 28th 2014 in
https://rt.openssl.org/Ticket/Display.html?id=3286 by Praveen
Kariyanahalli, and subsequently by Ivan Fratric and Felix Groebert
(Google). A fix was developed by zhu qun-ying.

The fix for this issue can be identified by commits bcc31166 (1.0.1),
b79e6e3a (1.0.0) and 4b258e73 (0.9.8).

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
releases will be provided after that date. Users of these releases are advised
to upgrade.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150611.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVeZq1AAoJENnE0m0OYESRESoIAJWIeqHHDd83ONNpXGeythDj
F7DTzlKkOx+URajAOBme+XNFJSqe71kBHk8uY7ZSZcindLcVxIHEXY3S0z2qGc1B
3SsOo71TsvReIuMN8mV2fq2MDEvPpbi5fSCND1OqR5C7kGafWvUtM9TneyuB4Mu6
ktvitpJtJ/TNUXo1+50HufR3boveQzZo6Sf1KFCK5jWROaiwolTTjHQNk9aPItEz
fgS7YmbHToBqnhK/JyRip7T9UlBJ2LVUoCqiQoZZ3abAbAAfBycjoXfalEQ53wde
V6LUE36D1viTIG5OcIGbbUEcMkWbTQU7KISz+IocZ2e1KEAU0CCP54qi6rgazrQ=
=aQnm
-----END PGP SIGNATURE-----

From jimis at gmx.net  Thu Jun 11 15:08:56 2015
From: jimis at gmx.net (Dimitrios Apostolou)
Date: Thu, 11 Jun 2015 17:08:56 +0200 (CEST)
Subject: [openssl-dev] Build failure on SLES11
In-Reply-To: <557995E9.5090004@openssl.org>
References: <alpine.DEB.2.11.1506111532080.3850@localhost>
 <55799168.2080705@cisco.com> <557995E9.5090004@openssl.org>
Message-ID: <alpine.DEB.2.11.1506111708000.3850@localhost>

On Thu, 11 Jun 2015, Andy Polyakov wrote:

> It's can as well be wrong. I mean it might have to be adjusted as
> $1>=2.20 instead of 2.19. While AVX support was added in binutils 2.19,
> they might have omitted specifically vpclmulqdq. Can you confirm if it
> works if you replace 2.19 with 2.20?


Indeed, I confirm that the following patch fixes the issue:


--- crypto/modes/asm/ghash-x86_64.pl.bak	2015-06-11 
17:04:21.000000000 +0200
+++ crypto/modes/asm/ghash-x86_64.pl	2015-06-11 17:04:28.000000000 
+0200
@@ -92,7 +92,7 @@

  if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1`
  		=~ /GNU assembler version ([2-9]\.[0-9]+)/) {
-	$avx = ($1>=2.19) + ($1>=2.22);
+	$avx = ($1>=2.20) + ($1>=2.22);
  }

  if (!$avx && $win64 && ($flavour =~ /nasm/ || $ENV{ASM} =~ /nasm/) &&



Dimitris


From rainer.jung at kippdata.de  Thu Jun 11 17:02:49 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Thu, 11 Jun 2015 19:02:49 +0200
Subject: [openssl-dev] OpenSSL version 1.0.2b released
In-Reply-To: <20150611144708.GA16030@openssl.org>
References: <20150611144708.GA16030@openssl.org>
Message-ID: <5579BF39.8030504@kippdata.de>

The release notes mentioned and linked in all of the four release 
announcements still contain stale text:

https://www.openssl.org/news/openssl-1.0.2-notes.html
https://www.openssl.org/news/openssl-1.0.1-notes.html
https://www.openssl.org/news/openssl-1.0.0-notes.html
https://www.openssl.org/news/openssl-0.9.8-notes.html

The current release simply looks like

  Major changes between OpenSSL 1.0.2a and OpenSSL 1.0.2b [under 
development]

-

Major changes between OpenSSL 1.0.2 and OpenSSL 1.0.2a [19 Mar 2015]
...

So all entries for todays releases are still missing.

Maybe it is on its way, but since the announcement was 2 hours ago and 
the pages are linked in them I thought I'd better let you know.

Regards,

Rainer

From waywardgeek at google.com  Thu Jun 11 18:53:13 2015
From: waywardgeek at google.com (Bill Cox)
Date: Thu, 11 Jun 2015 11:53:13 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <5578D4B8.90901@dei.uc.pt>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <5578D4B8.90901@dei.uc.pt>
Message-ID: <CAH9QtQHtr1A_5VgFZtOm5evT0bstW4VzYLnuB8=dtRpRLK10+Q@mail.gmail.com>

On Wed, Jun 10, 2015 at 5:22 PM, Samuel Neves <sneves at dei.uc.pt> wrote:

> Andrew Moon's code, linked  by Zooko, appears to be that (though the
> implementation is different from mine) plus some extra massaging to handle
> different calling conventions and ABIs. It is pretty good.
>

Just adding Andrew Moon (who hopefully is available) to the conversation.

Andrew, I have some cycles to help integrate Blake2s and Blake2b into
OpenSSL.  I see you've done a ton of work optimizing Blake2 in assembly for
different platforms.  Which code would you recommend starting with for
OpenSSL?  I see lots of SSE and AVX/AVX2 support in OpenSSL for SHA512, as
well as ARM v4, v8 (and others).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/a02827c9/attachment.html>

From sdaoden at yandex.com  Thu Jun 11 19:59:28 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Thu, 11 Jun 2015 21:59:28 +0200
Subject: [openssl-dev] OpenSSL Security Advisory
In-Reply-To: <20150611144911.GA16575@openssl.org>
References: <20150611144911.GA16575@openssl.org>
Message-ID: <20150611195928.HL-ixvmMziBa%sdaoden@yandex.com>

Huhu!!

 |Fixes for this issue were developed by Emilia K??sper and Kurt Roeckx

I just want to mention these ?UTF-8 re-encoded as UTF-8? issues,
which may be acceptable for names of males, but, but
*particularly* with respect to the natural beauty of the affected
person?  On the other hand i always knew engineers have the
etiquettes of construction workers.
The good news: it seems to be a long way to Boko Haram.  Still.


Also it is a real pity that it seems to be too hard to copy and
paste the NEWS.  And now it didn't even help to point one of those
HTML monsters to the cesspool.
Wait.  I haven't said there is a coincidence.


(^_^)/"

--steffen

From rt at openssl.org  Thu Jun 11 20:34:37 2015
From: rt at openssl.org (starlight.2015q2@binnacle.cx via RT)
Date: Thu, 11 Jun 2015 20:34:37 +0000
Subject: [openssl-dev] [openssl.org #3902] #3423: Undefined behavior in
	crypto/cast/c_enc.c
In-Reply-To: <6.2.5.6.2.20150611163323.083682a8@binnacle.cx>
References: <RT-Ticket-3902@openssl.org>
 <6.2.5.6.2.20150611163323.083682a8@binnacle.cx>
Message-ID: <rt-4.0.19-12424-1434054877-727.3902-21-0@openssl.org>

Hello,

FYI using gcc 4.9.2 on x86_64 AMD

after Configure added

   -flto
   -g
   -fstack-protector-all --param ssp-buffer-size=1
   -fsanitize=address
   -fsanitize=undefined
   -fasynchronous-unwind-tables
   -DOPENSSL_NO_BUF_FREELIST

and 'make test' fails with old bug marked "resolved"

  3423: Undefined behavior in crypto/cast/c_enc.c



started with

./Configure \
    linux-x86_64 \
    enable-ec_nistp_64_gcc_128 \
    shared \
    threads \
    zlib \
    no-ssl2 \
    no-ssl3 \
    no-exp-edh-rsa-des-cbc-sha \
    no-exp-edh-dss-des-cbc-sha \
    no-exp-des-cbc-sha \
    no-exp-rc2-cbc-md5 \
    no-exp-rc4-md5 \
    --openssldir=/usr/local/openssl-1.0.2

Regards

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From kannanar at cisco.com  Thu Jun 11 21:43:24 2015
From: kannanar at cisco.com (Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco))
Date: Thu, 11 Jun 2015 21:43:24 +0000
Subject: [openssl-dev] Openssl Poodle Vulnerability Clarification
Message-ID: <AF70C7F70D95C54BAF2FCD161BADF2EB251EF249@xmb-aln-x13.cisco.com>

Hi All,

To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our application we have using openSSL through Apache. We have disabled using the below lines.

SSLProtocol all -SSLv2 -SSLv3

We are using 443 as SSL port. The command openssl s_client -connect <IPAddress>:443 -ssl3 shows the handshake failure message for 443 port. But for the ports 3333 and 4444 is connecting using SSLv3. The scanner as well report the high severity risk for those ports. In our application we are using those ports for syslog related tasks. If we change the port some other, then the scanner shows the new port in the list.

How to disable the SSLv3 connection for those ports as well since may customers are waiting for the fix. Your suggestion is much appreciated. 

Thanks,
Kannan Narayanasamy.


From kurt at roeckx.be  Thu Jun 11 22:07:25 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 12 Jun 2015 00:07:25 +0200
Subject: [openssl-dev] Openssl Poodle Vulnerability Clarification
In-Reply-To: <AF70C7F70D95C54BAF2FCD161BADF2EB251EF249@xmb-aln-x13.cisco.com>
References: <AF70C7F70D95C54BAF2FCD161BADF2EB251EF249@xmb-aln-x13.cisco.com>
Message-ID: <20150611220725.GA18105@roeckx.be>

On Thu, Jun 11, 2015 at 09:43:24PM +0000, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
> Hi All,
> 
> To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our application we have using openSSL through Apache. We have disabled using the below lines.
> 
> SSLProtocol all -SSLv2 -SSLv3
> 
> We are using 443 as SSL port. The command openssl s_client -connect <IPAddress>:443 -ssl3 shows the handshake failure message for 443 port. But for the ports 3333 and 4444 is connecting using SSLv3. The scanner as well report the high severity risk for those ports. In our application we are using those ports for syslog related tasks. If we change the port some other, then the scanner shows the new port in the list.
> 
> How to disable the SSLv3 connection for those ports as well since may customers are waiting for the fix. Your suggestion is much appreciated. 

There are 2 solutions:
- Change the configuration of syslog to disable SSLv3.  Not sure
  it can actually be configured.
- Build your openssl with SSLv3 disabled.


Kurt


From rt at openssl.org  Thu Jun 11 22:44:24 2015
From: rt at openssl.org (Jules Villard via RT)
Date: Thu, 11 Jun 2015 22:44:24 +0000
Subject: [openssl-dev] [openssl.org #3903] Infer run on openssl-1.0.2a
In-Reply-To: <20150611222429.GA2385@pauvre.org>
References: <RT-Ticket-3903@openssl.org> <20150611222429.GA2385@pauvre.org>
Message-ID: <rt-4.0.19-12424-1434062664-1624.3903-21-0@openssl.org>

Hello,

The following 13 potential null-pointer dereference bugs were found by
running Facebook's Infer static analyzer on openssl-1.0.2a. You can
reproduce these reports by downloading Infer and running it like so:

  https://fbinfer.org/docs/getting-started.html
  cd openssl-1.0.2a
  ./config && make clean
  infer -- make
  inferTraceBugs

The last command allows you to see more information about each report,
in particular symbolic traces that lead to the bug.

- apps/srp.c at line 149: NULL_DEREFERENCE
    pointer pp last assigned on line 148 could be null and is dereferenced at line 149, column 43

  apps/srp.c at line 166: NULL_DEREFERENCE
    pointer pp last assigned on line 164 could be null and is dereferenced at line 166, column 13

  The functions print_entry and print_user don't check that
  db->data->data is not NULL, hence sk_OPENSSL_PSTRING_value could
  return NULL.

  Additional note: the test is slightly different in both cases:
  "verbose > 0" for print_user vs "indx >= 0 && verbose" for
  print_entry.

- apps/x509.c at line 1108: NULL_DEREFERENCE
    pointer upkey last assigned on line 1107 could be null and is dereferenced by call to EVP_PKEY_copy_parameters() at line 1108, column 5

  Calling x509_certify() with xca == NULL or xca->cert_info == NULL
  makes X509_get_pubkey() return NULL, which triggers a NULL
  dereference in EVP_PKEY_copy_parameters().

  Additional note: the return value of X509_get_pubkey() is checked
  for NULL elsewhere in the codebase, eg, in apps/ca.c:1597.

- apps/x509.c at line 1220: NULL_DEREFERENCE
    pointer pktmp last assigned on line 1219 could be null and is dereferenced by call to EVP_PKEY_copy_parameters() at line 1220, column 5

  Similar to the previous one.

- crypto/mem_dbg.c at line 647: NULL_DEREFERENCE
    pointer lcl last assigned on line 644 could be null and is dereferenced at line 647, column 22

  localtime(3) can return NULL in case of error.

- crypto/objects/o_names.c at line 105: NULL_DEREFERENCE
    pointer name_funcs last assigned on line 103 could be null and is dereferenced at line 105, column 9

  crypto/objects/o_names.c at line 107: NULL_DEREFERENCE
    pointer name_funcs last assigned on line 103 could be null and is dereferenced at line 107, column 9

  crypto/objects/o_names.c at line 109: NULL_DEREFERENCE
    pointer name_funcs last assigned on line 103 could be null and is dereferenced at line 109, column 9

  If the names_type_num < 0 or if name_type_num >=
  name_funcs_stack->num, then name_funcs is assigned to NULL on
  line 103. These ones may be false positives, as it looks like that
  this can never be the case in that file.

- crypto/pkcs7/pk7_doit.c at line 1149: NULL_DEREFERENCE
    pointer ri last assigned on line 1148 could be null and is dereferenced at line 1149, column 12

  If PKCS7_get_issuer_and_serial() is called with idx < 0 then the
  execution gets to the last call to sk_PKCS7_RECIP_INFO_value(),
  which returns NULL.

- crypto/x509/x509_cmp.c at line 410: NULL_DEREFERENCE
    pointer x last assigned on line 405 could be null and is dereferenced at line 410, column 55

  If X509_chain_check_suiteb() is called with chain == NULL, then the
  call to sk_X509_value() on line 410 will assign NULL to x. Line 410
  is X509_get_version(x), which dereferences x without checking for
  NULL.

- crypto/x509/x509_req.c at line 125: NULL_DEREFERENCE
    pointer xk last assigned on line 124 could be null and is dereferenced by call to EVP_PKEY_cmp() at line 125, column 13

  If X509_REQ_check_private_key() is called with x == NULL, then xk
  will get NULL on line 124.

- crypto/x509/x509_req.c at line 204: NULL_DEREFERENCE
    pointer attr last assigned on line 203 could be null and is dereferenced at line 204, column 13

  In X509_REQ_get_extensions(), the call to X509_REQ_get_attr_by_NID()
  may return -2 as an error code, but the caller checks for -1
  instead. This results in an NPE a few lines down, as the -2 is
  passed to X509_REQ_get_attr(), which sees that idx is invalid and
  returns NULL. Then attr == NULL is dereferenced by attr->single in
  the condition of the if statement on the next line.

- crypto/x509/x509_lu.c at line 311: NULL_DEREFERENCE
    pointer lu last assigned on line 310 could be null and is dereferenced by call to X509_LOOKUP_by_subject() at line 311, column 17

  If vs->ctx->get_cert_methods is NULL then sk_X509_LOOKUP_num()
  returns -1 in the condition of the for loop. Then, if
  vs->current_method < -1 we still enter the body of the loop. Then lu
  gets assigned to NULL by sk_X509_LOOKUP_value.


Best regards,
Jules Villard
Facebook Static Analysis Tools Team

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Thu Jun 11 22:47:16 2015
From: rt at openssl.org (Salz, Rich via RT)
Date: Thu, 11 Jun 2015 22:47:16 +0000
Subject: [openssl-dev] [openssl.org #3903] Infer run on openssl-1.0.2a
In-Reply-To: <f0916be00dc84d219634e8d3457eb55c@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3903@openssl.org> <20150611222429.GA2385@pauvre.org>
 <rt-4.0.19-12424-1434062664-1624.3903-21-0@openssl.org>
 <f0916be00dc84d219634e8d3457eb55c@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <rt-4.0.19-10987-1434062836-1988.3903-6-0@openssl.org>

This is great!

Any chance you can run it against master?  I'm hoping most of the ones in apps go away ...



From rt at openssl.org  Thu Jun 11 23:23:28 2015
From: rt at openssl.org (Jules Villard via RT)
Date: Thu, 11 Jun 2015 23:23:28 +0000
Subject: [openssl-dev] [openssl.org #3903] Infer run on openssl-1.0.2a
In-Reply-To: <20150611232241.GB2385@pauvre.org>
References: <RT-Ticket-3903@openssl.org> <20150611222429.GA2385@pauvre.org>
 <rt-4.0.19-12424-1434062664-1624.3903-21-0@openssl.org>
 <f0916be00dc84d219634e8d3457eb55c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.19-10987-1434062836-1988.3903-6-0@openssl.org>
 <20150611232241.GB2385@pauvre.org>
Message-ID: <rt-4.0.19-17407-1434065008-1880.3903-6-0@openssl.org>

On Thu, 11 Jun 2015 22:47:16 +0000, Salz, Rich via RT wrote:
> This is great!
> 
> Any chance you can run it against master?  I'm hoping most of the ones in apps go away ...

On master I get the following 12 reports. The first 10 seem to match
reports in my previous email, and the last two are new. I've looked at
the result of inferTraceBugs on those and added comments.

apps/srp.c:109: error: NULL_DEREFERENCE
   pointer pp last assigned on line 108 could be null and is dereferenced at line 109, column 47

apps/srp.c:126: error: NULL_DEREFERENCE
   pointer pp last assigned on line 124 could be null and is dereferenced at line 126, column 13

apps/x509.c:1008: error: NULL_DEREFERENCE
   pointer upkey last assigned on line 1007 could be null and is dereferenced by call to EVP_PKEY_copy_parameters() at line 1008, column 5

crypto/mem_dbg.c:650: error: NULL_DEREFERENCE
   pointer lcl last assigned on line 647 could be null and is dereferenced at line 650, column 22

crypto/objects/o_names.c:104: error: NULL_DEREFERENCE
   pointer name_funcs last assigned on line 102 could be null and is dereferenced at line 104, column 9

crypto/objects/o_names.c:106: error: NULL_DEREFERENCE
   pointer name_funcs last assigned on line 102 could be null and is dereferenced at line 106, column 9

crypto/objects/o_names.c:108: error: NULL_DEREFERENCE
   pointer name_funcs last assigned on line 102 could be null and is dereferenced at line 108, column 9

crypto/pkcs7/pk7_doit.c:1096: error: NULL_DEREFERENCE
   pointer ri last assigned on line 1095 could be null and is dereferenced at line 1096, column 12

crypto/x509/x509_cmp.c:406: error: NULL_DEREFERENCE
   pointer x last assigned on line 401 could be null and is dereferenced at line 406, column 55

crypto/x509/x509_req.c:125: error: NULL_DEREFERENCE
   pointer xk last assigned on line 124 could be null and is dereferenced by call to EVP_PKEY_cmp() at line 125, column 13

crypto/x509v3/v3_prn.c:131: error: NULL_DEREFERENCE
   pointer extoct last assigned on line 130 could be null and is dereferenced by call to ASN1_STRING_data() at line 131, column 9

  If X509V3_EXT_print() is called with ext == NULL then
  X509_EXTENSION_get_data(ext) returns NULL and exctoct == NULL gets
  dereferenced.

crypto/x509v3/v3_scts.c:187: error: NULL_DEREFERENCE
   pointer oct last assigned on line 179 could be null and is dereferenced at line 187, column 9

  This one looks like it might be a false positive where Infer doesn't
  know that d2i_ASN1_OCTET_STRING() will allocate oct.



From danmcd at omniti.com  Fri Jun 12 01:07:18 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 11 Jun 2015 21:07:18 -0400
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
	breaks binary compatibility
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
Message-ID: <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>

I noticed that a new field was added to HMAC_CTX in the 1.0.2a->b or 1.0.1m->n update:

typedef struct hmac_ctx_st {
   const EVP_MD *md;
   EVP_MD_CTX md_ctx;
   EVP_MD_CTX i_ctx;
   EVP_MD_CTX o_ctx;
   unsigned int key_length;
   unsigned char key[HMAC_MAX_MD_CBLOCK];
+ int key_init;
} HMAC_CTX;

This breaks binary compatibility.  I found this out the hard way during an attempt to update OmniOS's OpenSSL to 1.0.2b ('014, bloody) or 1.0.1n (006, 012).  Observe our use of HMAC_CTX in illumos (which OmniOS is a distribution of):

struct Mac {
        char            *name;
        int             enabled;
        u_int           mac_len;
        u_char          *key;
        u_int           key_len;
        int             type;
        const EVP_MD    *evp_md;
        HMAC_CTX        evp_ctx;
};
struct Comp {
        int     type;
        int     enabled;
        char    *name;
};
struct Newkeys {
        Enc     enc;
        Mac     mac;
        Comp    comp; /* XXX KEBE SAYS THIS GETS CLOBBERED!!! */
};

You can see the code here:

	http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/ssh/include/kex.h#100

What is supposed to happen in this situation?  I was under the impression that letter releases don't break binary compatibility.  The SSH in illumos breaks because of this, but it appears OpenSSH has worked around such a situation.

Clues are welcome.

Thanks,
Dan McDonald -- OmniOS Engineering


From danmcd at omniti.com  Fri Jun 12 01:09:59 2015
From: danmcd at omniti.com (Dan McDonald)
Date: Thu, 11 Jun 2015 21:09:59 -0400
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
	breaks binary compatibility
In-Reply-To: <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
Message-ID: <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>


> On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com> wrote:
> 
> typedef struct hmac_ctx_st {
>   const EVP_MD *md;
>   EVP_MD_CTX md_ctx;
>   EVP_MD_CTX i_ctx;
>   EVP_MD_CTX o_ctx;
>   unsigned int key_length;
>   unsigned char key[HMAC_MAX_MD_CBLOCK];
> + int key_init;
> } HMAC_CTX;

A cheesy, but binary compatible, fix might be:

typedef struct hmac_ctx_st {
  const EVP_MD *md;
  EVP_MD_CTX md_ctx;
  EVP_MD_CTX i_ctx;
  EVP_MD_CTX o_ctx;
  unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
  unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't change! */
  unsigned char key[HMAC_MAX_MD_CBLOCK];
} HMAC_CTX;


Dan


From pwalten at au1.ibm.com  Fri Jun 12 01:21:06 2015
From: pwalten at au1.ibm.com (Peter Waltenberg)
Date: Fri, 12 Jun 2015 11:21:06 +1000
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
Message-ID: <OF5CD526E8.B01577F9-ONCA257E62.000728E0-4A257E62.00070F37@au1.ibm.com>


Which is exactly why our hacked version of OpenSSL has
allocators/deallocators for all these private struct's.

It'd be really nice if OpenSSL would fix this, adding them won't break
backwards compatibility (i.e. API breakage isn't an excuse for not fixing
these)  and going forwards problems like this would stop occuring.

Peter


From waywardgeek at google.com  Fri Jun 12 03:09:25 2015
From: waywardgeek at google.com (Bill Cox)
Date: Thu, 11 Jun 2015 20:09:25 -0700
Subject: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash
 function (let's kill md5sum!)
In-Reply-To: <CAH9QtQHtr1A_5VgFZtOm5evT0bstW4VzYLnuB8=dtRpRLK10+Q@mail.gmail.com>
References: <RT-Ticket-3897@openssl.org>
 <CAM_a8JyrqZC-WksB80jxy_VArPhnss3+0UYPvW1hSfOU2_A9_Q@mail.gmail.com>
 <rt-4.0.19-6285-1433522376-832.3897-21-0@openssl.org>
 <20150609165631.GA14469@roeckx.be>
 <CAM_a8JxibJBVAJT7CY9aCbqX2HncpcodEV76zNgduRpcARsL0w@mail.gmail.com>
 <CAM_a8Jz06OJFrad=bHWE7aA9zWmjkLMok_dvS44chnKjfpA4mg@mail.gmail.com>
 <CAH9QtQFvncQEd8Y5Ncgk_0HrAS4tCiZta7MvYxLFDEzLUNmt4A@mail.gmail.com>
 <CAM_a8Jx49fFbgs8VACFSUjntnJ3HtQpnaWBNTkEeP_jH9GZOrw@mail.gmail.com>
 <CAH9QtQEmS-GqCUe4hUowuSHySVRewWTS1weXfYuDWFhZhJV4rw@mail.gmail.com>
 <5578D4B8.90901@dei.uc.pt>
 <CAH9QtQHtr1A_5VgFZtOm5evT0bstW4VzYLnuB8=dtRpRLK10+Q@mail.gmail.com>
Message-ID: <CAH9QtQHiO8RRGbbgwmCdUS8Bk+6bmpoO3jmiAeSyyo9istAQwg@mail.gmail.com>

Actually, just to get the ball rolling, I'll integrate the "reg" version of
Blake2, which is portable C, and a bit faster than the reference version,
which was designed for readability rather than performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150611/503c5430/attachment.html>

From mancha1 at zoho.com  Fri Jun 12 06:22:25 2015
From: mancha1 at zoho.com (mancha)
Date: Fri, 12 Jun 2015 06:22:25 +0000
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
Message-ID: <20150612062224.GB29666@zoho.com>

On Thu, Jun 11, 2015 at 09:07:18PM -0400, Dan McDonald wrote:
> I noticed that a new field was added to HMAC_CTX in the 1.0.2a->b or
> 1.0.1m->n update:
> 
> typedef struct hmac_ctx_st { const EVP_MD *md; EVP_MD_CTX md_ctx;
> EVP_MD_CTX i_ctx; EVP_MD_CTX o_ctx; unsigned int key_length; unsigned
> char key[HMAC_MAX_MD_CBLOCK]; + int key_init; } HMAC_CTX;
> 
> This breaks binary compatibility.  I found this out the hard way
> during an attempt to update OmniOS's OpenSSL to 1.0.2b ('014, bloody)
> or 1.0.1n (006, 012).  Observe our use of HMAC_CTX in illumos (which
> OmniOS is a distribution of):
> 
> struct Mac { char            *name; int             enabled; u_int
> mac_len; u_char          *key; u_int           key_len; int
> type; const EVP_MD    *evp_md; HMAC_CTX        evp_ctx; }; struct Comp
> { int     type; int     enabled; char    *name; }; struct Newkeys {
> Enc     enc; Mac     mac; Comp    comp; /* XXX KEBE SAYS THIS GETS
> CLOBBERED!!! */ };
> 
> You can see the code here:
> 
> 	http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/ssh/include/kex.h#100
> 
> What is supposed to happen in this situation?  I was under the
> impression that letter releases don't break binary compatibility.  The
> SSH in illumos breaks because of this, but it appears OpenSSH has
> worked around such a situation.
> 
> Clues are welcome.
> 
> Thanks, Dan McDonald -- OmniOS Engineering

Hi Dan. Many thanks for your report. I've checked and the issue you've
identified potentially affects OpenSSH 4.7 through 6.5, inclusive.

OpenSSH 6.6 replaces the OpenSSL HMAC with its own implementation making
the ABI change a NOP for OpenSSH 6.6 onwards.  

Cheers.

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150612/4226bf3e/attachment.sig>

From matt at openssl.org  Fri Jun 12 06:57:23 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2015 07:57:23 +0100
Subject: [openssl-dev] OpenSSL version 1.0.2b released
In-Reply-To: <5579BF39.8030504@kippdata.de>
References: <20150611144708.GA16030@openssl.org> <5579BF39.8030504@kippdata.de>
Message-ID: <557A82D3.6040908@openssl.org>



On 11/06/15 18:02, Rainer Jung wrote:
> The release notes mentioned and linked in all of the four release
> announcements still contain stale text:
> 
> https://www.openssl.org/news/openssl-1.0.2-notes.html
> https://www.openssl.org/news/openssl-1.0.1-notes.html
> https://www.openssl.org/news/openssl-1.0.0-notes.html
> https://www.openssl.org/news/openssl-0.9.8-notes.html
> 
> The current release simply looks like
> 
>  Major changes between OpenSSL 1.0.2a and OpenSSL 1.0.2b [under
> development]
> 
> -
> 
> Major changes between OpenSSL 1.0.2 and OpenSSL 1.0.2a [19 Mar 2015]
> ...
> 
> So all entries for todays releases are still missing.
> 
> Maybe it is on its way, but since the announcement was 2 hours ago and
> the pages are linked in them I thought I'd better let you know.

This should be fixed now.

Matt


From timo.teras at iki.fi  Fri Jun 12 08:27:42 2015
From: timo.teras at iki.fi (Timo Teras)
Date: Fri, 12 Jun 2015 11:27:42 +0300
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
Message-ID: <20150612112742.402c63c6@vostro>

On Thu, 11 Jun 2015 21:09:59 -0400
Dan McDonald <danmcd at omniti.com> wrote:

> 
> > On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com> wrote:
> > 
> > typedef struct hmac_ctx_st {
> >   const EVP_MD *md;
> >   EVP_MD_CTX md_ctx;
> >   EVP_MD_CTX i_ctx;
> >   EVP_MD_CTX o_ctx;
> >   unsigned int key_length;
> >   unsigned char key[HMAC_MAX_MD_CBLOCK];
> > + int key_init;
> > } HMAC_CTX;
> 
> A cheesy, but binary compatible, fix might be:
> 
> typedef struct hmac_ctx_st {
>   const EVP_MD *md;
>   EVP_MD_CTX md_ctx;
>   EVP_MD_CTX i_ctx;
>   EVP_MD_CTX o_ctx;
>   unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
>   unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't
> change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
> } HMAC_CTX;

Why is separate key_init needid? Could we not use md!=NULL or
key_length!=0 checks to see if the context is initialized?

From timo.teras at iki.fi  Fri Jun 12 08:49:39 2015
From: timo.teras at iki.fi (Timo Teras)
Date: Fri, 12 Jun 2015 11:49:39 +0300
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <20150612112742.402c63c6@vostro>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
 <20150612112742.402c63c6@vostro>
Message-ID: <20150612114939.0c32883d@vostro>

On Fri, 12 Jun 2015 11:27:42 +0300
Timo Teras <timo.teras at iki.fi> wrote:

> On Thu, 11 Jun 2015 21:09:59 -0400
> Dan McDonald <danmcd at omniti.com> wrote:
> 
> > 
> > > On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com>
> > > wrote:
> > > 
> > > typedef struct hmac_ctx_st {
> > >   const EVP_MD *md;
> > >   EVP_MD_CTX md_ctx;
> > >   EVP_MD_CTX i_ctx;
> > >   EVP_MD_CTX o_ctx;
> > >   unsigned int key_length;
> > >   unsigned char key[HMAC_MAX_MD_CBLOCK];
> > > + int key_init;
> > > } HMAC_CTX;
> > 
> > A cheesy, but binary compatible, fix might be:
> > 
> > typedef struct hmac_ctx_st {
> >   const EVP_MD *md;
> >   EVP_MD_CTX md_ctx;
> >   EVP_MD_CTX i_ctx;
> >   EVP_MD_CTX o_ctx;
> >   unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
> >   unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't
> > change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
> > } HMAC_CTX;
> 
> Why is separate key_init needid? Could we not use md!=NULL or
> key_length!=0 checks to see if the context is initialized?

Seems it'd be along with the line to just use key_length instead.

Something along the lines of:

diff --git a/crypto/hmac/hmac.c b/crypto/hmac/hmac.c
index 5925467..e6876bf 100644
--- a/crypto/hmac/hmac.c
+++ b/crypto/hmac/hmac.c
@@ -97,7 +97,7 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
         return 0;
     }
 
-    if (!ctx->key_init && key == NULL)
+    if (!ctx->key_length && key == NULL)
         return 0;
 
     if (key != NULL) {
@@ -121,7 +121,6 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
         if (ctx->key_length != HMAC_MAX_MD_CBLOCK)
             memset(&ctx->key[ctx->key_length], 0,
                    HMAC_MAX_MD_CBLOCK - ctx->key_length);
-        ctx->key_init = 1;
     }
 
     if (reset) {
@@ -159,7 +158,7 @@ int HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, size_t len)
     if (FIPS_mode() && !ctx->i_ctx.engine)
         return FIPS_hmac_update(ctx, data, len);
 #endif
-    if (!ctx->key_init)
+    if (!ctx->key_length)
         return 0;
 
     return EVP_DigestUpdate(&ctx->md_ctx, data, len);
@@ -174,7 +173,7 @@ int HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len)
         return FIPS_hmac_final(ctx, md, len);
 #endif
 
-    if (!ctx->key_init)
+    if (!ctx->key_length)
         goto err;
 
     if (!EVP_DigestFinal_ex(&ctx->md_ctx, buf, &i))
@@ -195,7 +194,7 @@ void HMAC_CTX_init(HMAC_CTX *ctx)
     EVP_MD_CTX_init(&ctx->i_ctx);
     EVP_MD_CTX_init(&ctx->o_ctx);
     EVP_MD_CTX_init(&ctx->md_ctx);
-    ctx->key_init = 0;
+    ctx->key_length = 0;
     ctx->md = NULL;
 }
 
@@ -207,11 +206,8 @@ int HMAC_CTX_copy(HMAC_CTX *dctx, HMAC_CTX *sctx)
         goto err;
     if (!EVP_MD_CTX_copy(&dctx->md_ctx, &sctx->md_ctx))
         goto err;
-    dctx->key_init = sctx->key_init;
-    if (sctx->key_init) {
-        memcpy(dctx->key, sctx->key, HMAC_MAX_MD_CBLOCK);
-        dctx->key_length = sctx->key_length;
-    }
+    memcpy(dctx->key, sctx->key, HMAC_MAX_MD_CBLOCK);
+    dctx->key_length = sctx->key_length;
     dctx->md = sctx->md;
     return 1;
  err:
diff --git a/crypto/hmac/hmac.h b/crypto/hmac/hmac.h
index f8e9f5e..b8b55cd 100644
--- a/crypto/hmac/hmac.h
+++ b/crypto/hmac/hmac.h
@@ -79,7 +79,6 @@ typedef struct hmac_ctx_st {
     EVP_MD_CTX o_ctx;
     unsigned int key_length;
     unsigned char key[HMAC_MAX_MD_CBLOCK];
-    int key_init;
 } HMAC_CTX;
 
 # define HMAC_size(e)    (EVP_MD_size((e)->md))


From tmraz at redhat.com  Fri Jun 12 08:52:45 2015
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 12 Jun 2015 10:52:45 +0200
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <20150612114939.0c32883d@vostro>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
 <20150612112742.402c63c6@vostro> <20150612114939.0c32883d@vostro>
Message-ID: <1434099165.9562.13.camel@redhat.com>

On P?, 2015-06-12 at 11:49 +0300, Timo Teras wrote:
> On Fri, 12 Jun 2015 11:27:42 +0300
> Timo Teras <timo.teras at iki.fi> wrote:
> 
> > On Thu, 11 Jun 2015 21:09:59 -0400
> > Dan McDonald <danmcd at omniti.com> wrote:
> > 
> > > 
> > > > On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com>
> > > > wrote:
> > > > 
> > > > typedef struct hmac_ctx_st {
> > > >   const EVP_MD *md;
> > > >   EVP_MD_CTX md_ctx;
> > > >   EVP_MD_CTX i_ctx;
> > > >   EVP_MD_CTX o_ctx;
> > > >   unsigned int key_length;
> > > >   unsigned char key[HMAC_MAX_MD_CBLOCK];
> > > > + int key_init;
> > > > } HMAC_CTX;
> > > 
> > > A cheesy, but binary compatible, fix might be:
> > > 
> > > typedef struct hmac_ctx_st {
> > >   const EVP_MD *md;
> > >   EVP_MD_CTX md_ctx;
> > >   EVP_MD_CTX i_ctx;
> > >   EVP_MD_CTX o_ctx;
> > >   unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
> > >   unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't
> > > change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
> > > } HMAC_CTX;
> > 
> > Why is separate key_init needid? Could we not use md!=NULL or
> > key_length!=0 checks to see if the context is initialized?
> 
> Seems it'd be along with the line to just use key_length instead.

Yes, this needs to be reverted and key_length or some other workaround
used instead. I had a hope that breaking ABI compatibility on 1.0.x
branches is no-go.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)



From matt at openssl.org  Fri Jun 12 09:00:41 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2015 10:00:41 +0100
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <1434099165.9562.13.camel@redhat.com>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
 <20150612112742.402c63c6@vostro> <20150612114939.0c32883d@vostro>
 <1434099165.9562.13.camel@redhat.com>
Message-ID: <557A9FB9.1060507@openssl.org>



On 12/06/15 09:52, Tomas Mraz wrote:
> On P?, 2015-06-12 at 11:49 +0300, Timo Teras wrote:
>> On Fri, 12 Jun 2015 11:27:42 +0300
>> Timo Teras <timo.teras at iki.fi> wrote:
>>
>>> On Thu, 11 Jun 2015 21:09:59 -0400
>>> Dan McDonald <danmcd at omniti.com> wrote:
>>>
>>>>
>>>>> On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com>
>>>>> wrote:
>>>>>
>>>>> typedef struct hmac_ctx_st {
>>>>>   const EVP_MD *md;
>>>>>   EVP_MD_CTX md_ctx;
>>>>>   EVP_MD_CTX i_ctx;
>>>>>   EVP_MD_CTX o_ctx;
>>>>>   unsigned int key_length;
>>>>>   unsigned char key[HMAC_MAX_MD_CBLOCK];
>>>>> + int key_init;
>>>>> } HMAC_CTX;
>>>>
>>>> A cheesy, but binary compatible, fix might be:
>>>>
>>>> typedef struct hmac_ctx_st {
>>>>   const EVP_MD *md;
>>>>   EVP_MD_CTX md_ctx;
>>>>   EVP_MD_CTX i_ctx;
>>>>   EVP_MD_CTX o_ctx;
>>>>   unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
>>>>   unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't
>>>> change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
>>>> } HMAC_CTX;
>>>
>>> Why is separate key_init needid? Could we not use md!=NULL or
>>> key_length!=0 checks to see if the context is initialized?
>>
>> Seems it'd be along with the line to just use key_length instead.
> 
> Yes, this needs to be reverted and key_length or some other workaround
> used instead. I had a hope that breaking ABI compatibility on 1.0.x
> branches is no-go.
> 

Breaking ABI compatibility on 1.0.x is (supposed to be) a no-go. We're
just debating what the appropriate response is to this issue.

Matt

From matt at openssl.org  Fri Jun 12 09:38:02 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2015 10:38:02 +0100
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <20150612114939.0c32883d@vostro>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
 <20150612112742.402c63c6@vostro> <20150612114939.0c32883d@vostro>
Message-ID: <557AA87A.10002@openssl.org>



On 12/06/15 09:49, Timo Teras wrote:
> On Fri, 12 Jun 2015 11:27:42 +0300
> Timo Teras <timo.teras at iki.fi> wrote:
> 
>> On Thu, 11 Jun 2015 21:09:59 -0400
>> Dan McDonald <danmcd at omniti.com> wrote:
>>
>>>
>>>> On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com>
>>>> wrote:
>>>>
>>>> typedef struct hmac_ctx_st {
>>>>   const EVP_MD *md;
>>>>   EVP_MD_CTX md_ctx;
>>>>   EVP_MD_CTX i_ctx;
>>>>   EVP_MD_CTX o_ctx;
>>>>   unsigned int key_length;
>>>>   unsigned char key[HMAC_MAX_MD_CBLOCK];
>>>> + int key_init;
>>>> } HMAC_CTX;
>>>
>>> A cheesy, but binary compatible, fix might be:
>>>
>>> typedef struct hmac_ctx_st {
>>>   const EVP_MD *md;
>>>   EVP_MD_CTX md_ctx;
>>>   EVP_MD_CTX i_ctx;
>>>   EVP_MD_CTX o_ctx;
>>>   unsigned int key_init:1;   /* Ewww, cheesy use of bitfields... */
>>>   unsigned int key_length:31;  /* but the sizeof (HMAC_CTX) doesn't
>>> change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
>>> } HMAC_CTX;
>>
>> Why is separate key_init needid? Could we not use md!=NULL or
>> key_length!=0 checks to see if the context is initialized?
> 
> Seems it'd be along with the line to just use key_length instead.
> 
> Something along the lines of:

Your patch does introduce a change in behaviour if key != NULL but len
== 0. Previously this would set ctx->key to all 0s, and key_init to 1,
and would then continue to use that all zero key. A subsequent
invocation of HMAC_Init_ex with key == NULL would reuse that all zero
key. Your patch would allow the first invocation, but error out on the
second.

Should it be a valid use case to allow an all zero key in this way?

Matt



> 
> diff --git a/crypto/hmac/hmac.c b/crypto/hmac/hmac.c
> index 5925467..e6876bf 100644
> --- a/crypto/hmac/hmac.c
> +++ b/crypto/hmac/hmac.c
> @@ -97,7 +97,7 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
>          return 0;
>      }
>  
> -    if (!ctx->key_init && key == NULL)
> +    if (!ctx->key_length && key == NULL)
>          return 0;
>  
>      if (key != NULL) {
> @@ -121,7 +121,6 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
>          if (ctx->key_length != HMAC_MAX_MD_CBLOCK)
>              memset(&ctx->key[ctx->key_length], 0,
>                     HMAC_MAX_MD_CBLOCK - ctx->key_length);
> -        ctx->key_init = 1;
>      }
>  
>      if (reset) {
> @@ -159,7 +158,7 @@ int HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, size_t len)
>      if (FIPS_mode() && !ctx->i_ctx.engine)
>          return FIPS_hmac_update(ctx, data, len);
>  #endif
> -    if (!ctx->key_init)
> +    if (!ctx->key_length)
>          return 0;
>  
>      return EVP_DigestUpdate(&ctx->md_ctx, data, len);
> @@ -174,7 +173,7 @@ int HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len)
>          return FIPS_hmac_final(ctx, md, len);
>  #endif
>  
> -    if (!ctx->key_init)
> +    if (!ctx->key_length)
>          goto err;
>  
>      if (!EVP_DigestFinal_ex(&ctx->md_ctx, buf, &i))
> @@ -195,7 +194,7 @@ void HMAC_CTX_init(HMAC_CTX *ctx)
>      EVP_MD_CTX_init(&ctx->i_ctx);
>      EVP_MD_CTX_init(&ctx->o_ctx);
>      EVP_MD_CTX_init(&ctx->md_ctx);
> -    ctx->key_init = 0;
> +    ctx->key_length = 0;
>      ctx->md = NULL;
>  }
>  
> @@ -207,11 +206,8 @@ int HMAC_CTX_copy(HMAC_CTX *dctx, HMAC_CTX *sctx)
>          goto err;
>      if (!EVP_MD_CTX_copy(&dctx->md_ctx, &sctx->md_ctx))
>          goto err;
> -    dctx->key_init = sctx->key_init;
> -    if (sctx->key_init) {
> -        memcpy(dctx->key, sctx->key, HMAC_MAX_MD_CBLOCK);
> -        dctx->key_length = sctx->key_length;
> -    }
> +    memcpy(dctx->key, sctx->key, HMAC_MAX_MD_CBLOCK);
> +    dctx->key_length = sctx->key_length;
>      dctx->md = sctx->md;
>      return 1;
>   err:
> diff --git a/crypto/hmac/hmac.h b/crypto/hmac/hmac.h
> index f8e9f5e..b8b55cd 100644
> --- a/crypto/hmac/hmac.h
> +++ b/crypto/hmac/hmac.h
> @@ -79,7 +79,6 @@ typedef struct hmac_ctx_st {
>      EVP_MD_CTX o_ctx;
>      unsigned int key_length;
>      unsigned char key[HMAC_MAX_MD_CBLOCK];
> -    int key_init;
>  } HMAC_CTX;
>  
>  # define HMAC_size(e)    (EVP_MD_size((e)->md))
> 
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 

From timo.teras at iki.fi  Fri Jun 12 10:16:25 2015
From: timo.teras at iki.fi (Timo Teras)
Date: Fri, 12 Jun 2015 13:16:25 +0300
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <557AA87A.10002@openssl.org>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>
 <03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>
 <0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>
 <20150612112742.402c63c6@vostro> <20150612114939.0c32883d@vostro>
 <557AA87A.10002@openssl.org>
Message-ID: <20150612131625.0f390097@vostro>

On Fri, 12 Jun 2015 10:38:02 +0100
Matt Caswell <matt at openssl.org> wrote:

> 
> 
> On 12/06/15 09:49, Timo Teras wrote:
> > On Fri, 12 Jun 2015 11:27:42 +0300
> > Timo Teras <timo.teras at iki.fi> wrote:
> > 
> >> On Thu, 11 Jun 2015 21:09:59 -0400
> >> Dan McDonald <danmcd at omniti.com> wrote:
> >>
> >>>
> >>>> On Jun 11, 2015, at 9:07 PM, Dan McDonald <danmcd at omniti.com>
> >>>> wrote:
> >>>>
> >>>> typedef struct hmac_ctx_st {
> >>>>   const EVP_MD *md;
> >>>>   EVP_MD_CTX md_ctx;
> >>>>   EVP_MD_CTX i_ctx;
> >>>>   EVP_MD_CTX o_ctx;
> >>>>   unsigned int key_length;
> >>>>   unsigned char key[HMAC_MAX_MD_CBLOCK];
> >>>> + int key_init;
> >>>> } HMAC_CTX;
> >>>
> >>> A cheesy, but binary compatible, fix might be:
> >>>
> >>> typedef struct hmac_ctx_st {
> >>>   const EVP_MD *md;
> >>>   EVP_MD_CTX md_ctx;
> >>>   EVP_MD_CTX i_ctx;
> >>>   EVP_MD_CTX o_ctx;
> >>>   unsigned int key_init:1;   /* Ewww, cheesy use of bitfields...
> >>> */ unsigned int key_length:31;  /* but the sizeof (HMAC_CTX)
> >>> doesn't change! */ unsigned char key[HMAC_MAX_MD_CBLOCK];
> >>> } HMAC_CTX;
> >>
> >> Why is separate key_init needid? Could we not use md!=NULL or
> >> key_length!=0 checks to see if the context is initialized?
> > 
> > Seems it'd be along with the line to just use key_length instead.
> > 
> > Something along the lines of:
> 
> Your patch does introduce a change in behaviour if key != NULL but len
> == 0. Previously this would set ctx->key to all 0s, and key_init to 1,
> and would then continue to use that all zero key. A subsequent
> invocation of HMAC_Init_ex with key == NULL would reuse that all zero
> key. Your patch would allow the first invocation, but error out on the
> second.
> 
> Should it be a valid use case to allow an all zero key in this way?

This raises another concern. If md is changed, but key is not, things
go wrong anyway. I think we should just disallow chaning md without
key.

The problem is that if md is changed, we need to rehash using the new
md (in case they key >= HMAC_MAX_MD_CBLOCK). This was not allowed
earlier. So let's just require specifying key if md changes.

We can in fact remove using key_length altogether then. I think
key_length should be assigned to EVP_MD_block_size(md) always. Because
they key is technically zero-padded anyway to this length. 

From matt at openssl.org  Fri Jun 12 11:26:04 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2015 12:26:04 +0100
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <20150612131625.0f390097@vostro>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>	<03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>	<0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>	<20150612112742.402c63c6@vostro>	<20150612114939.0c32883d@vostro>	<557AA87A.10002@openssl.org>
 <20150612131625.0f390097@vostro>
Message-ID: <557AC1CC.6080007@openssl.org>



On 12/06/15 11:16, Timo Teras wrote:
>>>> Why is separate key_init needid? Could we not use md!=NULL or
>>>> key_length!=0 checks to see if the context is initialized?
>>>
>>> Seems it'd be along with the line to just use key_length instead.
>>>
>>> Something along the lines of:
>>
>> Your patch does introduce a change in behaviour if key != NULL but len
>> == 0. Previously this would set ctx->key to all 0s, and key_init to 1,
>> and would then continue to use that all zero key. A subsequent
>> invocation of HMAC_Init_ex with key == NULL would reuse that all zero
>> key. Your patch would allow the first invocation, but error out on the
>> second.
>>
>> Should it be a valid use case to allow an all zero key in this way?
> 
> This raises another concern. If md is changed, but key is not, things
> go wrong anyway.

Hmmm...yes, this is a problem.

> I think we should just disallow chaning md without
> key.
> 
> The problem is that if md is changed, we need to rehash using the new
> md (in case they key >= HMAC_MAX_MD_CBLOCK). This was not allowed
> earlier. So let's just require specifying key if md changes.
> 
> We can in fact remove using key_length altogether then. I think
> key_length should be assigned to EVP_MD_block_size(md) always. Because
> they key is technically zero-padded anyway to this length. 
> 

Previously, it would work to do this:

HMAC_Init_ex(ctx, NULL, 0, md, NULL);
HMAC_Init_ex(ctx, key, len, NULL, NULL);

The first call above would actually read uninitialised ctx->key
data...but then throw away any results in the second call.

I'm not sure we could get rid of key_length altogether and deal with the
above?

Matt

From matt at openssl.org  Fri Jun 12 12:18:48 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2015 13:18:48 +0100
Subject: [openssl-dev] sizeof (HMAC_CTX) changes with update,
 breaks binary compatibility
In-Reply-To: <557AC1CC.6080007@openssl.org>
References: <01071564-7C07-4452-98FF-025BE9B3C737@omniti.com>	<03D16161-2518-4AA9-9305-CF45EC6A7357@omniti.com>	<0EC2B6C7-B2C2-4B63-98F4-6168AE7CD66E@omniti.com>	<20150612112742.402c63c6@vostro>	<20150612114939.0c32883d@vostro>	<557AA87A.10002@openssl.org>
 <20150612131625.0f390097@vostro> <557AC1CC.6080007@openssl.org>
Message-ID: <557ACE28.3000102@openssl.org>



On 12/06/15 12:26, Matt Caswell wrote:
> 
> 
> On 12/06/15 11:16, Timo Teras wrote:
>>>>> Why is separate key_init needid? Could we not use md!=NULL or
>>>>> key_length!=0 checks to see if the context is initialized?
>>>>
>>>> Seems it'd be along with the line to just use key_length instead.
>>>>
>>>> Something along the lines of:
>>>
>>> Your patch does introduce a change in behaviour if key != NULL but len
>>> == 0. Previously this would set ctx->key to all 0s, and key_init to 1,
>>> and would then continue to use that all zero key. A subsequent
>>> invocation of HMAC_Init_ex with key == NULL would reuse that all zero
>>> key. Your patch would allow the first invocation, but error out on the
>>> second.
>>>
>>> Should it be a valid use case to allow an all zero key in this way?
>>
>> This raises another concern. If md is changed, but key is not, things
>> go wrong anyway.
> 
> Hmmm...yes, this is a problem.
> 
>> I think we should just disallow chaning md without
>> key.
>>
>> The problem is that if md is changed, we need to rehash using the new
>> md (in case they key >= HMAC_MAX_MD_CBLOCK). This was not allowed
>> earlier. So let's just require specifying key if md changes.
>>
>> We can in fact remove using key_length altogether then. I think
>> key_length should be assigned to EVP_MD_block_size(md) always. Because
>> they key is technically zero-padded anyway to this length. 
>>
> 
> Previously, it would work to do this:
> 
> HMAC_Init_ex(ctx, NULL, 0, md, NULL);
> HMAC_Init_ex(ctx, key, len, NULL, NULL);
> 
> The first call above would actually read uninitialised ctx->key
> data...but then throw away any results in the second call.

Actually thinking about it, I think that might be a corner case too
far...and I now remember that that was one of the corner cases that the
key_init change prevented.

So that would make the change look more like this:

>From d392a99d2d7910a3aea8b7fc33e52dfcb115c2b5 Mon Sep 17 00:00:00 2001
From: Matt Caswell <matt at openssl.org>
Date: Fri, 12 Jun 2015 13:08:04 +0100
Subject: [PATCH] Fix ABI break with HMAC

Recent HMAC changes broke ABI compatibility due to a new field in HMAC_CTX.
This backs that change out, and does it a different way.

Thanks to Timo Teras for the concept.
---
 crypto/hmac/hmac.c     | 20 ++++++++------------
 include/openssl/hmac.h |  1 -
 test/hmactest.c        |  7 ++++++-
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/crypto/hmac/hmac.c b/crypto/hmac/hmac.c
index d50fabb..7699b0b 100644
--- a/crypto/hmac/hmac.c
+++ b/crypto/hmac/hmac.c
@@ -68,6 +68,10 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
     int i, j, reset = 0;
     unsigned char pad[HMAC_MAX_MD_CBLOCK];

+    /* If we are changing MD then we must have a key */
+    if (md != NULL && md != ctx->md && (key == NULL || len < 0))
+        return 0;
+
     if (md != NULL) {
         reset = 1;
         ctx->md = md;
@@ -77,9 +81,6 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len,
         return 0;
     }

-    if (!ctx->key_init && key == NULL)
-        return 0;
-
     if (key != NULL) {
         reset = 1;
         j = M_EVP_MD_block_size(md);
@@ -101,7 +102,6 @@ int HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int
len,
         if (ctx->key_length != HMAC_MAX_MD_CBLOCK)
             memset(&ctx->key[ctx->key_length], 0,
                    HMAC_MAX_MD_CBLOCK - ctx->key_length);
-        ctx->key_init = 1;
     }

     if (reset) {
@@ -137,7 +137,7 @@ int HMAC_Init(HMAC_CTX *ctx, const void *key, int
len, const EVP_MD *md)

 int HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, size_t len)
 {
-    if (!ctx->key_init)
+    if (!ctx->md)
         return 0;
     return EVP_DigestUpdate(&ctx->md_ctx, data, len);
 }
@@ -147,7 +147,7 @@ int HMAC_Final(HMAC_CTX *ctx, unsigned char *md,
unsigned int *len)
     unsigned int i;
     unsigned char buf[EVP_MAX_MD_SIZE];

-    if (!ctx->key_init)
+    if (!ctx->md)
         goto err;

     if (!EVP_DigestFinal_ex(&ctx->md_ctx, buf, &i))
@@ -168,7 +168,6 @@ void HMAC_CTX_init(HMAC_CTX *ctx)
     EVP_MD_CTX_init(&ctx->i_ctx);
     EVP_MD_CTX_init(&ctx->o_ctx);
     EVP_MD_CTX_init(&ctx->md_ctx);
-    ctx->key_init = 0;
     ctx->md = NULL;
 }

@@ -181,11 +180,8 @@ int HMAC_CTX_copy(HMAC_CTX *dctx, HMAC_CTX *sctx)
         goto err;
     if (!EVP_MD_CTX_copy_ex(&dctx->md_ctx, &sctx->md_ctx))
         goto err;
-    dctx->key_init = sctx->key_init;
-    if (sctx->key_init) {
-        memcpy(dctx->key, sctx->key, HMAC_MAX_MD_CBLOCK);
-        dctx->key_length = sctx->key_length;
-    }
+    memcpy(dctx->key, sctx->key, HMAC_MAX_MD_CBLOCK);
+    dctx->key_length = sctx->key_length;
     dctx->md = sctx->md;
     return 1;
  err:
diff --git a/include/openssl/hmac.h b/include/openssl/hmac.h
index 61946fc..81aa49d 100644
--- a/include/openssl/hmac.h
+++ b/include/openssl/hmac.h
@@ -75,7 +75,6 @@ typedef struct hmac_ctx_st {
     EVP_MD_CTX o_ctx;
     unsigned int key_length;
     unsigned char key[HMAC_MAX_MD_CBLOCK];
-    int key_init;
 } HMAC_CTX;

 # define HMAC_size(e)    (EVP_MD_size((e)->md))
diff --git a/test/hmactest.c b/test/hmactest.c
index 13344d6..a9b829d 100644
--- a/test/hmactest.c
+++ b/test/hmactest.c
@@ -226,7 +226,12 @@ test5:
         err++;
         goto test6;
     }
-    if (!HMAC_Init_ex(&ctx, NULL, 0, EVP_sha256(), NULL)) {
+    if (HMAC_Init_ex(&ctx, NULL, 0, EVP_sha256(), NULL)) {
+        printf("Should disallow changing MD without a new key (test 5)\n");
+        err++;
+        goto test6;
+    }
+    if (!HMAC_Init_ex(&ctx, test[4].key, test[4].key_len, EVP_sha256(),
NULL)) {
         printf("Failed to reinitialise HMAC (test 5)\n");
         err++;
         goto test6;
-- 
2.1.4

Matt



From levitte at openssl.org  Fri Jun 12 14:55:28 2015
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 12 Jun 2015 16:55:28 +0200 (CEST)
Subject: [openssl-dev] [openssl-announce] Forthcoming releases
Message-ID: <20150612.165528.2137931534546421320.levitte@openssl.org>

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2c, 1.0.1o.

These releases will be made available on Friday 12th June. They will
fix two specific issues: 1) an HMAC ABI incompatibility with previous
releases, and 2) make it possible to accept a zero length extension
block in a ClientHello.

These are not security releases.

Yours

The OpenSSL Project Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150612/a6a77738/attachment.sig>
-------------- next part --------------
_______________________________________________
openssl-announce mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce

From openssl at openssl.org  Fri Jun 12 15:36:46 2015
From: openssl at openssl.org (OpenSSL)
Date: Fri, 12 Jun 2015 15:36:46 +0000
Subject: [openssl-dev] OpenSSL version 1.0.1o released
Message-ID: <20150612153646.GA2931@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.1o 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 1.0.1o of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1o 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-1.0.1o.tar.gz
      Size: 4546659
      MD5 checksum: af1096f500a612e2e2adacb958d7eab1
      SHA1 checksum: b003e3382607ef2c6d85b51e4ed7a4c0a76b8d5a

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.1o.tar.gz
    openssl sha1 openssl-1.0.1o.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVevjeAAoJENnE0m0OYESRBTYIALl9NdRXPLxB+VZtVFVmOIHq
HjC5IMBJCtsNCvUg3dOogSR+ZyrY82jPimxNY1+w5XCOQQ4Ro90Auw9OMoRwRo1y
7Y9+mZkxIrJUdudlNDmfsHw8wE5peThdhZnI9vnTgJSLBKbjqqVsHsxnUJ8dzNsc
M2e2qa/poSPapWakfgafRRCblM9C/9zK/++n1m+t2SLHdM1dPanbiOIodnxX7XKp
t/6UQzclDAPDpnG74bYPzHTI2rfcruezD8RiB3dNpma9n0uGRjorGEHjn/6PcgFy
Rn1vgybhsoXpmQWT9kEQcLeRjgHEwyzxBlmVYnC3SFItlMma3h/bGYniCR89Huo=
=WGaf
-----END PGP SIGNATURE-----

From openssl at openssl.org  Fri Jun 12 15:37:04 2015
From: openssl at openssl.org (OpenSSL)
Date: Fri, 12 Jun 2015 15:37:04 +0000
Subject: [openssl-dev] OpenSSL version 1.0.2c released
Message-ID: <20150612153704.GA3101@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.2c 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 1.0.2c of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2c 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-1.0.2c.tar.gz
      Size: 5280670
      MD5 checksum: 8c8d81a9ae7005276e486702edbcd4b6
      SHA1 checksum: 6e4a5e91159eb32383296c7c83ac0e59b83a0a44

   The checksums were calculated using the following commands:

    openssl md5 openssl-1.0.2c.tar.gz
    openssl sha1 openssl-1.0.2c.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVevZ0AAoJENnE0m0OYESRAGIIAI+OThnhcwcrZoA3pddNL5+s
mVGDd+ZstNkiqLFJSOn2Enh7Hx8xvUwaONvSAGqyiuxgmkyOSmnhc9NeE2LU+knl
8vMqF4hrTWV39JJZkkqqwEv5HRr17IWtzBL3N3/1mygvFmge6SFbGeRPk+XpyP/L
0aEWRzm7g4nq+g4Oa4/HeXsVeEwldMhgHoxbS0R3RHXPOlGb3VjZUDzg+0Nwqt5O
q/sncMZAaC2TGauqsAxS19C+7hVEeZdvPKgX+DClf+NMe9+j8gWz1zmD7q5zJSQ8
ZH5+4ifFaVBSn1vuxPK4cLF5j+aUnotmWFkhJ3yZOAt+tYEH95MNB2aP4k2UCgc=
=QIqW
-----END PGP SIGNATURE-----

From levitte at openssl.org  Fri Jun 12 15:39:43 2015
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 12 Jun 2015 17:39:43 +0200 (CEST)
Subject: [openssl-dev] [openssl-announce] Clarification on forthcoming
	releases
Message-ID: <20150612.173943.1507279799213732121.levitte@openssl.org>

Clarification on the forthcoming OpenSSL releases
=================================================

To clarify, the mentioned HMAC ABI incompatibility occurred in
recently released versions 1.0.2b and 1.0.1n which are security fixes
but which may cause other problems due to the ABI issue.  Therefore,
the forthcoming releases should be used in preference to 1.0.2b and
1.0.1n.

Yours

The OpenSSL Project Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150612/fe7f1cb2/attachment.sig>
-------------- next part --------------
_______________________________________________
openssl-announce mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce

From rt at openssl.org  Fri Jun 12 15:44:33 2015
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Fri, 12 Jun 2015 15:44:33 +0000
Subject: [openssl-dev] [openssl.org #3904] [master] NULL handling Issues in
	i2c_ibuf() in a_int.c
In-Reply-To: <CADujJWUDk73GSu_i87fxKRzqzUeWUKbDUPb6Vjr8ji0Wa=nVHA@mail.gmail.com>
References: <RT-Ticket-3904@openssl.org>
 <CADujJWUDk73GSu_i87fxKRzqzUeWUKbDUPb6Vjr8ji0Wa=nVHA@mail.gmail.com>
Message-ID: <rt-4.0.19-10987-1434123873-819.3904-21-0@openssl.org>

This ticket only applies to master

What is the intended behavior when b or blen is NULL?
all I see is that ret is set to 1 and the function continues.

These issues are both related to the above question.

First issue

When !neg and b == NULL the following operation is preformed likely
resulting in a undefined behavior:

line 164: memcpy(p, b, blen);

memcpy with the b (src) NULL.

Second issue

When b == NULL and n == b, n is decremented while it is NULL likely
resulting in undefined behavior:

line 167: n = b + blen - 1;

line 171:
while (!*n && i > 1) {
    *(p--) = 0;
    n--;
    i--;
}

--
Kurt Cancemi
https://www.x64architecture.com

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From waywardgeek at google.com  Fri Jun 12 17:52:46 2015
From: waywardgeek at google.com (Bill Cox)
Date: Fri, 12 Jun 2015 10:52:46 -0700
Subject: [openssl-dev] Extended master secret goober in s3_srvr.c
Message-ID: <CAH9QtQG3Wvvv58qwfaHqQSHGpi+Xc7bUQts-vLwjHE7=joyzsQ@mail.gmail.com>

Here's some code in master starting at line 594 in s3_srvr.c:

                if (!s->s3->handshake_buffer) {
                    SSLerr(SSL_F_SSL3_ACCEPT, ERR_R_INTERNAL_ERROR);
                    return -1;
                }
                /*
                 * For sigalgs freeze the handshake buffer. If we support
                 * extms we've done this already.
                 */
                if (!(s->s3->flags & SSL_SESS_FLAG_EXTMS)) {
                    s->s3->flags |= TLS1_FLAGS_KEEP_HANDSHAKE;
                    if (!ssl3_digest_cached_records(s))
                        return -1;
                }

The goober is that s->s3->flags does not have a flag for
SSL_SESS_FLAG_EXTMS.  This flag is defined for s->session->flags, not
s->s3->flags.  What happens is that s->s3->flags generally has bit 0 clear,
because this iis the flag for SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS.
Therefore, this generally runs, and we set TLS1_FLAGS_KEEP_HANDSHAKE even
if we have extended master secret support enabled.

I haven't figured out yet what this does in the code.  If it were really
bad, we would have heard about it already.  What was this code supposed to
do, and how should it get fixed?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150612/aba73d08/attachment-0001.html>

From valerie.fenwick at oracle.com  Fri Jun 12 17:53:22 2015
From: valerie.fenwick at oracle.com (Valerie Fenwick)
Date: Fri, 12 Jun 2015 10:53:22 -0700
Subject: [openssl-dev] Regression testing?
Message-ID: <557B1C92.8040204@oracle.com>

Hi Folks -

I was wondering if there is a document anywhere describing what type of testing 
you do before releasing a new version of OpenSSL? I'm guessing you don't test on 
every potential hardware platform, on every potential operating system that 
OpenSSL is used on, but rather a subset.  Is that information posted anywhere?
(ie what that subset is)

I checked the FAQ, but did not see that information in the testing section.

Thank you so much!

Valerie
-- 
NOTE: Using voice recognition software, forgive typos/grammar mistakes!
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

From steve at openssl.org  Fri Jun 12 20:23:30 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 12 Jun 2015 20:23:30 +0000
Subject: [openssl-dev] Extended master secret goober in s3_srvr.c
In-Reply-To: <CAH9QtQG3Wvvv58qwfaHqQSHGpi+Xc7bUQts-vLwjHE7=joyzsQ@mail.gmail.com>
References: <CAH9QtQG3Wvvv58qwfaHqQSHGpi+Xc7bUQts-vLwjHE7=joyzsQ@mail.gmail.com>
Message-ID: <20150612202329.GA13020@openssl.org>

On Fri, Jun 12, 2015, Bill Cox wrote:

> Here's some code in master starting at line 594 in s3_srvr.c:
> 
>                 if (!s->s3->handshake_buffer) {
>                     SSLerr(SSL_F_SSL3_ACCEPT, ERR_R_INTERNAL_ERROR);
>                     return -1;
>                 }
>                 /*
>                  * For sigalgs freeze the handshake buffer. If we support
>                  * extms we've done this already.
>                  */
>                 if (!(s->s3->flags & SSL_SESS_FLAG_EXTMS)) {
>                     s->s3->flags |= TLS1_FLAGS_KEEP_HANDSHAKE;
>                     if (!ssl3_digest_cached_records(s))
>                         return -1;
>                 }
> 
> The goober is that s->s3->flags does not have a flag for
> SSL_SESS_FLAG_EXTMS.  This flag is defined for s->session->flags, not
> s->s3->flags.  What happens is that s->s3->flags generally has bit 0 clear,
> because this iis the flag for SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS.
> Therefore, this generally runs, and we set TLS1_FLAGS_KEEP_HANDSHAKE even
> if we have extended master secret support enabled.
> 
> I haven't figured out yet what this does in the code.  If it were really
> bad, we would have heard about it already.  What was this code supposed to
> do, and how should it get fixed?
> 

Nice catch. That code only gets called when TLS 1.2 client authentication is
used: I think it just means we digest cached records twice instead of once.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rt at openssl.org  Fri Jun 12 20:50:31 2015
From: rt at openssl.org (bug-reporting0000@cneufeld.ca via RT)
Date: Fri, 12 Jun 2015 20:50:31 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <201506121905.t5CJ5TJN030362@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
Message-ID: <rt-4.0.19-12424-1434142231-1663.3905-21-0@openssl.org>

I have compiled and installed OpenSSL v1.0.2b, and find that the 'host'
command segfaults when looking up amazon.ca.  This is with host compiled
from bind-9.9.6-P1.  There is no segfault when running OpenSSL v1.0.2a with
the same 'host' binary.

This is a Linux 64-bit machine, executables and libraries compiled from
sources with no foreign patches.

valgrind reports the following:

==28702== Invalid free() / delete / delete[] / realloc()
==28702==    at 0x4C28BE7: free (vg_replace_malloc.c:473)
==28702==    by 0x64BFFAC: CRYPTO_free (in /usr/lib/engines/libgost.so)
==28702==    by 0x64BAD34: gost_param_free (in /usr/lib/engines/libgost.so)
==28702==    by 0x64BAFB8: gost_engine_destroy (in /usr/lib/engines/libgost.so)
==28702==    by 0x4F3E97B: engine_free_util (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x4F3F103: ENGINE_remove (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x4F3F1D4: engine_list_cleanup (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x4F3E7B5: engine_cleanup_cb_free (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x4F4E0A0: sk_pop_free (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x4F3EABB: ENGINE_cleanup (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x533F19: dst__openssl_destroy (openssl_link.c:266)
==28702==    by 0x4AC2D7: dst_lib_destroy (dst_api.c:261)
==28702==  Address 0x6157d28 is 8 bytes inside a block of size 46 alloc'd
==28702==    at 0x4C27ACD: malloc (vg_replace_malloc.c:296)
==28702==    by 0x54F27D: mem_get (mem.c:796)
==28702==    by 0x54F27D: isc__mem_allocateunlocked (mem.c:1518)
==28702==    by 0x54F7AC: isc___mem_allocate (mem.c:1542)
==28702==    by 0x4E9B287: CRYPTO_malloc (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x4F43757: BUF_strndup (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x64BADE7: gost_set_default_param (in /usr/lib/engines/libgost.so)
==28702==    by 0x4F3FF31: ENGINE_ctrl_cmd_string (in /usr/lib/libcrypto.so.1.0.0)
==28702==    by 0x53745F: dst__opensslgost_init (opensslgost_link.c:433)
==28702==    by 0x4AC51C: dst_lib_init2 (dst_api.c:231)
==28702==    by 0x40E004: setup_libs (dighost.c:1376)
==28702==    by 0x40A087: main (host.c:896)


-- 
 Christopher Neufeld
 Home page:  http://www.cneufeld.ca/neufeld
 "Don't edit reality for the sake of simplicity"

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From matt at openssl.org  Fri Jun 12 22:32:58 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Jun 2015 23:32:58 +0100
Subject: [openssl-dev] Regression testing?
In-Reply-To: <557B1C92.8040204@oracle.com>
References: <557B1C92.8040204@oracle.com>
Message-ID: <557B5E1A.1090803@openssl.org>



On 12/06/15 18:53, Valerie Fenwick wrote:
> Hi Folks -
> 
> I was wondering if there is a document anywhere describing what type of
> testing you do before releasing a new version of OpenSSL? I'm guessing
> you don't test on every potential hardware platform, on every potential
> operating system that OpenSSL is used on, but rather a subset.  Is that
> information posted anywhere?
> (ie what that subset is)
> 
> I checked the FAQ, but did not see that information in the testing section.
> 
> Thank you so much!

Most of our dev work is done on Linux. We also get reports from the
Cisco Jenkins farm which has a number of different platforms on it, so
if we break something we generally know about it quite quickly for these
platforms:

https://openssl-sanity.cisco.com:8443/

During the actual release process itself I check the build on Linux and
on Windows.

Anything else is more reactive based on reports of problems coming in as
and when they occur. Some of the dev team have access to specific
platforms that they test on an occasional basis (e.g. Richard checks VMS
regularly).

Matt


From krzysiek at leeds.pl  Fri Jun 12 22:45:14 2015
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Sat, 13 Jun 2015 00:45:14 +0200
Subject: [openssl-dev] Regression testing?
In-Reply-To: <557B5E1A.1090803@openssl.org>
References: <557B1C92.8040204@oracle.com> <557B5E1A.1090803@openssl.org>
Message-ID: <557B60FA.3050205@leeds.pl>

Hey,

Nice to see this continues build. Have you guys thought about creating 
one build for static code analysis (f.e. integrating cppcheck)?

Kris

On 06/13/2015 12:32 AM, Matt Caswell wrote:
>
> On 12/06/15 18:53, Valerie Fenwick wrote:
>> Hi Folks -
>>
>> I was wondering if there is a document anywhere describing what type of
>> testing you do before releasing a new version of OpenSSL? I'm guessing
>> you don't test on every potential hardware platform, on every potential
>> operating system that OpenSSL is used on, but rather a subset.  Is that
>> information posted anywhere?
>> (ie what that subset is)
>>
>> I checked the FAQ, but did not see that information in the testing section.
>>
>> Thank you so much!
> Most of our dev work is done on Linux. We also get reports from the
> Cisco Jenkins farm which has a number of different platforms on it, so
> if we break something we generally know about it quite quickly for these
> platforms:
>
> https://openssl-sanity.cisco.com:8443/
>
> During the actual release process itself I check the build on Linux and
> on Windows.
>
> Anything else is more reactive based on reports of problems coming in as
> and when they occur. Some of the dev team have access to specific
> platforms that they test on an occasional basis (e.g. Richard checks VMS
> regularly).
>
> Matt
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


From rt at openssl.org  Sat Jun 13 01:40:21 2015
From: rt at openssl.org (Mark.Daniel@wasd.vsm.com.au via RT)
Date: Sat, 13 Jun 2015 01:40:21 +0000
Subject: [openssl-dev] [openssl.org #3906] #3760 FIXED at v1.0.2c
In-Reply-To: <118.210.128.6.63740.00af89484da7e19f.soymail@slider.vsm.com.au>
References: <RT-Ticket-3906@openssl.org>
 <118.210.128.6.63740.00af89484da7e19f.soymail@slider.vsm.com.au>
Message-ID: <rt-4.0.19-17407-1434159621-1806.3906-21-0@openssl.org>

#3760: [BUG] Segmentation fault from s3_svr.c ssl3_choose_cipher()

https://rt.openssl.org/Ticket/Display.html?id=3760

Is no longer exhibiting the reported behaviour.

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From mjos at iki.fi  Sat Jun 13 06:17:03 2015
From: mjos at iki.fi (Markku-Juhani Olavi Saarinen)
Date: Sat, 13 Jun 2015 09:17:03 +0300
Subject: [openssl-dev] OpenSSL offers reviewers for draft-saarinen-blake2
Message-ID: <CA+iU_qmC2oNcdDW5Ch6JzR-aHMWxdVtgBim3y5i+N=_oNLfSng@mail.gmail.com>

Dear RFC-ISE and others,

We submitted the specification of "The BLAKE2 Cryptographic Hash and
MAC" as an informational RFC on February 1, 2015. The document is
currently in its third revision after various contributors have read
it and pointed out minor typographic errors in the original text.
Therefore the editorial quality of the document should be sufficient
at this point. The CFRG was also informed about the existence of the
document. However the document is still in "Finding Reviewers" stage
of the RFC process.
https://tools.ietf.org/html/draft-saarinen-blake2-03

Numerous real-life implementations and applications using BLAKE2
exist, and BLAKE2 is a de facto industry standard hash function.
Therefore the CFRG IETF process has little to contribute to the design
of the algorithm and we, as editors and algorithm designers, see the
current Internet Draft as a final specification. This is why the
document was put out as an independent submission like many other
cryptographic algorithms. See https://blake2.net/

Recently the OpenSSL development community has expressed renewed
interest in having the document finalized as an RFC and they seem to
consider this to be a prerequisite of BLAKE2's adoption into the main
branch of OpenSSL (although this has not historically been the case
for all algorithms). This would especially help in including BLAKE2 in
various possible TLS ciphersuites. TLS appears to especially require
new PRF and MAC options.

If you are still seeking reviewers, you may find Yoav Nir's comments
below. There appears to be significant industry pressure to help this
document to obtain its RFC number and the open development community
is willing to offer any assistance required. Note that
draft-saarinen-blake2 this is *not* a protocol specification, just a
"FYI" specification for the Internet Community about this particular
independent cryptographic primitive.

You may approach me (the editor of draft-saarinen-blake2) privately if
you require additional reviewers or commentary but want to avoid the
openssl-dev mailing list.

Best Regards,
- markku

Dr. Markku-Juhani O. Saarinen <mjos at iki.fi>

---------- Forwarded message ----------
From: Yoav Nir <ynir.ietf at gmail.com>
Date: Thu, Jun 11, 2015 at 10:15 AM
Subject: Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2
hash function (let's kill md5sum!)
To: openssl-dev at openssl.org


That shouldn?t be too difficult (finding reviewers, I mean).

Is the ISE asking for volunteers to review? What kind of volunteers?
IMO what a reviewer needs to be able to say is:
 - The document is clear (you can implement based on this)
 - The algorithm might be useful in the IETF
 - The security claims are sufficient to what IETF protocols need
 - The security claims are backed up by either peer-reviewed academic
papers or equivalent

So there?s a lot of people who can do all that. You don?t even need
real cryptographers, although having at least one would be good. What
is holding things up?

Yoav


On Jun 11, 2015, at 11:50 AM, Jean-Philippe Aumasson
<jeanphilippe.aumasson at gmail.com> wrote:

The status of the draft is unchanged ("Finding Reviewers"). Perhaps
OpenSSL can speed up the review process.

BLAKE2 has a keyed (aka MAC/PRF) mode, so it may also replace
Poly1305. A BLAKE2 MAC can be customized wrt key or tag size, and can
provide the highest security level for a give key/tag size
combination.

From rt at openssl.org  Sat Jun 13 09:49:34 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Sat, 13 Jun 2015 09:49:34 +0000
Subject: [openssl-dev] [openssl.org #3760] [BUG] Segmentation fault from
	s3_svr.c ssl3_choose_cipher()
In-Reply-To: <14.2.0.218.54642.00af488edd8a5bd8.soymail@slider.vsm.com.au>
References: <RT-Ticket-3760@openssl.org>
 <14.2.0.218.54642.00af488edd8a5bd8.soymail@slider.vsm.com.au>
Message-ID: <rt-4.0.19-10987-1434188974-228.3760-6-0@openssl.org>

Great. Thanks for letting us know. Closing this ticket.

Matt


From rsalz at akamai.com  Sat Jun 13 13:12:29 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 13 Jun 2015 13:12:29 +0000
Subject: [openssl-dev] OpenSSL offers reviewers for draft-saarinen-blake2
In-Reply-To: <CA+iU_qmC2oNcdDW5Ch6JzR-aHMWxdVtgBim3y5i+N=_oNLfSng@mail.gmail.com>
References: <CA+iU_qmC2oNcdDW5Ch6JzR-aHMWxdVtgBim3y5i+N=_oNLfSng@mail.gmail.com>
Message-ID: <b74619c897404d23be5937315d1facce@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Recently the OpenSSL development community has expressed renewed
> interest in having the document finalized as an RFC and they seem to
> consider this to be a prerequisite of BLAKE2's adoption into the main branch
> of OpenSSL

This is not true.  The topic of RFC-or-not has never come up in any OpenSSL discussions that I have seen.

Please be careful about reply-all.

         /r$


From rt at openssl.org  Sat Jun 13 13:13:23 2015
From: rt at openssl.org (Rainer Jung via RT)
Date: Sat, 13 Jun 2015 13:13:23 +0000
Subject: [openssl-dev] [openssl.org #3907] Script testssl uses bash feature
	(non-POSIX)
In-Reply-To: <557BEFB2.7010007@kippdata.de>
References: <RT-Ticket-3907@openssl.org> <557BEFB2.7010007@kippdata.de>
Message-ID: <rt-4.0.19-17407-1434201203-1347.3907-21-0@openssl.org>

The script test/testssl uses the "local" keywork in test_cipher() since 
commit 
https://github.com/openssl/openssl/commit/e8356e32aed70d139eae2d05aeaeb160509262aa 
(master, merged at least to 1.0.1 and 1.0.2).

This keyword is non-POSIX but the script is supposed to be run with 
/bin/sh. E.g. on Solaris systems this will produce an error

./testssl: local: not found

because the shell does not understand "local" as a keyword and tries to 
find an executable "local" in the path.

Currently this error is not fatal, because the keyword is used to mark 
the variables "cipher" and "protocol" as local. They are set from the 
first and second arguments of the function, which is simply ignored when 
the error happens. Fortunately all calls to the function pass global 
variables "cipher" and "protocol" as first and second arguments, so the 
failure is transparent since the global variables of the same name 
already have the correct values. $cipher and $protocol will still 
provide the correct contents in the function.

Possible fixes are:

- demand running the script using bash. Not all systems might provide 
bash though.

- simply removing the local keyword. Currently the script would 
overwrite the global variables cipher and protocol in test_cipher(), but 
those are only used to actually pass arguments to this function, so 
overwriting has no side effect

- removing the local keyword and renaming the local variables cipher and 
protocol so something like localCipher and localProtocol to remind about 
their scope. I suggest using this workaround.

I think there's no POSIX compliant way to scope variables in shell, at 
least not without playing difficult to read eval games.

Thanks,

Rainer

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Sat Jun 13 13:13:26 2015
From: rt at openssl.org (Peter Dettman via RT)
Date: Sat, 13 Jun 2015 13:13:26 +0000
Subject: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat
	issues (vs latest git master)
In-Reply-To: <557BEC9C.9040204@bouncycastle.org>
References: <RT-Ticket-3908@openssl.org> <557BEC9C.9040204@bouncycastle.org>
Message-ID: <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>

Hi,
Please find attached a patch against the current git master that fixes 
some problems in TLS (and DTLS) heartbeats. This patch supercedes the 
original pull request I made closer to the time of heartbleed 
(https://github.com/openssl/openssl/pull/66), which I neglected to 
report to rt.

The following 2 issues are addressed by the patch:

1. The current implementation includes 16 bytes of random data in the 
payload (after the sequence number). To clarify, RFC 6520 requires 16 
bytes minimum of random _padding_. There's no such requirement on the 
payload, which may be arbitrary - but this is essentially pointless (or 
worse). Furthermore, the response processor is not verifying that the 
response payload actually echoes this data correctly. The patch removes 
this extra random data from heartbeat requests, also making the 
verification issue moot.

2. For a long-running connection, tlsext_hb_seq could grow beyond 16 
bits (where sizeof(unsigned int) > 2), so the response processor should 
only compare that the bottom 16 bits match. The patch changes that 
comparison (alternatively tlsext_hb_seq++ could explicitly wrap to 0).

Regards,
Pete Dettman


-------------- next part --------------
diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index 155b8bf..a227b7e 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -1404,15 +1404,16 @@ int dtls1_process_heartbeat(SSL *s, unsigned char *p, unsigned int length)
         unsigned int seq;
 
         /*
-         * We only send sequence numbers (2 bytes unsigned int), and 16
-         * random bytes, so we just try to read the sequence number
+         * We only send sequence numbers (2 bytes unsigned int),
+         * so we confirm the response payload matches that.
          */
-        n2s(pl, seq);
-
-        if (payload == 18 && seq == s->tlsext_hb_seq) {
-            dtls1_stop_timer(s);
-            s->tlsext_hb_seq++;
-            s->tlsext_hb_pending = 0;
+        if (2 == payload) {
+            n2s(pl, seq);
+            if (seq == (s->tlsext_hb_seq & 0xffff)) {
+                dtls1_stop_timer(s);
+                s->tlsext_hb_seq++;
+                s->tlsext_hb_pending = 0;
+            }
         }
     }
 
@@ -1423,7 +1424,7 @@ int dtls1_heartbeat(SSL *s)
 {
     unsigned char *buf, *p;
     int ret = -1;
-    unsigned int payload = 18;  /* Sequence number + random bytes */
+    unsigned int payload = 2;   /* Sequence number */
     unsigned int padding = 16;  /* Use minimum padding */
 
     /* Only send if peer supports and accepts HB requests... */
@@ -1453,13 +1454,11 @@ int dtls1_heartbeat(SSL *s)
 
     /*-
      * Create HeartBeat message, we just use a sequence number
-     * as payload to distuingish different messages and add
-     * some random stuff.
+     * as payload to distinguish different messages.
      *  - Message Type, 1 byte
      *  - Payload Length, 2 bytes (unsigned int)
      *  - Payload, the sequence number (2 bytes uint)
-     *  - Payload, random bytes (16 bytes uint)
-     *  - Padding
+     *  - Padding (16 random bytes)
      */
     buf = OPENSSL_malloc(1 + 2 + payload + padding);
     if (buf == NULL) {
@@ -1469,16 +1468,10 @@ int dtls1_heartbeat(SSL *s)
     p = buf;
     /* Message Type */
     *p++ = TLS1_HB_REQUEST;
-    /* Payload length (18 bytes here) */
+    /* Payload length */
     s2n(payload, p);
-    /* Sequence number */
+    /* Sequence number (low 16 bits) */
     s2n(s->tlsext_hb_seq, p);
-    /* 16 random bytes */
-    if (RAND_bytes(p, 16) <= 0) {
-        SSLerr(SSL_F_DTLS1_HEARTBEAT, ERR_R_INTERNAL_ERROR);
-        goto err;
-    }
-    p += 16;
     /* Random padding */
     if (RAND_bytes(p, padding) <= 0) {
         SSLerr(SSL_F_DTLS1_HEARTBEAT, ERR_R_INTERNAL_ERROR);
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 402047a..d7938f5 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -3636,14 +3636,15 @@ int tls1_process_heartbeat(SSL *s, unsigned char *p, unsigned int length)
         unsigned int seq;
 
         /*
-         * We only send sequence numbers (2 bytes unsigned int), and 16
-         * random bytes, so we just try to read the sequence number
+         * We only send sequence numbers (2 bytes unsigned int),
+         * so we confirm the response payload matches that.
          */
-        n2s(pl, seq);
-
-        if (payload == 18 && seq == s->tlsext_hb_seq) {
-            s->tlsext_hb_seq++;
-            s->tlsext_hb_pending = 0;
+        if (2 == payload) {
+            n2s(pl, seq);
+            if (seq == (s->tlsext_hb_seq & 0xffff)) {
+                s->tlsext_hb_seq++;
+                s->tlsext_hb_pending = 0;
+            }
         }
     }
 
@@ -3654,7 +3655,7 @@ int tls1_heartbeat(SSL *s)
 {
     unsigned char *buf, *p;
     int ret = -1;
-    unsigned int payload = 18;  /* Sequence number + random bytes */
+    unsigned int payload = 2;   /* Sequence number */
     unsigned int padding = 16;  /* Use minimum padding */
 
     /* Only send if peer supports and accepts HB requests... */
@@ -3684,13 +3685,11 @@ int tls1_heartbeat(SSL *s)
 
     /*-
      * Create HeartBeat message, we just use a sequence number
-     * as payload to distuingish different messages and add
-     * some random stuff.
+     * as payload to distinguish different messages.
      *  - Message Type, 1 byte
      *  - Payload Length, 2 bytes (unsigned int)
      *  - Payload, the sequence number (2 bytes uint)
-     *  - Payload, random bytes (16 bytes uint)
-     *  - Padding
+     *  - Padding (16 random bytes)
      */
     buf = OPENSSL_malloc(1 + 2 + payload + padding);
     if (buf == NULL) {
@@ -3700,16 +3699,10 @@ int tls1_heartbeat(SSL *s)
     p = buf;
     /* Message Type */
     *p++ = TLS1_HB_REQUEST;
-    /* Payload length (18 bytes here) */
+    /* Payload length */
     s2n(payload, p);
-    /* Sequence number */
+    /* Sequence number (low 16 bits) */
     s2n(s->tlsext_hb_seq, p);
-    /* 16 random bytes */
-    if (RAND_bytes(p, 16) <= 0) {
-        SSLerr(SSL_F_TLS1_HEARTBEAT, ERR_R_INTERNAL_ERROR);
-        goto err;
-    }
-    p += 16;
     /* Random padding */
     if (RAND_bytes(p, padding) <= 0) {
         SSLerr(SSL_F_TLS1_HEARTBEAT, ERR_R_INTERNAL_ERROR);
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From hanno at hboeck.de  Sat Jun 13 13:43:25 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Sat, 13 Jun 2015 15:43:25 +0200
Subject: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat
 issues (vs latest git master)
In-Reply-To: <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>
References: <RT-Ticket-3908@openssl.org> <557BEC9C.9040204@bouncycastle.org>
 <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>
Message-ID: <20150613154325.55122a6b@pc1>

Serious question: Is there any valid use case for heartbeats in TLS or
DTLS?
(With valid use case I mean something like "I use it for this system",
not answers like "you could use it for xy")

I asked this question in the heartbleed aftermath a couple of times and
never got any reasonable answer. I have the feeling the only reason
this extension exists is that someone needed a topic for his thesis.

If this extension isn't used then I think it shouldn't be fixed. It
should be removed. I think complexity is responsible for a large chunk
of the problems TLS has these days, therefore everything that can be
removed should be.

-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150613/7f3b329e/attachment.sig>

From ynir.ietf at gmail.com  Sat Jun 13 13:49:25 2015
From: ynir.ietf at gmail.com (Yoav Nir)
Date: Sat, 13 Jun 2015 16:49:25 +0300
Subject: [openssl-dev] OpenSSL offers reviewers for draft-saarinen-blake2
In-Reply-To: <b74619c897404d23be5937315d1facce@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CA+iU_qmC2oNcdDW5Ch6JzR-aHMWxdVtgBim3y5i+N=_oNLfSng@mail.gmail.com>
 <b74619c897404d23be5937315d1facce@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <DC7611B2-4EDF-42F3-B4C6-736E669239E2@gmail.com>


> On Jun 13, 2015, at 4:12 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> 
>> Recently the OpenSSL development community has expressed renewed
>> interest in having the document finalized as an RFC and they seem to
>> consider this to be a prerequisite of BLAKE2's adoption into the main branch
>> of OpenSSL
> 
> This is not true.  The topic of RFC-or-not has never come up in any OpenSSL discussions that I have seen.

Except the previous thread.

An RFC is not needed to get an algorithm into OpenSSL. It *is* necessary if we want ciphersuites for TLS, signature hashes for certificates PRFs and MACs for IKE/IPsec etc.

None of the bodies standardizing those will go with an algorithms whose sole specifications are a website maintained by the people who invented the algorithm and a wikipedia article. That?s where an RFC can help, just like RFC 7539 was needed to get ChaCha20-Poly1305 into TLS and IPsecME drafts. With a good RFC we can push TLS, IPsecME, and PKIX drafts, perhaps even get some interest from CAs in the CA/BF.

With Blake2 getting no use at all in browsers, web servers, VPN gateways and certificates, I don?t even know what "BLAKE2 is a de facto industry standard hash function? means.

Yoav

From rt at openssl.org  Sat Jun 13 14:02:48 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Sat, 13 Jun 2015 14:02:48 +0000
Subject: [openssl-dev] [openssl.org #3463] [PATCH] Add support of
	no_application_protocol alert in ALPN protocol selection
In-Reply-To: <CAFdNdFsNLTy9Y26o2oB4hRqOvtKV+0OccrDyC=GC9jo7E509dg@mail.gmail.com>
References: <RT-Ticket-3463@openssl.org>
 <CAFdNdFsNLTy9Y26o2oB4hRqOvtKV+0OccrDyC=GC9jo7E509dg@mail.gmail.com>
Message-ID: <rt-4.0.19-17407-1434204168-1857.3463-6-0@openssl.org>

So, the google approach is that if no protocol match is found, the server
replies WITHOUT the alpn header. They don't like no_app_protocol, to put it
mildly :)

thoughts?


From rt at openssl.org  Sat Jun 13 14:05:20 2015
From: rt at openssl.org (Raghavendra Prabhu via RT)
Date: Sat, 13 Jun 2015 14:05:20 +0000
Subject: [openssl-dev] [openssl.org #3909] Crash due to non-checking of
	return value / errno of malloc
In-Reply-To: <CAEtq3tN7EySqcbuOLRQmY6exB4JLMv+9fafTJoFX-M-T_dNH+A@mail.gmail.com>
References: <RT-Ticket-3909@openssl.org>
 <CAEtq3tN7EySqcbuOLRQmY6exB4JLMv+9fafTJoFX-M-T_dNH+A@mail.gmail.com>
Message-ID: <rt-4.0.19-10987-1434204320-669.3909-21-0@openssl.org>

Hi

While using https://github.com/libhostile/libhostile/, with

hostile.sh -m 100 curl -L http://...
(It LD_PRELOADs through that script and makes malloc fail (by returning
ENOMEM before actual malloc is invoked) every 100 invocations or so).

I started noticing a crash in every 5-6 invocations. (Other times curl
reports with error 7 - out of memory among others but there is no crash).

===========
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/curl...(no debugging symbols found)...done.
[New LWP 6606]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `curl -L http://percona.com'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  SHA1_Update (c=0x0, data_=0x7ffc2f4dd03c, len=4) at ../md32_common.h:310
310         l = (c->Nl + (((HASH_LONG) len) << 3)) & 0xffffffffUL;
(gdb) bt
#0  SHA1_Update (c=0x0, data_=0x7ffc2f4dd03c, len=4) at ../md32_common.h:310
#1  0x00007f8a4a7b09d8 in ssleay_rand_bytes (buf=0x1071230 "", num=6,
pseudo=1, lock=1) at md_rand.c:475
#2  0x00007f8a4ab3666e in SSL_CTX_new (meth=0x7f8a4ad5daa0
<SSLv23_client_method_data.16764>) at ssl_lib.c:1992
#3  0x00007f8a4c017260 in ossl_connect_common () from /usr/lib/libcurl.so.4
#4  0x00007f8a4c01acc0 in Curl_ssl_connect_nonblocking () from
/usr/lib/libcurl.so.4
#5  0x00007f8a4bfd42ad in Curl_http_connect () from /usr/lib/libcurl.so.4
#6  0x00007f8a4bfe5471 in Curl_protocol_connect () from
/usr/lib/libcurl.so.4
#7  0x00007f8a4bff928e in multi_runsingle () from /usr/lib/libcurl.so.4
#8  0x00007f8a4bff9ead in curl_multi_perform () from /usr/lib/libcurl.so.4
#9  0x00007f8a4bff0aeb in curl_easy_perform () from /usr/lib/libcurl.so.4
#10 0x000000000040b44f in operate_do ()
#11 0x000000000040ce0d in operate ()
#12 0x000000000040245c in main ()
(gdb) info args
c = 0x0
data_ = 0x7ffc2f4dd03c
len = 4
(gdb) print *data
Cannot access memory at address 0xa
(gdb) print data
$1 = (const unsigned char *) 0xa <error: Cannot access memory at address
0xa>
(gdb) quit
=========================================


What that tool does is make malloc fail every 100 invocations with some
jitter/randomization.

Noticed with openssl 1.0.2c.

[Filed this earlier under openssl-security at openssl.org but was redirected
to file it here].

-----------
Raghavendra

-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rsalz at akamai.com  Sat Jun 13 14:09:58 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 13 Jun 2015 14:09:58 +0000
Subject: [openssl-dev] Regression testing?
In-Reply-To: <557B60FA.3050205@leeds.pl>
References: <557B1C92.8040204@oracle.com> <557B5E1A.1090803@openssl.org>
 <557B60FA.3050205@leeds.pl>
Message-ID: <67c3550973624d24a2a973a5ccdf18df@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Nice to see this continues build. Have you guys thought about creating one
> build for static code analysis (f.e. integrating cppcheck)?

So the FB folks seem to be interested in helping with infer, which is neat (see RT 3903).  We periodically look at Coverity.  What's involved in doing cppcheck?

From rsalz at akamai.com  Sat Jun 13 14:11:20 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 13 Jun 2015 14:11:20 +0000
Subject: [openssl-dev] Regression testing?
In-Reply-To: <557B1C92.8040204@oracle.com>
References: <557B1C92.8040204@oracle.com>
Message-ID: <b055099a44b64ea9886f71ea478c95ca@ustx2ex-dag1mb2.msg.corp.akamai.com>


> I was wondering if there is a document anywhere describing what type of
> testing you do before releasing a new version of OpenSSL?

Matt already gave some answers.  Our biggest regression test is "make test" at the top-level.  We've recently gotten much better at adding more tests...

Any help gratefully received :)

	/r$



From rsalz at akamai.com  Sat Jun 13 14:42:23 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 13 Jun 2015 14:42:23 +0000
Subject: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat
 issues (vs latest git master)
In-Reply-To: <20150613154325.55122a6b@pc1>
References: <RT-Ticket-3908@openssl.org> <557BEC9C.9040204@bouncycastle.org>
 <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>
 <20150613154325.55122a6b@pc1>
Message-ID: <e150dc11b0544b51a7f54afdaa92b83c@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Serious question: Is there any valid use case for heartbeats in TLS or DTLS?

For TLS, I can't see one.

I would be happy if the code vanished for DTLS. :)

From rt at openssl.org  Sat Jun 13 21:20:39 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Sat, 13 Jun 2015 21:20:39 +0000
Subject: [openssl-dev] [openssl.org #3907] Script testssl uses bash feature
	(non-POSIX)
In-Reply-To: <557BEFB2.7010007@kippdata.de>
References: <RT-Ticket-3907@openssl.org> <557BEFB2.7010007@kippdata.de>
Message-ID: <rt-4.0.19-31900-1434230439-365.3907-6-0@openssl.org>

Thanks. Seems the simplest thing is just use $1 and $2 ... Will be fixed in
master, and 1.0.0/1/2
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Sun Jun 14 02:55:05 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 14 Jun 2015 02:55:05 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in and
	-out files are same
In-Reply-To: <46271FE7.4050201@gmail.com>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
Message-ID: <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>

One possiblity is open in exclusive mode. The problem is that O_EXCL is only
part of open(2), not fopen(3). And we have to use fopen() because we need the
"b" mode for binary output on platforms that require it. So I don't think that
will work, either.


From peter.dettman at bouncycastle.org  Sun Jun 14 03:38:30 2015
From: peter.dettman at bouncycastle.org (Peter Dettman)
Date: Sun, 14 Jun 2015 10:38:30 +0700
Subject: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat
 issues (vs latest git master)
In-Reply-To: <20150613154325.55122a6b@pc1>
References: <RT-Ticket-3908@openssl.org> <557BEC9C.9040204@bouncycastle.org>
 <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>
 <20150613154325.55122a6b@pc1>
Message-ID: <557CF736.7090704@bouncycastle.org>

On 13/06/2015 8:43 pm, Hanno B?ck wrote:
> Serious question: Is there any valid use case for heartbeats in TLS or
> DTLS?
> (With valid use case I mean something like "I use it for this system",
> not answers like "you could use it for xy")
I don't use them for anything. We started to implement them for 
BouncyCastle (D)TLS before heartbleed, but I can't see us ever actually 
finishing that, and none of our users has ever asked for them.

> I asked this question in the heartbleed aftermath a couple of times and
> never got any reasonable answer. I have the feeling the only reason
> this extension exists is that someone needed a topic for his thesis.
I'm more cynical and suspect heartbeats to have been designed to 
complement the Dual EC exploitation outlined at 
https://projectbullrun.org/dual-ec/index.html as a possible source of 
attacker-visible PRNG output (quite separate to whatever suspicions 
arise from Heartbleed itself).

>
> If this extension isn't used then I think it shouldn't be fixed. It
> should be removed. I think complexity is responsible for a large chunk
> of the problems TLS has these days, therefore everything that can be
> removed should be.
No objections here, although I'd prefer to see the patch applied before 
any removal, since others may take it upon themselves to keep or copy 
the code.

Regards,
Pete Dettman




From aaronmdjones at gmail.com  Sun Jun 14 06:09:28 2015
From: aaronmdjones at gmail.com (Aaron Jones)
Date: Sun, 14 Jun 2015 06:09:28 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in
 and -out files are same
In-Reply-To: <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
 <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
Message-ID: <557D1A98.9000001@gmail.com>

On 14/06/15 02:55, Rich Salz via RT wrote:
> One possiblity is open in exclusive mode. The problem is that O_EXCL is only
> part of open(2), not fopen(3). And we have to use fopen() because we need the
> "b" mode for binary output on platforms that require it. So I don't think that
> will work, either.

Do those platforms not have fdopen(3) with the same "b" semantics?

I note fdopen(3) is a POSIX thing, and "b" has no effect on POSIX
systems, so perhaps not. Worth a look though?

Failing that, you could fstat(3) the 2 open files and compare their
st_ino and st_dev fields for equality before writing anything to either
of them.

-- 
Aaron Jones


From rt at openssl.org  Sun Jun 14 06:09:47 2015
From: rt at openssl.org (Aaron Jones via RT)
Date: Sun, 14 Jun 2015 06:09:47 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in
	and -out files are same
In-Reply-To: <557D1A98.9000001@gmail.com>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
 <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
 <557D1A98.9000001@gmail.com>
Message-ID: <rt-4.0.19-31751-1434262187-965.1520-6-0@openssl.org>

On 14/06/15 02:55, Rich Salz via RT wrote:
> One possiblity is open in exclusive mode. The problem is that O_EXCL is only
> part of open(2), not fopen(3). And we have to use fopen() because we need the
> "b" mode for binary output on platforms that require it. So I don't think that
> will work, either.

Do those platforms not have fdopen(3) with the same "b" semantics?

I note fdopen(3) is a POSIX thing, and "b" has no effect on POSIX
systems, so perhaps not. Worth a look though?

Failing that, you could fstat(3) the 2 open files and compare their
st_ino and st_dev fields for equality before writing anything to either
of them.

-- 
Aaron Jones



From openssl-users at dukhovni.org  Sun Jun 14 15:45:35 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 14 Jun 2015 15:45:35 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in
 and -out files are same
In-Reply-To: <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
 <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
Message-ID: <20150614154534.GB14121@mournblade.imrryr.org>

On Sun, Jun 14, 2015 at 02:55:05AM +0000, Rich Salz via RT wrote:

> One possiblity is open in exclusive mode. The problem is that O_EXCL is only
> part of open(2), not fopen(3). And we have to use fopen() because we need the
> "b" mode for binary output on platforms that require it. So I don't think that
> will work, either.

This is not the right approach anyway.  To avoid clobbering the
input file we need to avoid overwriting just that particular file,
not any already existing file.  It must be possible to use "-out"
to overwrite existing files.

A more critical deficiencydefects in how output is written by the
software in apps/ is:

    * Private key output files are created with "0666" permissions
      modulo umask.  They should be created with "0600" permissions.

I've never run into a situation where the output file I want to
write to is also an input to the command in question.  What's your
use-case?

As for "b" mode and the like, that can be handled with fdopen(3)
after open(2).  To check wether an output file is one of the input
files, open it for write without truncation, then check with fstat()
whether it is one of the input files, and if not truncate, otherwise
bail out.  Still what problem are we trying to solve here?

-- 
	Viktor.

From krzysiek at leeds.pl  Sun Jun 14 16:07:03 2015
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Sun, 14 Jun 2015 18:07:03 +0200
Subject: [openssl-dev] Regression testing?
In-Reply-To: <67c3550973624d24a2a973a5ccdf18df@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <557B1C92.8040204@oracle.com> <557B5E1A.1090803@openssl.org>
 <557B60FA.3050205@leeds.pl>
 <67c3550973624d24a2a973a5ccdf18df@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <557DA6A7.8040507@leeds.pl>

Hi,

It's pretty easy to run cppcheck. It also integrates quite well with 
jenkins, as there is cppcheck plugin available. You can find mine 
configuration right here if interested:
http://amongbits.com:8090/job/openssl/ (guest/guest for login/pass)


I don't have much experience with Coverity, but I'm guessing is much 
better then cppcheck. Nevertheless cppcheck also produces some 
interesting results. For example it has found real bug here:
http://amongbits.com:8090/job/openssl/17/cppcheckResult/source.977/#659


Regards,
Kris


On 06/13/2015 04:09 PM, Salz, Rich wrote:
>> Nice to see this continues build. Have you guys thought about creating one
>> build for static code analysis (f.e. integrating cppcheck)?
> So the FB folks seem to be interested in helping with infer, which is neat (see RT 3903).  We periodically look at Coverity.  What's involved in doing cppcheck?
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


From rsalz at akamai.com  Sun Jun 14 23:31:35 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 14 Jun 2015 23:31:35 +0000
Subject: [openssl-dev] [openssl.org #1520] request for checking if -in
 and -out files are same
In-Reply-To: <20150614154534.GB14121@mournblade.imrryr.org>
References: <RT-Ticket-1520@openssl.org> <46271FE7.4050201@gmail.com>
 <rt-4.0.19-31900-1434250505-1190.1520-6-0@openssl.org>
 <20150614154534.GB14121@mournblade.imrryr.org>
Message-ID: <696af4c6264b47c2af21b1a2549517db@ustx2ex-dag1mb2.msg.corp.akamai.com>


>     * Private key output files are created with "0666" permissions
>       modulo umask.  They should be created with "0600" permissions.

https://gitlab.openssl.org/openssl/openssl/merge_requests/668
to fix RT 2547.  Opened about a month ago.

>  Still what problem are we
> trying to solve here?

Protecting users when they do
	openssl command -in xxx -out xxx

RT 1530, which I closed as wontfix some time ago.


From rt at openssl.org  Sun Jun 14 23:59:59 2015
From: rt at openssl.org (84.le0n via RT)
Date: Sun, 14 Jun 2015 23:59:59 +0000
Subject: [openssl-dev] [openssl.org #3910] [PATCH] Build correctly when
	no_des option is enabled
In-Reply-To: <CAHtW0Z_tgjz=Gp-Sk2kVKMxC2Fe_J09TRVraHj5m2srfOg0jiA@mail.gmail.com>
References: <RT-Ticket-3910@openssl.org>
 <CAHtW0Z_tgjz=Gp-Sk2kVKMxC2Fe_J09TRVraHj5m2srfOg0jiA@mail.gmail.com>
Message-ID: <rt-4.0.19-5892-1434326399-1050.3910-21-0@openssl.org>

Hi all,
this is my first email on this mailing list even if I use OpenSSL since
years.

I've had the same problem Osvaldo Calles had when building OpenSSL with
no-des option enabled .
This patch simply add an #ifndef around the first if clause avoiding
EVP_des_ede3_wrap call.


Gabriele Pongelli.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_des.patch
Type: application/octet-stream
Size: 3234 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150614/428fd10f/attachment.obj>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rt at openssl.org  Mon Jun 15 02:31:05 2015
From: rt at openssl.org (bug-reporting0000@cneufeld.ca via RT)
Date: Mon, 15 Jun 2015 02:31:05 +0000
Subject: [openssl-dev] [openssl.org #3905] Followup information
In-Reply-To: <201506150230.t5F2UhmE013812@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
 <rt-4.0.19-12424-1434142231-1971.3905-3-0@openssl.org>
 <201506150230.t5F2UhmE013812@cneufeld.ca>
Message-ID: <rt-4.0.19-5892-1434335465-1413.3905-6-0@openssl.org>

In case it's not obvious from the valgrind output, it appears that what is
happening is that OpenSSL's crypto/mem.c is calling the ISC bind's private
allocator (isc___mem_allocate) instead of malloc(3).  This ISC function
seems to be a system that mallocs a large block of memory and then hands
out pieces of it without while maintaining its own bookkeeping.  However,
crypto/mem.c still uses the original free(3), it doesn't see isc___mem_free
to release memory by the same rules.  The result is a rogue free() call
partway into the block that ISC bind allocated, and a segfault.

I haven't figured out yet why the ISC bind allocator is getting caught up
in libcrypto, or what changed between 1.0.2a and 1.0.2b to cause this to
become visible.


-- 
 Christopher Neufeld
 Home page:  http://www.cneufeld.ca/neufeld
 "Don't edit reality for the sake of simplicity"



From rt at openssl.org  Mon Jun 15 03:29:12 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 15 Jun 2015 03:29:12 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <rt-4.0.19-5892-1434335465-930.3905-6-0@openssl.org>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
 <rt-4.0.19-12424-1434142231-1971.3905-3-0@openssl.org>
 <201506150230.t5F2UhmE013812@cneufeld.ca>
 <rt-4.0.19-5892-1434335465-930.3905-6-0@openssl.org>
Message-ID: <rt-4.0.19-5892-1434338952-479.3905-6-0@openssl.org>

It's strange that CRYPTO_malloc ends up calling ISC-malloc, but CRYPTO_free
does not. This is strange, but really hard to see how this is an openssl issue.


From rt at openssl.org  Mon Jun 15 04:50:02 2015
From: rt at openssl.org (Shigeki Ohtsu via RT)
Date: Mon, 15 Jun 2015 04:50:02 +0000
Subject: [openssl-dev] [openssl.org #3463] [PATCH] Add support of
	no_application_protocol alert in ALPN protocol selection
In-Reply-To: <CAFdNdFue7595mX+YrRP89j7xacPSX+N6Lek=nH0NL-Kt2H_xKA@mail.gmail.com>
References: <RT-Ticket-3463@openssl.org>
 <CAFdNdFsNLTy9Y26o2oB4hRqOvtKV+0OccrDyC=GC9jo7E509dg@mail.gmail.com>
 <rt-4.0.19-17407-1434204168-1857.3463-6-0@openssl.org>
 <CAFdNdFue7595mX+YrRP89j7xacPSX+N6Lek=nH0NL-Kt2H_xKA@mail.gmail.com>
Message-ID: <rt-4.0.19-4559-1434343802-1163.3463-6-0@openssl.org>

The Google's approach is keeping connection and expecting the client
continues to speak http/1.1 as a fail-back protocol.
This is one approach but I don't think it is all the cases.

For example when the server only provides a service that binds to the
specific protocol or tests some experimental protocols over TLS,
the server does not need to keep the connection and closes it because there
are no fail-back protocol.

It is natural for a server to send a no_application_protocol alert to
notify its error to the client before closing as well as it does in
handshake_failure.
According to RFC7301 it is defined SHALL so that the client which is
implemented with the spec properly can recognize the alert correctly.

I look back my patch now and it was really old and needs some changes. If
it would be accepted, I'd like to revise it.




2015-06-13 23:02 GMT+09:00 Rich Salz via RT <rt at openssl.org>:

> So, the google approach is that if no protocol match is found, the server
> replies WITHOUT the alpn header. They don't like no_app_protocol, to put it
> mildly :)
>
> thoughts?
>
>


From ohtsu at iij.ad.jp  Mon Jun 15 04:54:52 2015
From: ohtsu at iij.ad.jp (Shigeki Ohtsu)
Date: Mon, 15 Jun 2015 13:54:52 +0900
Subject: [openssl-dev] [openssl.org #3463] [PATCH] Add support of
 no_application_protocol alert in ALPN protocol selection
In-Reply-To: <rt-4.0.19-17407-1434204168-1857.3463-6-0@openssl.org>
References: <RT-Ticket-3463@openssl.org>
 <CAFdNdFsNLTy9Y26o2oB4hRqOvtKV+0OccrDyC=GC9jo7E509dg@mail.gmail.com>
 <rt-4.0.19-17407-1434204168-1857.3463-6-0@openssl.org>
Message-ID: <557E5A9C.108@iij.ad.jp>


The Google's approach is keeping connection and expecting the client 
continues to speak http/1.1 as a fail-back protocol.
This is one approach but I don't think it is all the cases.

For example when a server only provides a service that binds to the 
specific protocol or tests some experimental protocols over TLS,
the server does not need to keep the connection and closes it in the 
case of no matching because there are no fail-back protocol.

It is natural for a server to send a no_application_protocol alert to 
notify its error to the client before closing as well as it does in 
handshake_failure.
According to RFC7301 it is defined SHALL so that the client which is 
implemented with the spec properly can recognize the alert correctly.

I look back my patch now and it was really old and needs some changes. 
If it would be accepted, I'd like to revise it.

On 2015/06/13 23:02, Rich Salz via RT wrote:
> So, the google approach is that if no protocol match is found, the server
> replies WITHOUT the alpn header. They don't like no_app_protocol, to put it
> mildly :)
>
> thoughts?
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From rt at openssl.org  Mon Jun 15 05:04:45 2015
From: rt at openssl.org (Shigeki Ohtsu via RT)
Date: Mon, 15 Jun 2015 05:04:45 +0000
Subject: [openssl-dev] [openssl.org #3463] [PATCH] Add support of
	no_application_protocol alert in ALPN protocol selection
In-Reply-To: <557E5A9C.108@iij.ad.jp>
References: <RT-Ticket-3463@openssl.org>
 <CAFdNdFsNLTy9Y26o2oB4hRqOvtKV+0OccrDyC=GC9jo7E509dg@mail.gmail.com>
 <rt-4.0.19-17407-1434204168-1857.3463-6-0@openssl.org>
 <557E5A9C.108@iij.ad.jp>
Message-ID: <rt-4.0.19-5892-1434344685-972.3463-6-0@openssl.org>


The Google's approach is keeping connection and expecting the client 
continues to speak http/1.1 as a fail-back protocol.
This is one approach but I don't think it is all the cases.

For example when a server only provides a service that binds to the 
specific protocol or tests some experimental protocols over TLS,
the server does not need to keep the connection and closes it in the 
case of no matching because there are no fail-back protocol.

It is natural for a server to send a no_application_protocol alert to 
notify its error to the client before closing as well as it does in 
handshake_failure.
According to RFC7301 it is defined SHALL so that the client which is 
implemented with the spec properly can recognize the alert correctly.

I look back my patch now and it was really old and needs some changes. 
If it would be accepted, I'd like to revise it.

On 2015/06/13 23:02, Rich Salz via RT wrote:
> So, the google approach is that if no protocol match is found, the server
> replies WITHOUT the alpn header. They don't like no_app_protocol, to put it
> mildly :)
>
> thoughts?
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



From matt at openssl.org  Mon Jun 15 08:35:20 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 15 Jun 2015 09:35:20 +0100
Subject: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat
 issues (vs latest git master)
In-Reply-To: <20150613154325.55122a6b@pc1>
References: <RT-Ticket-3908@openssl.org> <557BEC9C.9040204@bouncycastle.org>
 <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>
 <20150613154325.55122a6b@pc1>
Message-ID: <557E8E48.5040504@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 13/06/15 14:43, Hanno B?ck wrote:
> Serious question: Is there any valid use case for heartbeats in TLS
> or DTLS? (With valid use case I mean something like "I use it for
> this system", not answers like "you could use it for xy")

I had always understood the argument in favour of heartbeat for DTLS
to be:
1) PMTU discovery
2) Keep-alive functionality

I've never heard a good argument for TLS (PMTU is irrelevant for TLS,
and TCP provides keep-alive).

Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVfo5IAAoJENnE0m0OYESRqHEIAJnLGo1qzx+k+qtodZpzQ8M9
fhmsTsZJy6zbVK0lIEcK4Rn/0BEMM0i/0GTYiqHpIduIjR5utNDSfyl3ViYsPP0W
e3zjzWAy4L2CjdNLcwbOMAjvTAIxKUJIYtkisT3BN0Pv8zMN19Imqso8CnaWtgG7
0n5QHE9Wx4wSgUI8Wt29q7LoPxnFNf7NOOi++fO8RjE4K+evP2OE7i4oAFk/nlZs
m5J+XJ2CVYHkg7uQ4btHLINVt9PBU7GpK58fOQ+3A8VXcXMYLKEwNoB3r7hsB2Uj
zvNECHXQFn9sVaj7u2PLNZITn3O1diw88oTe6O9PrSVQKh6+1QCZwU1cW7C9AWg=
=zepT
-----END PGP SIGNATURE-----

From stormseeker1 at gmail.com  Mon Jun 15 10:04:40 2015
From: stormseeker1 at gmail.com (Storm Seeker)
Date: Mon, 15 Jun 2015 12:04:40 +0200
Subject: [openssl-dev] HELP NEEDED FOR CROSS-COMPILING OPENSSL (LIBSSL AND
 LIBCRYPTO) ON UBUNTU FOR MIPS (SYSTEM ON CHIP BROADCOM BCM6358 [ROUTER
 NETGEAR DGN2200V1])
Message-ID: <CAKOhHw755J=PWO=bFqDe2pXUV4kgvjyOhWaZUW0h-gPe2aCNRA@mail.gmail.com>

Good morning everybody and nice to meet you

I've been struggling to get this done for entire weeks and long nights, but
I weren't able to.
I need to CROSS-COMPILE OPENSSL (LIBSSL AND LIBCRYPTO) ON UBUNTU FOR MIPS
(SYSTEM ON CHIP BROADCOM BCM6358 [ROUTER NETGEAR DGN2200V1]).
I'm able to compile other programs using the following guide:
https://folini.wordpress.com/2011/10/08/compilare-una-libreria-per-modfs/
You can find info and the toolchain download link on that page (
http://www.hwupgrade.it/forum/showpost.php?p=34212438&postcount=152).
For other programs, after setting the environment variables according to
this guide, it is enough to run:

./configure --host=mips-linux
make

I really need your help, because it doesn't wotk with OPENSSL.
I tried to investigate this in a large number of different ways digging in
the Configure, config, Makefile and so on, but with no luck

Thank you very much in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150615/007fc2a5/attachment-0001.html>

From Michael.Tuexen at lurchi.franken.de  Mon Jun 15 10:42:16 2015
From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen)
Date: Mon, 15 Jun 2015 12:42:16 +0200
Subject: [openssl-dev] [openssl.org #3908] Patch fixing some heartbeat
	issues (vs latest git master)
In-Reply-To: <557E8E48.5040504@openssl.org>
References: <RT-Ticket-3908@openssl.org> <557BEC9C.9040204@bouncycastle.org>
 <rt-4.0.19-10987-1434201206-106.3908-21-0@openssl.org>
 <20150613154325.55122a6b@pc1> <557E8E48.5040504@openssl.org>
Message-ID: <452B34AD-D98D-4010-AEF1-68A8D8ED1ADF@lurchi.franken.de>

> On 15 Jun 2015, at 10:35, Matt Caswell <matt at openssl.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> On 13/06/15 14:43, Hanno B?ck wrote:
>> Serious question: Is there any valid use case for heartbeats in TLS
>> or DTLS? (With valid use case I mean something like "I use it for
>> this system", not answers like "you could use it for xy")
> 
> I had always understood the argument in favour of heartbeat for DTLS
> to be:
> 1) PMTU discovery
> 2) Keep-alive functionality
> 
> I've never heard a good argument for TLS (PMTU is irrelevant for TLS,
> and TCP provides keep-alive).
TCP provides keep-alives, but at a timescale which is not acceptable
for all applications. The default to start sending them is an idle
time of 2 hours. So applications will need to send their own in
some cases, but they can be application messages.

Best regards
Michael
> 
> Matt
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVfo5IAAoJENnE0m0OYESRqHEIAJnLGo1qzx+k+qtodZpzQ8M9
> fhmsTsZJy6zbVK0lIEcK4Rn/0BEMM0i/0GTYiqHpIduIjR5utNDSfyl3ViYsPP0W
> e3zjzWAy4L2CjdNLcwbOMAjvTAIxKUJIYtkisT3BN0Pv8zMN19Imqso8CnaWtgG7
> 0n5QHE9Wx4wSgUI8Wt29q7LoPxnFNf7NOOi++fO8RjE4K+evP2OE7i4oAFk/nlZs
> m5J+XJ2CVYHkg7uQ4btHLINVt9PBU7GpK58fOQ+3A8VXcXMYLKEwNoB3r7hsB2Uj
> zvNECHXQFn9sVaj7u2PLNZITn3O1diw88oTe6O9PrSVQKh6+1QCZwU1cW7C9AWg=
> =zepT
> -----END PGP SIGNATURE-----
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 


From cuoq at trust-in-soft.com  Mon Jun 15 12:14:47 2015
From: cuoq at trust-in-soft.com (Pascal Cuoq)
Date: Mon, 15 Jun 2015 12:14:47 +0000
Subject: [openssl-dev] available tests drivers for OpenSSL
Message-ID: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>

Hello,

I am working on a C interpreter that uses existing tests to find more issues than simple execution does. In that it is comparable to Valgrind or UBSan. It has different enough strengths and weaknesses compared to these existing tools to make it worth using in addition to them, too.

This C interpreter is already able to work its way through a majority of the tests in OpenSSL's test directory, and indeed to find issues that occur during the execution of these tests (RT #3891). I was wondering whether anyone had, as a readily available artefact of fuzzing or quality assurance campaigns, some additional test drivers beyond but in the same style as those inside the archive.

Tests for derived libraries such as LibreSSL or BoringSSL would also be interesting.

Making the interpreter available in its current state to a motivated third party is also a possibility.

Pascal


From rt at openssl.org  Mon Jun 15 13:17:17 2015
From: rt at openssl.org (bug-reporting0000@cneufeld.ca via RT)
Date: Mon, 15 Jun 2015 13:17:17 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <201506151317.t5FDH0pe006170@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
 <rt-4.0.19-12424-1434142231-1971.3905-3-0@openssl.org>
 <201506150230.t5F2UhmE013812@cneufeld.ca>
 <rt-4.0.19-5892-1434335465-930.3905-6-0@openssl.org>
 <rt-4.0.19-5892-1434338952-479.3905-6-0@openssl.org>
 <201506151317.t5FDH0pe006170@cneufeld.ca>
Message-ID: <rt-4.0.19-5112-1434374237-1516.3905-6-0@openssl.org>

On Mon, 15 Jun 2015 03:29:12 +0000, Rich Salz via RT <rt at openssl.org> said:

> It's strange that CRYPTO_malloc ends up calling ISC-malloc, but CRYPTO_free
> does not. This is strange, but really hard to see how this is an openssl issue.

OK, I've been poking at this a bit more.  The ISC bind's host program is
calling CRYPTO_set_mem_functions, and registering its malloc/free
analogues.  That's going fine.  They are used when gost_set_default_param()
is called during setup.  malloc_func, free_func, and so on in crypto/mem.c
are set, and everything looks good.  CRYPTO_set_mem_functions itself lies
in the mmap-ed range of /usr/lib/libcrypto.so, as expected.

Then, the program runs, and it goes to shut down.  I'll note that it seems
to signal itself for shutdown by sending itself a catchable signal
(SIGTERM), but execution continues.  Eventually, it gets to
gost_param_free(), and if you inspect malloc_func and free_func here,
they're still correct, set to the ISC analogues.  But, when you descend
into CRYPTO_free, suddenly they're set to glibc malloc/free again.  This
confused me for a while because hardware watchpoints didn't spot the
switch.  But it turns out, they're not in the same mapped region.  The
malloc_func and free_func seen now are in the /usr/lib/engines/libgost.so
mapping, not the /usr/lib/libcrypto.so mapping.  Turns out libgost has its
own copy of those symbols, at different addresses, and those ones haven't
been modified by CRYPTO_set_mem_functions.  Inspection with "nm" shows
this.  In fact, the CRYPTO_free() that we're calling at this point isn't
the one mapped into libcrypto, but is libgost's own separate copy, and it's
using the unmodified memory hooks, since it never saw
CRYPTO_set_mem_functions.

It appears to me that mem.c is linked into the binary through two different
routes, and both are being used at various times in the execution of the
program.  The 'host' program does not spawn threads, everything is
happening in the same stack.

I'll note that libgost.so is dynamically linked against libcrypto.so, but
that's not where the second incarnation appears, 'nm' shows the symbols to
be linked into the libgost.so library directly (the malloc_func and
malloc_free symbols appear with 'd', the CRYPTO_free appears with 'T', so
they're all present as compiled symbols in libgost.so).


So, this may be a build issue, though I haven't done anything particularly
unusual in my configuration:
./config zlib shared threads no-hw no-krb5 --prefix=/usr

The link line in make when building libgost.so doesn't include mem.o in the
objects list, but I'll do some more checking later.


-- 
 Christopher Neufeld
 Home page:  http://www.cneufeld.ca/neufeld
 "Don't edit reality for the sake of simplicity"



From hkario at redhat.com  Mon Jun 15 13:20:05 2015
From: hkario at redhat.com (Hubert Kario)
Date: Mon, 15 Jun 2015 15:20:05 +0200
Subject: [openssl-dev] available tests drivers for OpenSSL
In-Reply-To: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>
References: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>
Message-ID: <2068514.Day4mDq4AO@pintsize.usersys.redhat.com>

On Monday 15 June 2015 12:14:47 Pascal Cuoq wrote:
> Hello,
> 
> I am working on a C interpreter that uses existing tests to find more issues
> than simple execution does. In that it is comparable to Valgrind or UBSan.
> It has different enough strengths and weaknesses compared to these existing
> tools to make it worth using in addition to them, too.
> 
> This C interpreter is already able to work its way through a majority of the
> tests in OpenSSL's test directory, and indeed to find issues that occur
> during the execution of these tests (RT #3891). I was wondering whether
> anyone had, as a readily available artefact of fuzzing or quality assurance
> campaigns, some additional test drivers beyond but in the same style as
> those inside the archive.
> 
> Tests for derived libraries such as LibreSSL or BoringSSL would also be
> interesting.

not yet ready, but I'm working on a generic test suite for TLS:
https://github.com/tomato42/tlsfuzzer/

the basic idea behind it is to have a non RFC compliant server or client and 
seeing if the peer responds correctly to malformed messages (In other words, 
it can very easily test openssl s_server process). I don't know if that 
matches the expected environment of your tool.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150615/c7bbe140/attachment.sig>

From kurt at roeckx.be  Mon Jun 15 13:42:57 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 15 Jun 2015 15:42:57 +0200
Subject: [openssl-dev] available tests drivers for OpenSSL
In-Reply-To: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>
References: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>
Message-ID: <20150615134257.GA17629@roeckx.be>

On Mon, Jun 15, 2015 at 12:14:47PM +0000, Pascal Cuoq wrote:
> Hello,
> 
> I am working on a C interpreter that uses existing tests to find more issues than simple execution does. In that it is comparable to Valgrind or UBSan. It has different enough strengths and weaknesses compared to these existing tools to make it worth using in addition to them, too.
> 
> This C interpreter is already able to work its way through a majority of the tests in OpenSSL's test directory, and indeed to find issues that occur during the execution of these tests (RT #3891). I was wondering whether anyone had, as a readily available artefact of fuzzing or quality assurance campaigns, some additional test drivers beyond but in the same style as those inside the archive.

There have been people doing fuzzing, and I would like to collect
them all and put them into a seperate repository.


Kurt


From rt at openssl.org  Mon Jun 15 14:09:43 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 15 Jun 2015 14:09:43 +0000
Subject: [openssl-dev] [openssl.org #3588] obsolete comment for
	SSL_set_accept_state and SSL_set_connect_state
In-Reply-To: <54532B7C.1040605@artisanlogiciel.net>
References: <RT-Ticket-3588@openssl.org> <54532B7C.1040605@artisanlogiciel.net>
Message-ID: <rt-4.0.19-5112-1434377383-106.3588-6-0@openssl.org>

commit d31fb0b5b341aa7883b487d07e6a56d216224e25
Author: Rich Salz <rsalz at akamai.com>
Date: Sat Jun 13 10:50:00 2015 -0400

Refactor into clear_ciphers; RT3588

While closing RT3588 (Remove obsolete comment) Kurt and I saw that a
few lines to completely clear the SSL cipher state could be moved into
a common function.

Reviewed-by: Kurt Roeckx <kurt at openssl.org>
---


--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Mon Jun 15 14:22:34 2015
From: rt at openssl.org (Arkadiusz Miskiewicz via RT)
Date: Mon, 15 Jun 2015 14:22:34 +0000
Subject: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of regression -
	fails to connect to server where 1.0.2a works fine
In-Reply-To: <201506151308.08131.arekm@maven.pl>
References: <RT-Ticket-3911@openssl.org> <201506151308.08131.arekm@maven.pl>
Message-ID: <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>


Hello.

I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from
mysql client to my mysql server. Downgrading to 1.0.2a and the problem is gone.

1.0.2c:

$ mysql -u user -p -h host
Enter password:
ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)

1.0.2a:

$ mysql -u user -p -h host
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 233
Server version: 5.6.20-68.0-log PLD/Linux Distribution MySQL RPM

Copyright (c) 2009-2015 Percona LLC and/or its affiliates
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

13:00:05 mysql{1}> \s
--------------
mysql  Ver 14.14 Distrib 5.6.24-72.2, for Linux (x86_64) using  6.3

Connection id:          233
Current database:
Current user:           user at some.ip.address
SSL:                    Cipher in use is DHE-RSA-AES256-SHA
[...]


Server side is using 1.0.2a.

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From tmraz at redhat.com  Mon Jun 15 14:45:29 2015
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 15 Jun 2015 16:45:29 +0200
Subject: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of
 regression - fails to connect to server where 1.0.2a works fine
In-Reply-To: <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>
References: <RT-Ticket-3911@openssl.org> <201506151308.08131.arekm@maven.pl>
 <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>
Message-ID: <1434379529.17179.11.camel@redhat.com>

On Po, 2015-06-15 at 14:22 +0000, Arkadiusz Miskiewicz via RT wrote:
> Hello.
> 
> I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from
> mysql client to my mysql server. Downgrading to 1.0.2a and the problem is gone.
> 

That's because mysql server hardcodes 512 bits DH parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)



From rt at openssl.org  Mon Jun 15 14:45:44 2015
From: rt at openssl.org (Tomas Mraz via RT)
Date: Mon, 15 Jun 2015 14:45:44 +0000
Subject: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of
	regression - fails to connect to server where 1.0.2a works fine
In-Reply-To: <1434379529.17179.11.camel@redhat.com>
References: <RT-Ticket-3911@openssl.org> <201506151308.08131.arekm@maven.pl>
 <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>
 <1434379529.17179.11.camel@redhat.com>
Message-ID: <rt-4.0.19-5892-1434379544-481.3911-6-0@openssl.org>

On Po, 2015-06-15 at 14:22 +0000, Arkadiusz Miskiewicz via RT wrote:
> Hello.
> 
> I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from
> mysql client to my mysql server. Downgrading to 1.0.2a and the problem is gone.
> 

That's because mysql server hardcodes 512 bits DH parameters. That's
insecure and connect is prevented by the LOGJAM fix. You can configure
the server to not use DH ciphersuites as a workaround, or patch the
mysql server to use at least 1024 bits DH parameters.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)




From todd.farmer at oracle.com  Mon Jun 15 14:44:15 2015
From: todd.farmer at oracle.com (Todd Farmer)
Date: Mon, 15 Jun 2015 08:44:15 -0600
Subject: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of
 regression - fails to connect to server where 1.0.2a works fine
In-Reply-To: <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>
References: <RT-Ticket-3911@openssl.org> <201506151308.08131.arekm@maven.pl>
 <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>
Message-ID: <557EE4BF.7000300@oracle.com>

Hello Arkadiusz,

On 6/15/2015 8:22 AM, Arkadiusz Miskiewicz via RT wrote:
> I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from
> mysql client to my mysql server. Downgrading to 1.0.2a and the problem is gone.
> 
> 1.0.2c:
> 
> $ mysql -u user -p -h host
> Enter password:
> ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)

You seem to be running into the following:

http://bugs.mysql.com/bug.php?id=77275

It's fixed in MySQL Server 5.7 (RC), and will be fixed in 5.6 (GA)
shortly.  You appear to be using Percona builds, so they may apply the
patch from 5.7 on a different schedule - best to inquire directly with them.

Best regards,

-- 
Todd Farmer
Director, Technical Product Management, MySQL
MySQL @ Oracle


From rt at openssl.org  Mon Jun 15 15:15:42 2015
From: rt at openssl.org (Todd Farmer via RT)
Date: Mon, 15 Jun 2015 15:15:42 +0000
Subject: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of
	regression - fails to connect to server where 1.0.2a works fine
In-Reply-To: <557EE4BF.7000300@oracle.com>
References: <RT-Ticket-3911@openssl.org> <201506151308.08131.arekm@maven.pl>
 <rt-4.0.19-5892-1434378154-1052.3911-21-0@openssl.org>
 <557EE4BF.7000300@oracle.com>
Message-ID: <rt-4.0.19-5112-1434381342-393.3911-6-0@openssl.org>

Hello Arkadiusz,

On 6/15/2015 8:22 AM, Arkadiusz Miskiewicz via RT wrote:
> I've just upgraded from 1.0.2a to 1.0.2c and now I no longer can connect from
> mysql client to my mysql server. Downgrading to 1.0.2a and the problem is gone.
> 
> 1.0.2c:
> 
> $ mysql -u user -p -h host
> Enter password:
> ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)

You seem to be running into the following:

http://bugs.mysql.com/bug.php?id=77275

It's fixed in MySQL Server 5.7 (RC), and will be fixed in 5.6 (GA)
shortly.  You appear to be using Percona builds, so they may apply the
patch from 5.7 on a different schedule - best to inquire directly with them.

Best regards,

-- 
Todd Farmer
Director, Technical Product Management, MySQL
MySQL @ Oracle



From Stefan.Neis at t-online.de  Mon Jun 15 15:22:58 2015
From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de)
Date: Mon, 15 Jun 2015 17:22:58 +0200
Subject: [openssl-dev]
 =?utf-8?q?Help_needed_for_cross-compiling_openssl?=
In-Reply-To: <CAKOhHw755J=PWO=bFqDe2pXUV4kgvjyOhWaZUW0h-gPe2aCNRA@mail.gmail.com>
References: <CAKOhHw755J=PWO=bFqDe2pXUV4kgvjyOhWaZUW0h-gPe2aCNRA@mail.gmail.com>
Message-ID: <1953093623557eedd22a9514.64935657@email.t-online.de>

Hi, 

	> For other programs, after setting the environment variables
according to this guide, it is enough to run: 

	>        > > ./configure --host=mips-linux > make
> > I really need your help, because it doesn't wotk with OPENSSL.    

	That's because OpenSSL is not using autoconf but a Configure script
that's created by hand 

	(and supports even more platforms...), so linux' "standard" mechanism
just doesn't work. 

	    > I tried to investigate this in a large number of different ways
digging in the Configure, config, Makefile and so on, but with no luck
>  > Thank you very much in advance!   

	OpenSSL does things slightly different, but once you get used to it,
it's pretty cool. 

	For a starting point, you could try 

	"./Configure linux-generic32 --cross-compile-prefix=mips-linux" 

	 after setting the environment variables. This assumes:

	1. Your target platform is sufficiently similar to linux. You can
look into the Configure script to 

	    see many more platforms and  you could try if e.g. any of the
irix-mips<something>-gcc 

	    platform definitions are working for you (giving you the bonus of
MIPS assembler code). 

	   Also, if you want to dig into the details of the platform
definitions, you might want to add 

	   another one for you case. 

	2. The crosscompiler is named somthing like mips-linux-gcc, which
AFAIR is implied by the 

	    host parameter in your sample above. Anway, what you specify as
"--cross-compile-prefix" 

	    is the prefix, that gets prepended to all those calls to
compilation tools like gcc, ar, ld. 

	        HTH, 

	              Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150615/38c6803a/attachment.html>

From andrejs.igumenovs at gmail.com  Mon Jun 15 15:50:32 2015
From: andrejs.igumenovs at gmail.com (Andrejs Igumenovs)
Date: Mon, 15 Jun 2015 18:50:32 +0300
Subject: [openssl-dev] available tests drivers for OpenSSL
In-Reply-To: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>
References: <D2D1E375-0D9D-4587-869F-0F630B4ECDCD@trust-in-soft.com>
Message-ID: <FC516801-CBB5-4C0F-8B8B-06F6D7C69613@gmail.com>

Hi Pascal,

There is also this one:
http://drmemory.org/

- Andrejs

> On 15.06.2015, at 15:14, Pascal Cuoq <cuoq at trust-in-soft.com> wrote:
> 
> Hello,
> 
> I am working on a C interpreter that uses existing tests to find more issues than simple execution does. In that it is comparable to Valgrind or UBSan. It has different enough strengths and weaknesses compared to these existing tools to make it worth using in addition to them, too.
> 
> This C interpreter is already able to work its way through a majority of the tests in OpenSSL's test directory, and indeed to find issues that occur during the execution of these tests (RT #3891). I was wondering whether anyone had, as a readily available artefact of fuzzing or quality assurance campaigns, some additional test drivers beyond but in the same style as those inside the archive.
> 
> Tests for derived libraries such as LibreSSL or BoringSSL would also be interesting.
> 
> Making the interpreter available in its current state to a motivated third party is also a possibility.
> 
> Pascal
> 
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From jifl at eCosCentric.com  Mon Jun 15 15:48:32 2015
From: jifl at eCosCentric.com (Jonathan Larmour)
Date: Mon, 15 Jun 2015 16:48:32 +0100
Subject: [openssl-dev] ARM optimised montgomery multiplication (armv4-mont)
Message-ID: <557EF3D0.8000108@eCosCentric.com>

Hi,

After the changes to DH requiring longer key lengths, I switched to 2048-bit
keys, but was finding this was now making my test runs on an embedded ARM9
target annoyingly slow; so thought I'd investigate to see if there was
anything to improve.

With some experimentation, it turns out that if I *stop* using the
crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
a simplish test to establish and close a simple SSL connection went from 28
seconds to 18. (It's quite a slow target at any time).

In other words, this "optimised" version has slowed things down dramatically.
Has anyone queried the value of the asm of armv4-mont.pl any time in the last
few years? Is it just that compilers have become better (I'm only using gcc
4.7.3, so not bleeding edge even).

Anyway, it's uncertain to me whether armv4-mont.pl should remain. Does anyone
care to try it on other ARM cores?

FYI, I couldn't discern any difference whether using armv4-gf2m or not, but
that doesn't mean it's bad.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

From nico at cryptonector.com  Mon Jun 15 16:02:36 2015
From: nico at cryptonector.com (Nico Williams)
Date: Mon, 15 Jun 2015 11:02:36 -0500
Subject: [openssl-dev] Self-initialization of locking/threadid callbacks
 and auto-detection of features
In-Reply-To: <557949D6.9010506@redhat.com>
References: <CAK3OfOhgUAQirHZbb=KXbykjAigLXmmva1DK4-5Stau_eTd+bg@mail.gmail.com>
 <20131028020710.GA15554@gmail.com> <52702171.1060604@openssl.org>
 <20131029231514.GA23539@gmail.com> <557949D6.9010506@redhat.com>
Message-ID: <20150615160234.GA3955@localhost>

On Thu, Jun 11, 2015 at 10:41:58AM +0200, Florian Weimer wrote:
> Detecting things in libcrypto is very difficult on GNU/Linux due to the
> way dynamic linking works.

Details?

> On GNU/Linux, you should try very hard to avoid linking -lpthread and
> restrict yourself to the pthreads API subset which is available without
> -lpthread.  If something is missing, we (as in glibc upstream) can move
> additional functionality from libpthread to libc.

[My apologies for making this so long.  There's a lot to say about this.]

Perhaps OpenSSL should have several configuration flavors for Linux
then.  If you want to statically link a non-threaded program with
OpenSSL, then you should use the libpthread static link meant for it.

Or perhaps we could have the OpenSSL static link archives assume
non-threaded processes (callers must initialize lock callbacks) but the
shared objects link with -lpthread and assume a threaded environment.
(This means supporting two "process models" instead of *four*.)

In any case, use of OpenSSL by *libraries* (which is rather common, I
gather; certainly in the case of Kerberos implementations) is currently
a disaster waiting to happen, and sometimes a disaster that strikes.

A workaound for libraries may be to use a private copy (as if by static
linking) of OpenSSL with distinct SONAME/symbols and initialize that
copy properly.  This is generally safe (we've tried it) but also a bit
troublesome.  On the plus side this means that ABI incompatibilities
betwee OpenSSL releases become a non-issue.

Or indeed, libpthread should move into libc (which I gather would take a
long time and is beyond what we can do here).

For background, Solaris moved libpthread into libc around 2004, during
S10 development.  Solaris 10 also dropped support for static linking of
libc and dropped all static linking archives from OS/Net (but not ld(1)
support for static linking).  Before that S9 had basically four process
models: statically-linked,-not-threaded, statically-linked,-threaded,
dynamically-linked,-not-threaded, dynamically-linked,-threaded.  This
was awful in a great many ways (think of statically-linked, single-
threaded programs that dlopen()ed dynamically-linked threaded objects
via, e.g., the name service switch).  Dropping support for statically
linking with libc greatly simplified a lot of things.  Linux ought to do
the same, but there's a fascination with static linking in Linux land...

...Static linking wouldn't be so bad if it had dependency tracking and
symbol resolution semantics closer to dynamic linking.  The startup
times for one process would be awesome, though startup times for entire
systems would be awful.  (Solaris 10 boot times improved significantly
when static linking was dropped.)  And then there's the need for PIE to
still get any benefit from ASLR, which then applies to the whole
program, not each library.  (Can gdb debug PIE nowadays?  Last I checked
it could not.)

(Moving the implementation of a library to another requires support for
shared object "filters", at least on Solaris, so that dynamically-linked
dependents of libpthread and such will find the symbols they need there,
though the RTLD knows to go look in the object they moved to.  We say
that libpthread is a filter of libc because only the pthread-related
symbols of libc appear in libpthread.  IIUC the Linux RTLD does not
support filters.)

(I help maintain an open source project that distributes a statically-
linked executable as that's a great way to avoid needing packaging and
installers.  So perhaps I shouldn't speak so ill of static linking.  But
then, static linking truly is awful.)

> Linking -lpthread has a real performance hit for unthreaded
> applications, so core libraries should avoid it.

It shouldn't.  Having *four* process models is an enormous burden on
developers, especially libc and libpthread developers, but this burden
leaks into other system libraries, such as OpenSSL's.  Solaris saw a
sizeable net performance win in switching to a single process model
(dynamically-linked, threaded) (for many processes there's just one
thread, natch).

> If you have received advice to the contrary, your source of advice is
> wrong. :-)

Or maybe I'm rather spoiled by Solaris and am continually suprised to
see that developers on Linux must struggle with problems that Solaris
tackled a decade ago.

In any case, the initialization problems when OpenSSL is used by
*libraries* are simply unacceptable.  Either that means that OpenSSL
cannot and must not be used by libraries, or we must find a solution
that doesn't suck.  See above and let me know which paths, if any, are
the way forward; I offered several, and there may be more that I have
not seen.

Nico
-- 

From nico at cryptonector.com  Mon Jun 15 17:20:24 2015
From: nico at cryptonector.com (Nico Williams)
Date: Mon, 15 Jun 2015 12:20:24 -0500
Subject: [openssl-dev] Self-initialization of locking/threadid callbacks
 and auto-detection of features
In-Reply-To: <20150615160234.GA3955@localhost>
References: <CAK3OfOhgUAQirHZbb=KXbykjAigLXmmva1DK4-5Stau_eTd+bg@mail.gmail.com>
 <20131028020710.GA15554@gmail.com> <52702171.1060604@openssl.org>
 <20131029231514.GA23539@gmail.com> <557949D6.9010506@redhat.com>
 <20150615160234.GA3955@localhost>
Message-ID: <20150615172023.GD3955@localhost>


Hmm, another option is to use weak symbols to detect presence of
pthreads.  This should work regardless of whether static or dynamic
linking is used.

A statically-linked, single-threaded program that dlopen()s an object
that brings in libpthread will have different OpenSSL dependencies for
the dynamically-loaded objects than for the initial statically-linked
program.  So everything should work out.

Nico
-- 

From rt at openssl.org  Mon Jun 15 17:24:39 2015
From: rt at openssl.org (bug-reporting0000@cneufeld.ca via RT)
Date: Mon, 15 Jun 2015 17:24:39 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <201506151724.t5FHOPQ3023004@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
 <rt-4.0.19-12424-1434142231-1971.3905-3-0@openssl.org>
 <201506150230.t5F2UhmE013812@cneufeld.ca>
 <rt-4.0.19-5892-1434335465-930.3905-6-0@openssl.org>
 <rt-4.0.19-5892-1434338952-479.3905-6-0@openssl.org>
 <201506151724.t5FHOPQ3023004@cneufeld.ca>
Message-ID: <rt-4.0.19-5112-1434389079-1893.3905-6-0@openssl.org>

OK, it's a build system issue.  The erroneously linked symbols do not
appear in libgost.so unless make is invoked with the "-j <NUM>" switch.
I'll see later if I can make a patch to fix the parallel build behaviour.


-- 
 Christopher Neufeld
 Home page:  http://www.cneufeld.ca/neufeld
 "Don't edit reality for the sake of simplicity"



From rsalz at akamai.com  Mon Jun 15 18:19:49 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 15 Jun 2015 18:19:49 +0000
Subject: [openssl-dev] Self-initialization of locking/threadid callbacks
 and auto-detection of features
In-Reply-To: <20150615160234.GA3955@localhost>
References: <CAK3OfOhgUAQirHZbb=KXbykjAigLXmmva1DK4-5Stau_eTd+bg@mail.gmail.com>
 <20131028020710.GA15554@gmail.com> <52702171.1060604@openssl.org>
 <20131029231514.GA23539@gmail.com> <557949D6.9010506@redhat.com>
 <20150615160234.GA3955@localhost>
Message-ID: <584cc008a194490c9644865a1e53be59@ustx2ex-dag1mb2.msg.corp.akamai.com>

My overall goal is that I want to remove the thread callback stuff.  Ideally we have two options: no threads and system-threads.

It seems that on Linux shared/static libraries might be an issue.  I hope we can resolve and simplify that.


From nico at cryptonector.com  Mon Jun 15 18:53:43 2015
From: nico at cryptonector.com (Nico Williams)
Date: Mon, 15 Jun 2015 13:53:43 -0500
Subject: [openssl-dev] Self-initialization of locking/threadid callbacks
 and auto-detection of features
In-Reply-To: <584cc008a194490c9644865a1e53be59@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CAK3OfOhgUAQirHZbb=KXbykjAigLXmmva1DK4-5Stau_eTd+bg@mail.gmail.com>
 <20131028020710.GA15554@gmail.com> <52702171.1060604@openssl.org>
 <20131029231514.GA23539@gmail.com> <557949D6.9010506@redhat.com>
 <20150615160234.GA3955@localhost>
 <584cc008a194490c9644865a1e53be59@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150615185342.GE3955@localhost>

On Mon, Jun 15, 2015 at 06:19:49PM +0000, Salz, Rich wrote:
> My overall goal is that I want to remove the thread callback stuff.

Excellent.

> Ideally we have two options: no threads and system-threads.

Presumably that would be either a configure-time option or a run-time
automatic option, but not an option given to the caller via an API.

> It seems that on Linux shared/static libraries might be an issue.  I
> hope we can resolve and simplify that.

With weak symbols this problem can go away, but when linking statically
it does make the order of dependencies matter in the final link edit.
It'd have to be -lpthread -lcrypto -lssl; -lpthread could not come after
OpenSSL; the strong symbol definition has to come first.

Nico
-- 

From valerie.fenwick at oracle.com  Mon Jun 15 18:43:42 2015
From: valerie.fenwick at oracle.com (Valerie Fenwick)
Date: Mon, 15 Jun 2015 11:43:42 -0700
Subject: [openssl-dev] Regression testing?
In-Reply-To: <b055099a44b64ea9886f71ea478c95ca@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <557B1C92.8040204@oracle.com>
 <b055099a44b64ea9886f71ea478c95ca@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <557F1CDE.80604@oracle.com>



On 6/13/2015 7:11 AM, Salz, Rich wrote:
>
>> I was wondering if there is a document anywhere describing what type of
>> testing you do before releasing a new version of OpenSSL?
>
> Matt already gave some answers.  Our biggest regression test is "make test" at the top-level.  We've recently gotten much better at adding more tests...
>
> Any help gratefully received :)
>

Thanks, very helpful!  Is there a "minimum" number of systems/OSes this
is run on before a release goes out?


Or is it always just "best effort" based on which engineers are available?

We do internal testing of the bits before we integrate to Solaris (we
have to test not only OpenSSL itself, but a few of the big things that
depend on it).  Not sure how interesting those test results would be
to anyone not using Solaris :-)

Valerie
-- 
NOTE: Using voice recognition software, forgive typos/grammar mistakes!
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

From rsalz at akamai.com  Mon Jun 15 22:20:09 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 15 Jun 2015 22:20:09 +0000
Subject: [openssl-dev] Regression testing?
In-Reply-To: <557F1CDE.80604@oracle.com>
References: <557B1C92.8040204@oracle.com>
 <b055099a44b64ea9886f71ea478c95ca@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <557F1CDE.80604@oracle.com>
Message-ID: <9be5192380524a8aa30ce9e805cbe168@ustx2ex-dag1mb2.msg.corp.akamai.com>

> Thanks, very helpful!  Is there a "minimum" number of systems/OSes this is
> run on before a release goes out?

Some linux distro.  If there are vms- or windows-specific changes in the release that the team things are of concern, we try to test those as well.

> Or is it always just "best effort" based on which engineers are available?

Yes, basically.

> We do internal testing of the bits before we integrate to Solaris (we have to test not only OpenSSL itself, but a few of the big things that depend on it).  Not sure how interesting those test results would be to anyone not using Solaris :-)

Lots of folks use Solaris.  If you have a Jenkins or similar build farm that could send out reports of things like nightly build failures, we might be interested in seeing how the team could leverage that ...

From rt at openssl.org  Mon Jun 15 22:27:55 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 15 Jun 2015 22:27:55 +0000
Subject: [openssl-dev] [openssl.org #2547] [Bug report / Linux / openssl
	0.9.8k-7ubuntu8.6] openssl genrsa creates world readable
	private key files
In-Reply-To: <4E06309D.7040000@knaff.lu>
References: <RT-Ticket-2547@openssl.org> <4E06309D.7040000@knaff.lu>
Message-ID: <rt-4.0.19-5892-1434407275-1561.2547-6-0@openssl.org>

This is a big change, so we're only doing it in master. Fixed.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From atulthosar at gmail.com  Tue Jun 16 07:21:31 2015
From: atulthosar at gmail.com (Atul Thosar)
Date: Tue, 16 Jun 2015 12:51:31 +0530
Subject: [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris 10)
Message-ID: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>

?Hi All,

>From archives/google, I understood that the OpenSSL works/supported on
Solaris 11 platform, but in our case, it's a bit different scenario.

Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc)
and it works well on Solaris 10 platform. We use Sun Studio 12 compiler.

We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o
changing the build platform. I mean we will continue to build OpenSSL on
Solaris 10 and run it on Solaris 11.

Has anyone encounter such situation?  Appreciate any help/pointers if this
mechanism will work?

--

BR,

Atul Thosar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150616/5adee1c9/attachment.html>

From appro at openssl.org  Tue Jun 16 12:09:40 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 16 Jun 2015 14:09:40 +0200
Subject: [openssl-dev] ARM optimised montgomery multiplication
	(armv4-mont)
In-Reply-To: <557EF3D0.8000108@eCosCentric.com>
References: <557EF3D0.8000108@eCosCentric.com>
Message-ID: <55801204.2070108@openssl.org>

Hi,

> After the changes to DH requiring longer key lengths, I switched to 2048-bit
> keys, but was finding this was now making my test runs on an embedded ARM9
> target annoyingly slow; so thought I'd investigate to see if there was
> anything to improve.
> 
> With some experimentation, it turns out that if I *stop* using the
> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
> a simplish test to establish and close a simple SSL connection went from 28
> seconds to 18. (It's quite a slow target at any time).
> 
> In other words, this "optimised" version has slowed things down dramatically.
> Has anyone queried the value of the asm of armv4-mont.pl any time in the last
> few years?

Yes, of course. For reference, here are speed rsa2048 dsa2048 results
from Cortex-A8. Numbers are operations per second, so that higher is better.

Without armv4-mont.pl:

                  sign    verify    sign/s verify/s
rsa 2048 bits 0.052684s 0.001421s     19.0    703.5
dsa 2048 bits 0.014576s 0.017526s     68.6     57.1

With armv4-mont.pl but without NEON (ARM SIMD extension):

rsa 2048 bits 0.039255s 0.001140s     25.5    877.3
dsa 2048 bits 0.011630s 0.013900s     86.0     71.9

With armv4-mont.pl and NEON on:

rsa 2048 bits 0.021053s 0.000606s     47.5   1650.2
dsa 2048 bits 0.006084s 0.006985s    164.4    143.2

Well, RSA/DSA are not DH, but they are very representative when it comes
to sheer BIGNUM performance. And of course Cortex-A8 is not ARM9, but at
least it shows that statement about armv4-mont.pl being bad for
performance does not hold universally true. It's rather contrary, as
similar picture can be observed on most ARM processors (well, all I tested).

> Is it just that compilers have become better (I'm only using gcc
> 4.7.3, so not bleeding edge even).

I don't think so. BIGNUM performance can be delicate balance between
multiple factors and it's not impossible to end up on the other side of
breaking point. What breaking point? If you examine performance
improvement with and without Montgomery multiplication module, you'll
notice that there are processors on which improvement coefficient
declines with key length. I mean you'll observe lower improvement longer
key is. This indicates that there ought to be point past which you can
as well observe worse performance, not better. So far such points fell
outside practical key lengths on tested systems, ARM or not. Well,
except for s390x-mont module [which by the way even discusses reasons
for why such breaking point exists, see commentary in
bn/asm/s390x-mont.pl]. In other words I argue that your case is case of
finding yourself on the other side of said breaking point on specific
CPU, not case of armv4-mont.pl being universally inferior. It does come
a little bit unexpected in sense that I wouldn't expect it to hit the
point at 2048-bit key length on any specific ARM processor, but on the
other hard it's not impossible (all it takes is multiplication
instruction stalling pipe-line for long enough to tip the balance).

> Anyway, it's uncertain to me whether armv4-mont.pl should remain.

Assuming that majority of ARM users are not ARM9 users, most would have
to disagree :-) So what does it leave us? One can argue that OpenSSL
could detect the breaking point at run-time and act accordingly, but
it's tricky and is likely to have too narrow use. One can argue that
OpenSSL can be further optimized so that breaking point is moved further
(if not eliminated), which is more practical, because it should improve
performance on all processors, but this is not something that happens
over night. Meanwhile just documenting the case and providing
instructions on how to disengage the module is probably reasonable
compromise. Would you agree? One can make arrangements so that said
instructions would be super-simple...

> FYI, I couldn't discern any difference whether using armv4-gf2m or not, but
> that doesn't mean it's bad.

armv4-gf2m is involved in Elliptic Curve, and of specific kind. Your
problem description doesn't sound like it should affect you. But even if
it did, it's unlike that you'll notice regression, because there are no
breaking points in that case.


From appro at openssl.org  Tue Jun 16 12:21:20 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 16 Jun 2015 14:21:20 +0200
Subject: [openssl-dev] Help needed for cross-compiling openssl
In-Reply-To: <1953093623557eedd22a9514.64935657@email.t-online.de>
References: <CAKOhHw755J=PWO=bFqDe2pXUV4kgvjyOhWaZUW0h-gPe2aCNRA@mail.gmail.com>
 <1953093623557eedd22a9514.64935657@email.t-online.de>
Message-ID: <558014C0.8020801@openssl.org>

Hi,

>> For other programs, after setting the environment variables according
> to this guide, it is enough to run:
> 
>>
> 
>>
>> ./configure --host=mips-linux
>> make
>>
>> I really need your help, because it doesn't wotk with OPENSSL.
>  
> 
> That's because OpenSSL is not using autoconf but a Configure script
> that's created by hand
> 
> (and supports even more platforms...), so linux' "standard" mechanism
> just doesn't work.
> 
>  
> 
>> I tried to investigate this in a large number of different ways
> digging in the Configure, config, Makefile and so on, but with no luck
>>
>> Thank you very much in advance!
> 
>  
> 
> OpenSSL does things slightly different, but once you get used to it,
> it's pretty cool.
> 
> For a starting point, you could try
> 
> "./Configure linux-generic32 --cross-compile-prefix=mips-linux"
> 
> after setting the environment variables. This assumes:
> 
> 1. Your target platform is sufficiently similar to linux. You can look
> into the Configure script to
> 
>     see many more platforms and  you could try if e.g. any of the
> irix-mips<something>-gcc
> 
>     platform definitions are working for you (giving you the bonus of
> MIPS assembler code).
> 
>    Also, if you want to dig into the details of the platform
> definitions, you might want to add
> 
>    another one for you case.
> 
> 2. The crosscompiler is named somthing like mips-linux-gcc, which AFAIR
> is implied by the
> 
>     host parameter in your sample above. Anway, what you specify as
> "--cross-compile-prefix"
> 
>     is the prefix, that gets prepended to all those calls to compilation
> tools like gcc, ar, ld.

Absolutely right! Except that given context OP is more likely to have to
use --cross-compile-prefix=mips-linux-, i.e. with additional dash.
Stefan, if it appears as nitpicking, I apologize. It's just that
sometimes little detail can help to understand the general idea better.

Cheers.


From appro at openssl.org  Tue Jun 16 12:40:43 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 16 Jun 2015 14:40:43 +0200
Subject: [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris
 10)
In-Reply-To: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
References: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
Message-ID: <5580194B.1070100@openssl.org>

Hi,

> From archives/google, I understood that the OpenSSL works/supported on
> Solaris 11 platform, but in our case, it's a bit different scenario.
> 
> Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc)
> and it works well on Solaris 10 platform. We use Sun Studio 12 compiler.
> 
> We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform
> w/o changing the build platform. I mean we will continue to build
> OpenSSL on Solaris 10 and run it on Solaris 11.
> 
> Has anyone encounter such situation?  Appreciate any help/pointers if
> this mechanism will work?

It totally should work on Solaris. I personally would even encourage
such practice, i.e. compile on older platform. In *general* case there
are situation when it would be inappropriate (if possible at all), but
OpenSSL on Solaris is not such case. Well, one can still argue that
older compiler might fail to produce optimal code for both platforms, or
even that compiler has to be run on target platform, but for most
critical parts we do have assembly modules. Well, not so much in 0.9.8,
so that there is a contradiction in what I'm trying to say, but it's
about specifics, not general principle. And general principle is that
assembly modules found in later releases can be compiled on old systems
yet deliver optimal performance on new ones. This is thanks to run-time
switch, when CPU capabilities are detected at run-time and different
code paths are chosen for execution on different processors. [And to the
fact that extension instructions are hand-coded so that you don't need
latest assembler to compile.] Once again, this is for later OpenSSL
releases. As far as 0.9.8 goes, if performance of compiler-generated
code not being optimized for specific processor is not an issue, then
compiling on older system is totally viable approach.


From Stefan.Neis at t-online.de  Tue Jun 16 13:55:10 2015
From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de)
Date: Tue, 16 Jun 2015 15:55:10 +0200
Subject: [openssl-dev]
 =?utf-8?q?Help_needed_for_cross-compiling_openssl?=
In-Reply-To: <558014C0.8020801@openssl.org>
References: <558014C0.8020801@openssl.org>
Message-ID: <157954750055802abe328d43.80772010@email.t-online.de>

    Hi,

> Absolutely right! Except that given context OP is more likely to have to
> use --cross-compile-prefix=mips-linux-, i.e. with additional dash.

Yes, right, sorry about that..

> Stefan, if it appears as nitpicking, I apologize.

No need to apologize. On the contrary, if one doesn't know the details
yet - such as th OP - that missing dash can make things really frustrating.
So I'm really sorry about that error. I just got a bit confused myself by the
given autoconf host triplet in the original mail. 

      Regards,
             Stefan
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




From jifl at eCosCentric.com  Tue Jun 16 14:03:53 2015
From: jifl at eCosCentric.com (Jonathan Larmour)
Date: Tue, 16 Jun 2015 15:03:53 +0100
Subject: [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris
 10)
In-Reply-To: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
References: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
Message-ID: <55802CC9.9000209@eCosCentric.com>

On 16/06/15 08:21, Atul Thosar wrote:
> 
> Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc)
> and it works well on Solaris 10 platform. We use Sun Studio 12 compiler.
> 
> We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o
> changing the build platform.[snip]

One issue to consider is that it may not be wise to be putting OpenSSL
0.9.8 into a new system when security updates for it will stop in a matter
of months.

Jifl
-- 
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

From nico at cryptonector.com  Tue Jun 16 15:46:16 2015
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 16 Jun 2015 10:46:16 -0500
Subject: [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris
	10)
In-Reply-To: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
References: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
Message-ID: <20150616154615.GA6117@localhost>

On Tue, Jun 16, 2015 at 12:51:31PM +0530, Atul Thosar wrote:
> Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc)
> and it works well on Solaris 10 platform. We use Sun Studio 12 compiler.
> 
> We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o
> changing the build platform. I mean we will continue to build OpenSSL on
> Solaris 10 and run it on Solaris 11.
> 
> Has anyone encounter such situation?  Appreciate any help/pointers if this
> mechanism will work?

Historically the approach you describe has worked quite well with
Solaris because the ABI is quite stable.  This is particularly the case
if you use only features that are extremely unlikely to be removed in a
new minor release (Solaris 12 would be a minor release).

(You should not build on anything older than S10 to run on S10 or later,
mostly due to subtle changes in how snprintf() works.)

But you should read the ABI compatibility promises that Oracle makes and
decide for yourself.

Nico
-- 

From nico at cryptonector.com  Tue Jun 16 16:43:14 2015
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 16 Jun 2015 11:43:14 -0500
Subject: [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris
	10)
In-Reply-To: <20150616154615.GA6117@localhost>
References: <CAKT7Mpq_J2LqLWD19ZCRC+VRmrkZayg_xBk3M4VMd1Q8mHoGwg@mail.gmail.com>
 <20150616154615.GA6117@localhost>
Message-ID: <20150616164314.GB6117@localhost>

I should add that you should read all the release notes of every update
and check if your product would be affected.

From jifl at eCosCentric.com  Tue Jun 16 20:41:36 2015
From: jifl at eCosCentric.com (Jonathan Larmour)
Date: Tue, 16 Jun 2015 21:41:36 +0100
Subject: [openssl-dev] ARM optimised montgomery multiplication
	(armv4-mont)
In-Reply-To: <55801204.2070108@openssl.org>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
Message-ID: <55808A00.4090200@eCosCentric.com>

Hi,

Thanks for the reply.

On 16/06/15 13:09, Andy Polyakov wrote:
>>
>> With some experimentation, it turns out that if I *stop* using the
>> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
>> a simplish test to establish and close a simple SSL connection went from 28
>> seconds to 18. (It's quite a slow target at any time).
>>
>> In other words, this "optimised" version has slowed things down dramatically.
>> Has anyone queried the value of the asm of armv4-mont.pl any time in the last
>> few years?
> 
> Yes, of course. For reference, here are speed rsa2048 dsa2048 results
> from Cortex-A8. Numbers are operations per second, so that higher is better.
> 
> Without armv4-mont.pl:
> 
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.052684s 0.001421s     19.0    703.5
> dsa 2048 bits 0.014576s 0.017526s     68.6     57.1
> 
> With armv4-mont.pl but without NEON (ARM SIMD extension):
> 
> rsa 2048 bits 0.039255s 0.001140s     25.5    877.3
> dsa 2048 bits 0.011630s 0.013900s     86.0     71.9


Wow, I get very different results on my ARM9 target. Without armv4-mont.pl:
                  sign    verify    sign/s verify/s
rsa 2048 bits 2.567500s 0.072826s      0.4     13.7
dsa 2048 bits 0.722857s 0.865833s      1.4      1.2

With armv4-mont.pl:
                  sign    verify    sign/s verify/s
rsa 2048 bits 3.433333s 0.104896s      0.3      9.5
dsa 2048 bits 1.058000s 1.253750s      0.9      0.8

What's more, I dug out a Cortex-A9 target (Atmel CycloneV board, operating
with single core only) and got this without armv4-mont.pl:
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.127342s 0.003628s      7.9    275.6
dsa 2048 bits 0.035971s 0.042778s     27.8     23.4

and this with armv4-mont.pl:
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.172931s 0.005222s      5.8    191.5
dsa 2048 bits 0.052565s 0.061350s     19.0     16.3

As you can see, in both cases using armv4-mont.pl makes it 30% slower. So
whatever is going on, it isn't down to the CPU. I think there must be
something else going on. I'll get back to you.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

From appro at openssl.org  Tue Jun 16 21:12:27 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 16 Jun 2015 23:12:27 +0200
Subject: [openssl-dev] ARM optimised montgomery
	multiplication	(armv4-mont)
In-Reply-To: <55808A00.4090200@eCosCentric.com>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com>
Message-ID: <5580913B.40208@openssl.org>

>>> With some experimentation, it turns out that if I *stop* using the
>>> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
>>> a simplish test to establish and close a simple SSL connection went from 28
>>> seconds to 18. (It's quite a slow target at any time).
>>>
>>> In other words, this "optimised" version has slowed things down dramatically.
>>> Has anyone queried the value of the asm of armv4-mont.pl any time in the last
>>> few years?
>> Yes, of course. For reference, here are speed rsa2048 dsa2048 results
>> from Cortex-A8. Numbers are operations per second, so that higher is better.
>>
>> Without armv4-mont.pl:
>>
>>                   sign    verify    sign/s verify/s
>> rsa 2048 bits 0.052684s 0.001421s     19.0    703.5
>> dsa 2048 bits 0.014576s 0.017526s     68.6     57.1
>>
>> With armv4-mont.pl but without NEON (ARM SIMD extension):
>>
>> rsa 2048 bits 0.039255s 0.001140s     25.5    877.3
>> dsa 2048 bits 0.011630s 0.013900s     86.0     71.9
> 
> 
> Wow, I get very different results on my ARM9 target. Without armv4-mont.pl:
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 2.567500s 0.072826s      0.4     13.7
> dsa 2048 bits 0.722857s 0.865833s      1.4      1.2
> 
> With armv4-mont.pl:
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 3.433333s 0.104896s      0.3      9.5
> dsa 2048 bits 1.058000s 1.253750s      0.9      0.8

Can you provide data for speed rsa dsa, which tests variety of length?
As mentioned earlier, we should observe decreasing improvement
coefficient, be it positive or negative...

> What's more, I dug out a Cortex-A9 target (Atmel CycloneV board, operating
> with single core only) and got this without armv4-mont.pl:
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.127342s 0.003628s      7.9    275.6
> dsa 2048 bits 0.035971s 0.042778s     27.8     23.4
> 
> and this with armv4-mont.pl:
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.172931s 0.005222s      5.8    191.5
> dsa 2048 bits 0.052565s 0.061350s     19.0     16.3
> 
> As you can see, in both cases using armv4-mont.pl makes it 30% slower. So
> whatever is going on, it isn't down to the CPU. I think there must be
> something else going on. I'll get back to you.

This is odd. Two questions. As far as I understand Cyclone V is FPGA, so
what does Cortex-A9 target mean in the context? Is it actual Cortex-A9
with FPGA beside it, or is it ARM processor "loaded" to FPGA? I don't
think one can give any performance guarantees in latter case. Two, can
you show /proc/cpuinfo?

On side note. Specifically Cortex-A9 has turned to be an odd-ball. It's
mentioned in commentary section, for some reason NEON doesn't give any
improvement on A9 on longer key lengths, but losses are considered
acceptable because it improves performance on other NEON-capable
processors. Well, this doesn't explain above discrepancies, which is why
it's a side note...


From appro at openssl.org  Tue Jun 16 21:42:36 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 16 Jun 2015 23:42:36 +0200
Subject: [openssl-dev] ARM optimised montgomery
	multiplication	(armv4-mont)
In-Reply-To: <55808A00.4090200@eCosCentric.com>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com>
Message-ID: <5580984C.2070602@openssl.org>

> What's more, I dug out a Cortex-A9 target (Atmel CycloneV board, operating
> with single core only) and got this without armv4-mont.pl:
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.127342s 0.003628s      7.9    275.6
> dsa 2048 bits 0.035971s 0.042778s     27.8     23.4
> 
> and this with armv4-mont.pl:
>                   sign    verify    sign/s verify/s
> rsa 2048 bits 0.172931s 0.005222s      5.8    191.5
> dsa 2048 bits 0.052565s 0.061350s     19.0     16.3

For reference, here is what I get on 1GHz Cortex-A9

Without armv4-mont:

rsa 2048 bits 0.041590s 0.001116s     24.0    896.0
dsa 2048 bits 0.011574s 0.013831s     86.4     72.3

With armv4-mont, no NEON

rsa 2048 bits 0.033003s 0.000954s     30.3   1048.4
dsa 2048 bits 0.009794s 0.011211s    102.1     89.2

NEON (recall that A9 is an odd-ball)

rsa 2048 bits 0.034281s 0.000987s     29.2   1012.8
dsa 2048 bits 0.010163s 0.012027s     98.4     83.1

Here is 600MHz ARM11xx, an ARMv6 processor.

Without armv4-mont:

rsa 2048 bits 0.110889s 0.002923s      9.0    342.1
dsa 2048 bits 0.030182s 0.036533s     33.1     27.4

With armv4-mont:

rsa 2048 bits 0.087895s 0.002569s     11.4    389.2
dsa 2048 bits 0.026412s 0.031384s     37.9     31.9


From jifl at eCosCentric.com  Wed Jun 17 00:20:59 2015
From: jifl at eCosCentric.com (Jonathan Larmour)
Date: Wed, 17 Jun 2015 01:20:59 +0100
Subject: [openssl-dev] ARM optimised montgomery
	multiplication	(armv4-mont)
In-Reply-To: <5580913B.40208@openssl.org>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com> <5580913B.40208@openssl.org>
Message-ID: <5580BD6B.2060203@eCosCentric.com>

On 16/06/15 22:12, Andy Polyakov wrote:
>>>> With some experimentation, it turns out that if I *stop* using the
>>>> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
>>>> a simplish test to establish and close a simple SSL connection went from 28
>>>> seconds to 18. (It's quite a slow target at any time).
>>>>
>>>> In other words, this "optimised" version has slowed things down dramatically.
>>>> Has anyone queried the value of the asm of armv4-mont.pl any time in the last
>>>> few years?
[snip]

Hi Andy,

I found the cause - although OPENSSL_BN_ASM_MONT was defined, I hadn't noticed
that a colleague had put a #define OPENSSL_NO_ASM somewhere else (this isn't
linux but a port to our own OS). It turns out that (surprisingly) this
combination changes behaviour rather than barfing - it's even explicitly
catered for in bn_asm.c.

Regardless, the effect is that a different bn_mul_mont implementation gets
used, and the armv4-mont.pl implementation gets ignored entirely.

With that fixed, I now have greatly improved performance as expected. An
unfortunate waste of time for us both, but thanks for the assistance.

Jifl
-- 
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

From rt at openssl.org  Wed Jun 17 07:00:12 2015
From: rt at openssl.org (noreply@send-email.org via RT)
Date: Wed, 17 Jun 2015 07:00:12 +0000
Subject: [openssl-dev] [openssl.org #3912] OpenSSL 0.9.8zg crashes with
	s_client param.
In-Reply-To: <5a7566964342fe517e213e0b97fb1263@send-email.org>
References: <RT-Ticket-3912@openssl.org>
 <5a7566964342fe517e213e0b97fb1263@send-email.org>
Message-ID: <rt-4.0.19-4883-1434524412-732.3912-21-0@openssl.org>

OpenSSL 0.9.8ge crashes with the following parameter "openssl.exe s_client" on
Win32 platoform. 1.0.0s does not have this bug. Event: BEX Application:
openssl.exe TimeStamp: 557ae67e Offset: 0003fb70 ExceptionCode: c0000417
ExceptionData: 00000000 OS: 6.1.7601.2.1.0.256.48 LocaleID: 1041 Info1: 8d30
Info2: 8d30fe76231fde0d8591f9e28ccb5915 Info3: 7e30 Info4:
7e30565054b1b6b6911327a78f804968

-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From appro at openssl.org  Wed Jun 17 09:36:31 2015
From: appro at openssl.org (Andy Polyakov)
Date: Wed, 17 Jun 2015 11:36:31 +0200
Subject: [openssl-dev] ARM optimised montgomery
	multiplication	(armv4-mont)
In-Reply-To: <5580BD6B.2060203@eCosCentric.com>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com> <5580913B.40208@openssl.org>
 <5580BD6B.2060203@eCosCentric.com>
Message-ID: <55813F9F.6030002@openssl.org>

Hi,

>>>>> With some experimentation, it turns out that if I *stop* using the
>>>>> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version, the time for
>>>>> a simplish test to establish and close a simple SSL connection went from 28
>>>>> seconds to 18. (It's quite a slow target at any time).
>>>>>
>>>>> In other words, this "optimised" version has slowed things down dramatically.
>>>>> Has anyone queried the value of the asm of armv4-mont.pl any time in the last
>>>>> few years?
> [snip]
> 
> I found the cause - although OPENSSL_BN_ASM_MONT was defined, I hadn't noticed
> that a colleague had put a #define OPENSSL_NO_ASM somewhere else (this isn't
> linux but a port to our own OS). It turns out that (surprisingly) this
> combination changes behaviour rather than barfing - it's even explicitly
> catered for in bn_asm.c.

In other words sanity restored. Phew! Incidentally, as next step I was
going to ask for copy of your bn_asm.o (yes, binary .o, yes, bn_asm.o,
not armv4-mont.o), and bn_mul_mont should have shown up and presumably
noticed as unexpected...

> Regardless, the effect is that a different bn_mul_mont implementation gets
> used, and the armv4-mont.pl implementation gets ignored entirely.

Right. And as mentioned in commentary bn_mul_mont in bn_asm.c is just a
template with no performance promises attached. Note that it still
exhibits previously mentioned breaking point...

> With that fixed, I now have greatly improved performance as expected.

So that with armv4-mont actually in the loop, the breaking point is
still beyond practical key lengths, even on ARM9.

> An
> unfortunate waste of time for us both, but thanks for the assistance.

Given that presented timings for ARM9 are kind of astronomic you might
want to consider if it's possible to use other algorithms. EC is getting
wider adoption now and can perform better. Not to mention that optimized
NIST P-256 EC was recently added...

Cheers.


From rt at openssl.org  Wed Jun 17 10:38:46 2015
From: rt at openssl.org (Tomas Mraz via RT)
Date: Wed, 17 Jun 2015 10:38:46 +0000
Subject: [openssl-dev] [openssl.org #3913] [RFE] Add a way to application to
	know a minimum DH size allowed by the client
In-Reply-To: <1434528613.29794.19.camel@redhat.com>
References: <RT-Ticket-3913@openssl.org> <1434528613.29794.19.camel@redhat.com>
Message-ID: <rt-4.0.19-5164-1434537525-1742.3913-21-0@openssl.org>

The current minimum DH size allowed by the client is 768 bits which is a
hardcoded constant. It would be nice if the constant was at least
#define in public headers or even better if there was an API to query
various minimum and maximum bit sizes that are checked in the library
such as the maximum supported key lengths, etc.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)


_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From mynidiravichandra at gmail.com  Wed Jun 17 11:18:05 2015
From: mynidiravichandra at gmail.com (Ravichandra)
Date: Wed, 17 Jun 2015 16:48:05 +0530
Subject: [openssl-dev] ARM optimised montgomery multiplication
	(armv4-mont)
In-Reply-To: <55813F9F.6030002@openssl.org>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com> <5580913B.40208@openssl.org>
 <5580BD6B.2060203@eCosCentric.com> <55813F9F.6030002@openssl.org>
Message-ID: <CADsCSeTL30nV6ForREHjPmQ+efNbZKLvmSsS_Rak5D2Gg3LX2g@mail.gmail.com>

Hi Andy,
    When using on armv8 architecture, does this mont mul ASM code have any
optimization with linux-aarch64 configuration?

Thanks
Ravichandra

On Wed, Jun 17, 2015 at 3:06 PM, Andy Polyakov <appro at openssl.org> wrote:

> Hi,
>
> >>>>> With some experimentation, it turns out that if I *stop* using the
> >>>>> crypto/bn/asm/bn/armv4-mont.pl generated asm "optimised" version,
> the time for
> >>>>> a simplish test to establish and close a simple SSL connection went
> from 28
> >>>>> seconds to 18. (It's quite a slow target at any time).
> >>>>>
> >>>>> In other words, this "optimised" version has slowed things down
> dramatically.
> >>>>> Has anyone queried the value of the asm of armv4-mont.pl any time
> in the last
> >>>>> few years?
> > [snip]
> >
> > I found the cause - although OPENSSL_BN_ASM_MONT was defined, I hadn't
> noticed
> > that a colleague had put a #define OPENSSL_NO_ASM somewhere else (this
> isn't
> > linux but a port to our own OS). It turns out that (surprisingly) this
> > combination changes behaviour rather than barfing - it's even explicitly
> > catered for in bn_asm.c.
>
> In other words sanity restored. Phew! Incidentally, as next step I was
> going to ask for copy of your bn_asm.o (yes, binary .o, yes, bn_asm.o,
> not armv4-mont.o), and bn_mul_mont should have shown up and presumably
> noticed as unexpected...
>
> > Regardless, the effect is that a different bn_mul_mont implementation
> gets
> > used, and the armv4-mont.pl implementation gets ignored entirely.
>
> Right. And as mentioned in commentary bn_mul_mont in bn_asm.c is just a
> template with no performance promises attached. Note that it still
> exhibits previously mentioned breaking point...
>
> > With that fixed, I now have greatly improved performance as expected.
>
> So that with armv4-mont actually in the loop, the breaking point is
> still beyond practical key lengths, even on ARM9.
>
> > An
> > unfortunate waste of time for us both, but thanks for the assistance.
>
> Given that presented timings for ARM9 are kind of astronomic you might
> want to consider if it's possible to use other algorithms. EC is getting
> wider adoption now and can perform better. Not to mention that optimized
> NIST P-256 EC was recently added...
>
> Cheers.
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150617/faca03e6/attachment-0001.html>

From rt at openssl.org  Wed Jun 17 11:30:25 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 17 Jun 2015 11:30:25 +0000
Subject: [openssl-dev] [openssl.org #3912] OpenSSL 0.9.8zg crashes with
	s_client param.
In-Reply-To: <5a7566964342fe517e213e0b97fb1263@send-email.org>
References: <RT-Ticket-3912@openssl.org>
 <5a7566964342fe517e213e0b97fb1263@send-email.org>
Message-ID: <rt-4.0.19-5164-1434540625-1342.3912-6-0@openssl.org>

0.9.8 only gets security fixes; this seems like a crashed caused by incorrect
arguments.
closing.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From appro at openssl.org  Wed Jun 17 12:11:45 2015
From: appro at openssl.org (Andy Polyakov)
Date: Wed, 17 Jun 2015 14:11:45 +0200
Subject: [openssl-dev] ARM optimised montgomery multiplication
	(armv4-mont)
In-Reply-To: <CADsCSeTL30nV6ForREHjPmQ+efNbZKLvmSsS_Rak5D2Gg3LX2g@mail.gmail.com>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com> <5580913B.40208@openssl.org>
 <5580BD6B.2060203@eCosCentric.com> <55813F9F.6030002@openssl.org>
 <CADsCSeTL30nV6ForREHjPmQ+efNbZKLvmSsS_Rak5D2Gg3LX2g@mail.gmail.com>
Message-ID: <55816401.8060609@openssl.org>

Hi,

>     When using on armv8 architecture, does this mont mul ASM code have
> any optimization with linux-aarch64 configuration?

There is ambiguity in posed question. In direct context of this
discussion "this" as in "this mont mul ASM code" ought to refer to
armv4-mont. And then the answer would have to be "no, ARMv4 code can not
used in aarch64 build". But it's also possible to generalize and
consider "this" more like "this thing, Montgomery multiplication module,
you are talking about, is there aarch64 equivalent?" And answer to such
question would be yes, there is corresponding armv8-mont module in
development branch.


From stefan.eissing at greenbytes.de  Wed Jun 17 12:08:11 2015
From: stefan.eissing at greenbytes.de (Stefan Eissing)
Date: Wed, 17 Jun 2015 14:08:11 +0200
Subject: [openssl-dev] SNI/ALPN ordering
Message-ID: <9A81E755-7722-44D9-A400-E1771331B6B0@greenbytes.de>

*NOT A SECURITY ISSUE*

That our of the way: while debugging my HTTP/2 module for Apache httpd, I see that the callback for SNI seems to be invoked *after* the callback for ALPN had been called (OpenSSL 1.0.2c). Can this be correct? Is there anything to influence this ordering?

My issue is that the proposed ALPN protocols depend on the virtual host the client wants to talk to. So, the observed order poses a bit of a problem. The code *can* check the server name via SSL_get_servername() and the correct name is reported. However this is not how it is supposed to work, right?

Again, if there is anything influencing the order of the callback invocation, I'd be willing to adapt. Otherwise, I think, the order needs to be defined in the OpenSSL API and it should be SNI before ALPN. 

Cheers,

  Stefan


<green/>bytes GmbH
Hafenweg 16, 48155 M?nster, Germany
Phone: +49 251 2807760. Amtsgericht M?nster: HRB5782




From rt at openssl.org  Wed Jun 17 12:35:55 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 17 Jun 2015 12:35:55 +0000
Subject: [openssl-dev] [openssl.org #3912] OpenSSL 0.9.8zg crashes with
	s_client param.
In-Reply-To: <5a7566964342fe517e213e0b97fb1263@send-email.org>
References: <RT-Ticket-3912@openssl.org>
 <5a7566964342fe517e213e0b97fb1263@send-email.org>
Message-ID: <rt-4.0.19-5164-1434544555-51.3912-6-0@openssl.org>

On Wed Jun 17 07:00:12 2015, noreply at send-email.org wrote:
> OpenSSL 0.9.8ge crashes with the following parameter "openssl.exe
> s_client" on
> Win32 platoform. 1.0.0s does not have this bug. Event: BEX

I just looked into this. It seems s_client on 0.9.8 crashes if it is unable to
connect to open a socket to the server. It looks like this bug has been there
for a while. As Rich said, 0.9.8 is only receiving security fixes now so this
isn't going to be fixed - especially as there is an easy workaround (make sure
s_client connects!!!)

Matt


From mynidiravichandra at gmail.com  Wed Jun 17 13:16:16 2015
From: mynidiravichandra at gmail.com (Ravichandra)
Date: Wed, 17 Jun 2015 18:46:16 +0530
Subject: [openssl-dev] ARM optimised montgomery multiplication
	(armv4-mont)
In-Reply-To: <55816401.8060609@openssl.org>
References: <557EF3D0.8000108@eCosCentric.com> <55801204.2070108@openssl.org>
 <55808A00.4090200@eCosCentric.com> <5580913B.40208@openssl.org>
 <5580BD6B.2060203@eCosCentric.com> <55813F9F.6030002@openssl.org>
 <CADsCSeTL30nV6ForREHjPmQ+efNbZKLvmSsS_Rak5D2Gg3LX2g@mail.gmail.com>
 <55816401.8060609@openssl.org>
Message-ID: <CADsCSeQhWVzwb70xDh8nVpQ46KHr-FFwtKwrd6kaGCe_qAiDSA@mail.gmail.com>

I meant armv4-mont code. As the answer to that question is no, i would have
asked if we have a support for armv8-mont. Your response answers both of my
questions.

Thanks
Ravichandra

On Wed, Jun 17, 2015 at 5:41 PM, Andy Polyakov <appro at openssl.org> wrote:

> Hi,
>
> >     When using on armv8 architecture, does this mont mul ASM code have
> > any optimization with linux-aarch64 configuration?
>
> There is ambiguity in posed question. In direct context of this
> discussion "this" as in "this mont mul ASM code" ought to refer to
> armv4-mont. And then the answer would have to be "no, ARMv4 code can not
> used in aarch64 build". But it's also possible to generalize and
> consider "this" more like "this thing, Montgomery multiplication module,
> you are talking about, is there aarch64 equivalent?" And answer to such
> question would be yes, there is corresponding armv8-mont module in
> development branch.
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150617/aae691cb/attachment.html>

From rsalz at akamai.com  Wed Jun 17 14:40:38 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 17 Jun 2015 14:40:38 +0000
Subject: [openssl-dev] SNI/ALPN ordering
In-Reply-To: <9A81E755-7722-44D9-A400-E1771331B6B0@greenbytes.de>
References: <9A81E755-7722-44D9-A400-E1771331B6B0@greenbytes.de>
Message-ID: <51703d70be0b4a5d9fe3d5d5bf672df9@ustx2ex-dag1mb2.msg.corp.akamai.com>

> My issue is that the proposed ALPN protocols depend on the virtual host the
> client wants to talk to. So, the observed order poses a bit of a problem. The
> code *can* check the server name via SSL_get_servername() and the
> correct name is reported. However this is not how it is supposed to work,
> right?

I can imagine all sorts of things that depend on the SNI value, and not having it be the first does seem like a bug.


From gmaheshwari24.6 at gmail.com  Wed Jun 17 16:27:20 2015
From: gmaheshwari24.6 at gmail.com (gaurav maheshwari)
Date: Wed, 17 Jun 2015 21:57:20 +0530
Subject: [openssl-dev] 32 bit compilation of armv8 assembly
	support(openssl-1.0.2a)
In-Reply-To: <5579455E.7070409@openssl.org>
References: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
 <5579455E.7070409@openssl.org>
Message-ID: <CAJ+HfNbW-f7+yiHZYkgR5jv65w+yZep=StB09qqWNnpgqSb6CQ@mail.gmail.com>

I am compiling using the linaro aarch64 compiler for ILP32 ABI. *linux-armv4
*compilation
with option -march =armv8_a  giving lots of compilation errors as compiler
does not
supports mnemonics  . So I have tried to compile with new configuration for
ilp32
with "aarch64_asm".

"linux-armilp32","gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

In compilation with this configuration getting error
* "cannot represent BFD_RELOC_64 relocation in this object file
format" *in sha1-armv8.s.


linaro compiler path ("
http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu
").

On Thu, Jun 11, 2015 at 1:52 PM, Andy Polyakov <appro at openssl.org> wrote:

> Hi,
>
> >        Can we use armv8 assembly support provided in openssl-1.0.2a for
> > 32 bit mode compilation.
>
> It *is* used in 32-bit compilation as-is. aesv8-armx and ghashv8-armx
> are included in armv4_asm, and sha1-armv4-large and sha256-armv4 modules
> incorporate support for ARMv8 SHA instructions. But don't miss
> commentary in Configure prior linux-armv4 line.
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150617/8909d42e/attachment.html>

From appro at openssl.org  Wed Jun 17 20:36:38 2015
From: appro at openssl.org (Andy Polyakov)
Date: Wed, 17 Jun 2015 22:36:38 +0200
Subject: [openssl-dev] 32 bit compilation of armv8
	assembly	support(openssl-1.0.2a)
In-Reply-To: <CAJ+HfNbW-f7+yiHZYkgR5jv65w+yZep=StB09qqWNnpgqSb6CQ@mail.gmail.com>
References: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
 <5579455E.7070409@openssl.org>
 <CAJ+HfNbW-f7+yiHZYkgR5jv65w+yZep=StB09qqWNnpgqSb6CQ@mail.gmail.com>
Message-ID: <5581DA56.80205@openssl.org>

First of all let's establish ground rule. In order for something to be
supported we ought to have access to platform, hardware is preferred,
emulator can be acceptable. It naturally also includes tool chain and
minimal ecosystem in form of working run-time. You refer to
releases.linaro.org, but is there mabi=ilp32 libc? I don't see one. I
have Debian jessie on 96board, but is there ilp32 libc available? I
don't see one. Is executable format in question widely supported by
kernel? Mine says "exec format error"... In other words to me ilp32 is
not viable option, which makes it impossible to support at this point.

> I am compiling using the linaro aarch64 compiler for ILP32 ABI.
> *linux-armv4 *compilation
> with option -march =armv8_a  giving lots of compilation errors as
> compiler does not
> supports mnemonics  . So I have tried to compile with new configuration
> for ilp32
> with "aarch64_asm".
> 
> "linux-armilp32","gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
> SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
> ${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
> .so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> 
> In compilation with this configuration getting error* "cannot represent 
> BFD_RELOC_64 relocation in this object file format" *in sha1-armv8.s.  

Obviously it would require some adjustments, because mabi=ilp32 was not
considered when it was written. It might be sufficient to replace .quad
with .long, but there is no way for me to tell for reasons discussed in
the beginning. So that if there is some serious interest, then you have
to explain yourself better than providing reference to releases.linaro.org.

From rt at openssl.org  Wed Jun 17 20:53:25 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Wed, 17 Jun 2015 20:53:25 +0000
Subject: [openssl-dev] [openssl.org #3914] Library on Windows does not
	export SSL_CTX_set_options or SSL_set_options
In-Reply-To: <CAH8yC8nk3Ow=sPYTLBO+jZfRUJ_OaON47Q9=_i_zDWoc9bhpXw@mail.gmail.com>
References: <RT-Ticket-3914@openssl.org>
 <CAH8yC8nk3Ow=sPYTLBO+jZfRUJ_OaON47Q9=_i_zDWoc9bhpXw@mail.gmail.com>
Message-ID: <rt-4.0.19-8538-1434574405-101.3914-21-0@openssl.org>

I was kind of surprised to learn this... The SSL library on Windows
does not export SSL_CTX_set_options or SSL_set_options.

Below is a dumpbin /exports of ssleay.dll.

*****

    543E8F47 time date stamp Wed Oct 15 11:14:15 2014
        0.00 version
           1 ordinal base
         362 number of functions
         281 number of names
    ordinal hint RVA      name
        121    0 00038190 BIO_f_ssl
        173    1 00038CE0 BIO_new_buffer_ssl_connect
        122    2 00038AD0 BIO_new_ssl
        174    3 00038C30 BIO_new_ssl_connect
        124    4 00038B70 BIO_ssl_copy_session_id
        131    5 00038BF0 BIO_ssl_shutdown
        268    6 00023910 DTLSv1_client_method
        273    7 0001F780 DTLSv1_method
        275    8 00021BB0 DTLSv1_server_method
          1    9 00038D50 ERR_load_SSL_strings
        301    A 0002F8A0 PEM_read_SSL_SESSION
        302    B 0002F860 PEM_read_bio_SSL_SESSION
        305    C 0002F930 PEM_write_SSL_SESSION
        296    D 0002F8E0 PEM_write_bio_SSL_SESSION
        332    E 00039AD0 SRP_Calc_A_param
        335    F 000397F0 SRP_generate_client_master_secret
        333   10 000396A0 SRP_generate_server_master_secret
          2   11 00032730 SSL_CIPHER_description
        128   12 00032D60 SSL_CIPHER_get_bits
        349   13 00032D80 SSL_CIPHER_get_id
        130   14 00032D40 SSL_CIPHER_get_name
        129   15 00032D00 SSL_CIPHER_get_version
        184   16 00032E30 SSL_COMP_add_compression_method
        276   17 00032E10 SSL_COMP_get_compression_methods
        271   18 00032FD0 SSL_COMP_get_name
        334   19 00038D90 SSL_CTX_SRP_CTX_free
        330   1A 00039260 SSL_CTX_SRP_CTX_init
          3   1B 0002E9A0 SSL_CTX_add_client_CA
          4   1C 00030000 SSL_CTX_add_session
        243   1D 0002A690 SSL_CTX_callback_ctrl
          5   1E 0002A0B0 SSL_CTX_check_private_key
          6   1F 0002A440 SSL_CTX_ctrl
          7   20 0002FF60 SSL_CTX_flush_sessions
          8   21 0002ADB0 SSL_CTX_free
        180   22 00029AB0 SSL_CTX_get_cert_store
          9   23 0002E8A0 SSL_CTX_get_client_CA_list
        288   24 0002F470 SSL_CTX_get_client_cert_cb
        138   25 0002C0F0 SSL_CTX_get_ex_data
        167   26 0002C090 SSL_CTX_get_ex_new_index
        282   27 0002F770 SSL_CTX_get_info_callback
        140   28 0002BDB0 SSL_CTX_get_quiet_shutdown
        179   29 0002F4F0 SSL_CTX_get_timeout
         10   2A 00029E70 SSL_CTX_get_verify_callback
        228   2B 00029E50 SSL_CTX_get_verify_depth
         11   2C 00029E40 SSL_CTX_get_verify_mode
        141   2D 0002BF90 SSL_CTX_load_verify_locations
         12   2E 0002D210 SSL_CTX_new
         13   2F 00030220 SSL_CTX_remove_session
        279   30 0002F750 SSL_CTX_sess_get_get_cb
        287   31 0002F710 SSL_CTX_sess_get_new_cb
        289   32 0002F730 SSL_CTX_sess_get_remove_cb
        280   33 0002F740 SSL_CTX_sess_set_get_cb
        278   34 0002F700 SSL_CTX_sess_set_new_cb
        285   35 0002F720 SSL_CTX_sess_set_remove_cb
        245   36 0002A430 SSL_CTX_sessions
        310   37 000299D0 SSL_CTX_set1_param
        181   38 0002C120 SSL_CTX_set_cert_store
        232   39 0002AF40 SSL_CTX_set_cert_verify_callback
         15   3A 0002A7D0 SSL_CTX_set_cipher_list
         16   3B 0002E840 SSL_CTX_set_client_CA_list
        284   3C 0002F780 SSL_CTX_set_client_cert_cb
        293   3D 0002F790 SSL_CTX_set_client_cert_engine
        283   3E 0002F840 SSL_CTX_set_cookie_generate_cb
        281   3F 0002F850 SSL_CTX_set_cookie_verify_cb
         17   40 0002AF20 SSL_CTX_set_default_passwd_cb
        235   41 0002AF30 SSL_CTX_set_default_passwd_cb_userdata
        142   42 0002BF70 SSL_CTX_set_default_verify_paths
        143   43 0002C0D0 SSL_CTX_set_ex_data
        264   44 00029770 SSL_CTX_set_generate_session_id
        286   45 0002F760 SSL_CTX_set_info_callback
        266   46 0002C4F0 SSL_CTX_set_msg_callback
        361   47 0002AC90 SSL_CTX_set_next_proto_select_cb
        355   48 0002AC80 SSL_CTX_set_next_protos_advertised_cb
        295   49 0002C4C0 SSL_CTX_set_psk_client_callback
        303   4A 0002C4E0 SSL_CTX_set_psk_server_callback
        238   4B 00029950 SSL_CTX_set_purpose
        145   4C 0002BDA0 SSL_CTX_set_quiet_shutdown
        231   4D 000296B0 SSL_CTX_set_session_id_context
        328   4E 00039C70 SSL_CTX_set_srp_cb_arg
        316   4F 00039CB0 SSL_CTX_set_srp_client_pwd_callback
        324   50 00039C10 SSL_CTX_set_srp_password
        325   51 00039C30 SSL_CTX_set_srp_strength
        329   52 00039BF0 SSL_CTX_set_srp_username
        318   53 00039C90 SSL_CTX_set_srp_username_callback
        326   54 00039C50 SSL_CTX_set_srp_verify_param_callback
         19   55 00029630 SSL_CTX_set_ssl_version
        178   56 0002F4E0 SSL_CTX_set_timeout
        358   57 00028FD0 SSL_CTX_set_tlsext_use_srtp
        176   58 0002C1E0 SSL_CTX_set_tmp_dh_callback
        269   59 0002C240 SSL_CTX_set_tmp_ecdh_callback
        177   5A 0002C180 SSL_CTX_set_tmp_rsa_callback
        237   5B 00029990 SSL_CTX_set_trust
         21   5C 0002AF50 SSL_CTX_set_verify
        225   5D 0002AF60 SSL_CTX_set_verify_depth
         22   5E 00035040 SSL_CTX_use_PrivateKey
         23   5F 00035230 SSL_CTX_use_PrivateKey_ASN1
         24   60 000350E0 SSL_CTX_use_PrivateKey_file
         25   61 00034D60 SSL_CTX_use_RSAPrivateKey
         26   62 00034FC0 SSL_CTX_use_RSAPrivateKey_ASN1
         27   63 00034E70 SSL_CTX_use_RSAPrivateKey_file
         28   64 00035820 SSL_CTX_use_certificate
         29   65 00035A10 SSL_CTX_use_certificate_ASN1
        222   66 00035AA0 SSL_CTX_use_certificate_chain_file
         30   67 000358C0 SSL_CTX_use_certificate_file
        294   68 0002C2A0 SSL_CTX_use_psk_identity_hint
         31   69 0002F170 SSL_SESSION_free
        340   6A 0002F470 SSL_SESSION_get0_peer
        362   6B 0002F0E0 SSL_SESSION_get_compress_id
        146   6C 0002EFA0 SSL_SESSION_get_ex_data
        168   6D 0002EF40 SSL_SESSION_get_ex_new_index
        277   6E 0002F0D0 SSL_SESSION_get_id
        134   6F 0002F440 SSL_SESSION_get_time
        136   70 0002F430 SSL_SESSION_get_timeout
         32   71 0002EFC0 SSL_SESSION_new
         33   72 00037A10 SSL_SESSION_print
         34   73 00037EE0 SSL_SESSION_print_fp
        342   74 0002F480 SSL_SESSION_set1_id_context
        148   75 0002EF80 SSL_SESSION_set_ex_data
        135   76 0002F450 SSL_SESSION_set_time
        137   77 0002F410 SSL_SESSION_set_timeout
        338   78 00038EA0 SSL_SRP_CTX_free
        331   79 00038FB0 SSL_SRP_CTX_init
         35   7A 0002DD70 SSL_accept
         36   7B 0002E980 SSL_add_client_CA
        188   7C 0002ECD0 SSL_add_dir_cert_subjects_to_stack
        185   7D 0002EB80 SSL_add_file_cert_subjects_to_stack
         37   7E 000343D0 SSL_alert_desc_string
         38   7F 000345E0 SSL_alert_desc_string_long
         39   80 000343A0 SSL_alert_type_string
         40   81 00034370 SSL_alert_type_string_long
        344   82 0002C520 SSL_cache_hit
        244   83 0002A3F0 SSL_callback_ctrl
         41   84 0002A140 SSL_check_private_key
         42   85 0002C580 SSL_clear
         43   86 0002DDA0 SSL_connect
         44   87 00029F90 SSL_copy_session_id
         45   88 0002CD90 SSL_ctrl
        125   89 0002D860 SSL_do_handshake
         46   8A 0002D9E0 SSL_dup
         47   8B 0002E740 SSL_dup_CA_list
        353   8C 0002ACA0 SSL_export_keying_material
         48   8D 0002CA80 SSL_free
        356   8E 0002AC60 SSL_get0_next_proto_negotiated
        242   8F 0002EEE0 SSL_get1_session
        150   90 0002BE10 SSL_get_SSL_CTX
         49   91 0002BBC0 SSL_get_certificate
         52   92 0002A750 SSL_get_cipher_list
         55   93 0002A6F0 SSL_get_ciphers
         56   94 0002E8B0 SSL_get_client_CA_list
        127   95 0002BC00 SSL_get_current_cipher
        272   96 0002BC20 SSL_get_current_compression
        274   97 0002BC40 SSL_get_current_expansion
         57   98 0002A200 SSL_get_default_timeout
         58   99 0002D6F0 SSL_get_error
        151   9A 0002C070 SSL_get_ex_data
        175   9B 0002DE10 SSL_get_ex_data_X509_STORE_CTX_idx
        169   9C 0002C010 SSL_get_ex_new_index
         59   9D 0002CCE0 SSL_get_fd
        240   9E 00029D50 SSL_get_finished
        165   9F 0002BFC0 SSL_get_info_callback
         60   A0 00029F60 SSL_get_peer_cert_chain
         61   A1 00029F00 SSL_get_peer_certificate
        241   A2 00029DB0 SSL_get_peer_finished
        126   A3 0002BBE0 SSL_get_privatekey
        304   A4 0002C490 SSL_get_psk_identity
        297   A5 0002C470 SSL_get_psk_identity_hint
        153   A6 0002BDD0 SSL_get_quiet_shutdown
         63   A7 00029AA0 SSL_get_rbio
         64   A8 00029ED0 SSL_get_read_ahead
        246   A9 0002CCE0 SSL_get_rfd
        357   AA 00029060 SSL_get_selected_srtp_profile
        291   AB 0002AB30 SSL_get_servername
        292   AC 0002AB60 SSL_get_servername_type
        154   AD 0002EED0 SSL_get_session
         65   AE 0002A8B0 SSL_get_shared_ciphers
        155   AF 0002BDF0 SSL_get_shutdown
        322   B0 00039B90 SSL_get_srp_N
        317   B1 00039B70 SSL_get_srp_g
        319   B2 00039BD0 SSL_get_srp_userinfo
        323   B3 00039BB0 SSL_get_srp_username
        360   B4 00029030 SSL_get_srtp_profiles
         66   B5 0002B950 SSL_get_ssl_method
         69   B6 00029E30 SSL_get_verify_callback
        229   B7 00029E10 SSL_get_verify_depth
         70   B8 00029E40 SSL_get_verify_mode
        157   B9 0002C000 SSL_get_verify_result
         71   BA 0002BAC0 SSL_get_version
         72   BB 00029AB0 SSL_get_wbio
        247   BC 00029AC0 SSL_get_wfd
        249   BD 00029850 SSL_has_matching_session_id
        183   BE 00037F80 SSL_library_init
         73   BF 0002E9C0 SSL_load_client_CA_file
         74   C0 0002DDD0 SSL_load_error_strings
         75   C1 0002C710 SSL_new
         76   C2 0002A280 SSL_peek
         77   C3 00029EE0 SSL_pending
         78   C4 0002A220 SSL_read
         79   C5 0002A360 SSL_renegotiate
        312   C6 0002A3A0 SSL_renegotiate_abbreviated
        265   C7 0002A3E0 SSL_renegotiate_pending
         80   C8 000347F0 SSL_rstate_string
         81   C9 000339E0 SSL_rstate_string_long
        359   CA 0002AB90 SSL_select_next_proto
        309   CB 000299F0 SSL_set1_param
        290   CC 0002BE20 SSL_set_SSL_CTX
         82   CD 0002D8E0 SSL_set_accept_state
         83   CE 00029A10 SSL_set_bio
         84   CF 0002A840 SSL_set_cipher_list
         85   D0 0002E7E0 SSL_set_client_CA_list
         86   D1 0002D960 SSL_set_connect_state
        339   D2 0002C510 SSL_set_debug
        158   D3 0002C050 SSL_set_ex_data
         87   D4 00029B10 SSL_set_fd
        258   D5 000297E0 SSL_set_generate_session_id
        160   D6 0002BFB0 SSL_set_info_callback
        267   D7 0002C500 SSL_set_msg_callback
        300   D8 0002C4B0 SSL_set_psk_client_callback
        298   D9 0002C4D0 SSL_set_psk_server_callback
        236   DA 00029970 SSL_set_purpose
        161   DB 0002BDC0 SSL_set_quiet_shutdown
         88   DC 00029EC0 SSL_set_read_ahead
         89   DD 00029C80 SSL_set_rfd
         90   DE 0002F2D0 SSL_set_session
        189   DF 00029710 SSL_set_session_id_context
        307   E0 0002F500 SSL_set_session_secret_cb
        306   E1 0002F540 SSL_set_session_ticket_ext
        308   E2 0002F520 SSL_set_session_ticket_ext_cb
        162   E3 0002BDE0 SSL_set_shutdown
        320   E4 00039510 SSL_set_srp_server_param
        321   E5 00039410 SSL_set_srp_server_param_pw
         91   E6 0002B960 SSL_set_ssl_method
        348   E7 0002BFE0 SSL_set_state
        354   E8 00029000 SSL_set_tlsext_use_srtp
        187   E9 0002C210 SSL_set_tmp_dh_callback
        270   EA 0002C270 SSL_set_tmp_ecdh_callback
        186   EB 0002C1B0 SSL_set_tmp_rsa_callback
        239   EC 000299B0 SSL_set_trust
         94   ED 00029E80 SSL_set_verify
        226   EE 00029EA0 SSL_set_verify_depth
        163   EF 0002BFF0 SSL_set_verify_result
         95   F0 00029BB0 SSL_set_wfd
         96   F1 0002CD30 SSL_shutdown
        336   F2 000392F0 SSL_srp_server_param_with_username
        166   F3 0002BFD0 SSL_state
         97   F4 00033A20 SSL_state_string
         98   F5 00032FE0 SSL_state_string_long
         99   F6 00034960 SSL_use_PrivateKey
        100   F7 00034B60 SSL_use_PrivateKey_ASN1
        101   F8 00034A00 SSL_use_PrivateKey_file
        102   F9 00035530 SSL_use_RSAPrivateKey
        103   FA 000357A0 SSL_use_RSAPrivateKey_ASN1
        104   FB 00035640 SSL_use_RSAPrivateKey_file
        105   FC 000352B0 SSL_use_certificate
        106   FD 000354B0 SSL_use_certificate_ASN1
        107   FE 00035350 SSL_use_certificate_file
        299   FF 0002C370 SSL_use_psk_identity_hint
        164  100 0002BE00 SSL_version
        182  101 0002C170 SSL_want
        108  102 0002A2E0 SSL_write
        110  103 00019B90 SSLv23_client_method
        111  104 000182E0 SSLv23_method
        112  105 00018D40 SSLv23_server_method
        113  106 00004660 SSLv2_client_method
        114  107 00001010 SSLv2_method
        115  108 00002B80 SSLv2_server_method
        116  109 00010290 SSLv3_client_method
        117  10A 00005DA0 SSLv3_method
        118  10B 0000AEB0 SSLv3_server_method
        314  10C 0001A100 TLSv1_1_client_method
        313  10D 0001A020 TLSv1_1_method
        315  10E 0001A090 TLSv1_1_server_method
        341  10F 0001A0F0 TLSv1_2_client_method
        350  110 0001A010 TLSv1_2_method
        343  111 0001A080 TLSv1_2_server_method
        172  112 0001A150 TLSv1_client_method
        170  113 0001A070 TLSv1_method
        171  114 0001A0E0 TLSv1_server_method
        119  115 00036740 d2i_SSL_SESSION
        120  116 00035CA0 i2d_SSL_SESSION
         14  117 0003CF90 ssl2_ciphers
         18  118 00048750 ssl3_ciphers
  Summary
       10000 .data
        3000 .pdata
        A000 .rdata
        1000 .reloc
        1000 .rsrc
       3B000 .text
C:\OpenSSL-Win64\bin>
C:\OpenSSL-Win64\bin>

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From dragon at dancingdragon.be  Wed Jun 17 21:00:23 2015
From: dragon at dancingdragon.be (Joey Yandle)
Date: Wed, 17 Jun 2015 14:00:23 -0700
Subject: [openssl-dev] [openssl.org #3914] Library on Windows does not
 export SSL_CTX_set_options or SSL_set_options
In-Reply-To: <rt-4.0.19-8538-1434574405-101.3914-21-0@openssl.org>
References: <RT-Ticket-3914@openssl.org>
 <CAH8yC8nk3Ow=sPYTLBO+jZfRUJ_OaON47Q9=_i_zDWoc9bhpXw@mail.gmail.com>
 <rt-4.0.19-8538-1434574405-101.3914-21-0@openssl.org>
Message-ID: <5581DFE7.4020206@dancingdragon.be>

> I was kind of surprised to learn this... The SSL library on Windows
> does not export SSL_CTX_set_options or SSL_set_options.

That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \


From rt at openssl.org  Wed Jun 17 21:10:38 2015
From: rt at openssl.org (Joey Yandle via RT)
Date: Wed, 17 Jun 2015 21:10:38 +0000
Subject: [openssl-dev] [openssl.org #3914] Library on Windows does not
	export SSL_CTX_set_options or SSL_set_options
In-Reply-To: <5581DFE7.4020206@dancingdragon.be>
References: <RT-Ticket-3914@openssl.org>
 <CAH8yC8nk3Ow=sPYTLBO+jZfRUJ_OaON47Q9=_i_zDWoc9bhpXw@mail.gmail.com>
 <rt-4.0.19-8538-1434574405-101.3914-21-0@openssl.org>
 <5581DFE7.4020206@dancingdragon.be>
Message-ID: <rt-4.0.19-8538-1434575438-322.3914-6-0@openssl.org>

> I was kind of surprised to learn this... The SSL library on Windows
> does not export SSL_CTX_set_options or SSL_set_options.

That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \



From waywardgeek at google.com  Wed Jun 17 22:50:43 2015
From: waywardgeek at google.com (Bill Cox)
Date: Wed, 17 Jun 2015 15:50:43 -0700
Subject: [openssl-dev] Possible bug in extended master secret resumption
	logic
Message-ID: <CAH9QtQGrBEJgbUV9fUa51ArSp3Y4i51z0YAqFxNeBic0c+RW8Q@mail.gmail.com>

I work on Token Binding/ChannelID, which is why I'm diving into OpenSSL
code recently, and the extended master secret code specifically.  Adam
Langley pointed out some fishy code  to me, which I've just had time to
analyze.  Here's some code in t1_lib.c, function
ssl_add_serverhello_tlsext, at line 1724:

    if (!s->hit && s->session->flags & SSL_SESS_FLAG_EXTMS) {
        s2n(TLSEXT_TYPE_extended_master_secret, ret);
        s2n(0, ret);
    }

Adam thought the check for !s->hit should be removed, IIRC.  It looks like
this check will cause the EXTMS TLS extension to never be sent by the
server in a session-resumption handshake.  This violates the latest EXTMS
spec <https://tools.ietf.org/html/draft-ietf-tls-session-hash-05#page-7>:

"If the ClientHello contains the extension and the server decides to accept
the abbreviated handshake, then the server MUST include the
"extended_master_secret" extension in its ServerHello message."

In this case, I think the client should assume the server resuming the
session is not EXTMS capable, while the original server was.  This might
occur in some cases, when data-centers are transitioning, for example.  I
think the client should abort the handshake and try again with a new
session.  It seems to me that clients behaing this way might result in a
lot of session resumptions failing.  Am I reading this correctly?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150617/8edeea60/attachment.html>

From rt at openssl.org  Thu Jun 18 03:30:45 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Thu, 18 Jun 2015 03:30:45 +0000
Subject: [openssl-dev] [openssl.org #3914] Library on Windows does not
	export SSL_CTX_set_options or SSL_set_options
In-Reply-To: <CAH8yC8mqTVrgByhfs+SCEmZEDuqtMDxkgA7qtzmn4A8h=NLisg@mail.gmail.com>
References: <RT-Ticket-3914@openssl.org>
 <CAH8yC8nk3Ow=sPYTLBO+jZfRUJ_OaON47Q9=_i_zDWoc9bhpXw@mail.gmail.com>
 <rt-4.0.19-8538-1434574405-101.3914-21-0@openssl.org>
 <5581DFE7.4020206@dancingdragon.be>
 <rt-4.0.19-8538-1434575438-322.3914-6-0@openssl.org>
 <CAH8yC8mqTVrgByhfs+SCEmZEDuqtMDxkgA7qtzmn4A8h=NLisg@mail.gmail.com>
Message-ID: <rt-4.0.19-9054-1434598245-1316.3914-6-0@openssl.org>

Dooh.... I should have known :(

Sorry about the extra noise.

On Wed, Jun 17, 2015 at 5:10 PM, Joey Yandle via RT <rt at openssl.org> wrote:
>> I was kind of surprised to learn this... The SSL library on Windows
>> does not export SSL_CTX_set_options or SSL_set_options.
>
> That's because it's a macro:
>
> grep -r SSL_CTX_set_options | grep define
>
> ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \
>



From appro at openssl.org  Thu Jun 18 10:52:24 2015
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 18 Jun 2015 12:52:24 +0200
Subject: [openssl-dev] 32 bit compilation of armv8
	assembly	support(openssl-1.0.2a)
In-Reply-To: <5581DA56.80205@openssl.org>
References: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
 <5579455E.7070409@openssl.org>
 <CAJ+HfNbW-f7+yiHZYkgR5jv65w+yZep=StB09qqWNnpgqSb6CQ@mail.gmail.com>
 <5581DA56.80205@openssl.org>
Message-ID: <5582A2E8.8070601@openssl.org>

>> I am compiling using the linaro aarch64 compiler for ILP32 ABI.
>> *linux-armv4 *compilation
>> with option -march =armv8_a  giving lots of compilation errors as
>> compiler does not
>> supports mnemonics.

This is because toolchain referred to in one of previous messages is
only capable of generating/compiling AArch64 code. linux-armv4 is
equipped with AArch32 assembly and toolchain in question is indeed not
capable of compiling it. But it doesn't mean that if you compile
linux-armv4 target with right compiler you won't be able to run
resulting binary code on AArch64 system. This actually works and worked
from day one. Unlike abi=ilp32 that is (which is not actually
upstream-ed yet according https://wiki.linaro.org/Platform/arm64-ilp32).
Well, as for "works from day one", you are likely to have to add 32-bit
libc, but on Debian [or derivative] it's straightforward dpkg
--add-architecture. Well, there also might be *processors* that don't
support AArch32 (ARM specification allows it), but all those readily
available now are all perfectly capable of executing linux-armv4
targets. And when it comes to ARMv8 crypto extensions, they would
deliver same performance as 64-bit code, so you don't loose anything.
(Not to mention that binary can be "universal" and make best of any
particular processor it executed on.)

>> So I have tried to compile with new configuration
>> for ilp32
>> with "aarch64_asm".
>>
>> "linux-armilp32","gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
>> SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
>> ${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
>> .so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
>>
>> In compilation with this configuration getting error* "cannot represent 
>> BFD_RELOC_64 relocation in this object file format" *in sha1-armv8.s.  
> 
> Obviously it would require some adjustments, because mabi=ilp32 was not
> considered when it was written. It might be sufficient to replace .quad
> with .long, but there is no way for me to tell for reasons discussed in
> the beginning. So that if there is some serious interest, then you have
> to explain yourself better than providing reference to releases.linaro.org.

After having a look at available documentation, attached patch is likely
to be sufficient to compile with -mabi=ilp32. But once again, I have no
way to actually verify it and therefore no promises can be provided.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: armv8-ilp32.diff
Type: text/x-diff
Size: 1503 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/674e5a7e/attachment.diff>

From gmaheshwari24.6 at gmail.com  Thu Jun 18 13:00:25 2015
From: gmaheshwari24.6 at gmail.com (gaurav maheshwari)
Date: Thu, 18 Jun 2015 18:30:25 +0530
Subject: [openssl-dev] 32 bit compilation of armv8 assembly
	support(openssl-1.0.2a)
In-Reply-To: <5582A2E8.8070601@openssl.org>
References: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
 <5579455E.7070409@openssl.org>
 <CAJ+HfNbW-f7+yiHZYkgR5jv65w+yZep=StB09qqWNnpgqSb6CQ@mail.gmail.com>
 <5581DA56.80205@openssl.org> <5582A2E8.8070601@openssl.org>
Message-ID: <CAJ+HfNbUZQ9FqXpR4tfQvLhxHodtbT-VYrb70RWrRRwiWrL8uw@mail.gmail.com>

It is compiling successfully and all openssl test are passing for ILP32
abi.
Thanks.

On Thu, Jun 18, 2015 at 4:22 PM, Andy Polyakov <appro at openssl.org> wrote:

> >> I am compiling using the linaro aarch64 compiler for ILP32 ABI.
> >> *linux-armv4 *compilation
> >> with option -march =armv8_a  giving lots of compilation errors as
> >> compiler does not
> >> supports mnemonics.
>
> This is because toolchain referred to in one of previous messages is
> only capable of generating/compiling AArch64 code. linux-armv4 is
> equipped with AArch32 assembly and toolchain in question is indeed not
> capable of compiling it. But it doesn't mean that if you compile
> linux-armv4 target with right compiler you won't be able to run
> resulting binary code on AArch64 system. This actually works and worked
> from day one. Unlike abi=ilp32 that is (which is not actually
> upstream-ed yet according https://wiki.linaro.org/Platform/arm64-ilp32).
> Well, as for "works from day one", you are likely to have to add 32-bit
> libc, but on Debian [or derivative] it's straightforward dpkg
> --add-architecture. Well, there also might be *processors* that don't
> support AArch32 (ARM specification allows it), but all those readily
> available now are all perfectly capable of executing linux-armv4
> targets. And when it comes to ARMv8 crypto extensions, they would
> deliver same performance as 64-bit code, so you don't loose anything.
> (Not to mention that binary can be "universal" and make best of any
> particular processor it executed on.)
>
> >> So I have tried to compile with new configuration
> >> for ilp32
> >> with "aarch64_asm".
> >>
> >> "linux-armilp32","gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
> >> SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
> >> ${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
> >> .so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> >>
> >> In compilation with this configuration getting error* "cannot represent
> >> BFD_RELOC_64 relocation in this object file format" *in sha1-armv8.s.
> >
> > Obviously it would require some adjustments, because mabi=ilp32 was not
> > considered when it was written. It might be sufficient to replace .quad
> > with .long, but there is no way for me to tell for reasons discussed in
> > the beginning. So that if there is some serious interest, then you have
> > to explain yourself better than providing reference to
> releases.linaro.org.
>
> After having a look at available documentation, attached patch is likely
> to be sufficient to compile with -mabi=ilp32. But once again, I have no
> way to actually verify it and therefore no promises can be provided.
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/1efed944/attachment-0001.html>

From rt at openssl.org  Thu Jun 18 13:10:36 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:10:36 +0000
Subject: [openssl-dev] [openssl.org #3881] [PATCH] Instrument OpenSSL
	buffer heap memory usage
In-Reply-To: <59F59E65-E5AC-446C-AD57-361500FABC31@akamai.com>
References: <RT-Ticket-3881@openssl.org>
 <85151430-D7D2-47B9-A88A-41A1AE2F7160@akamai.com>
 <rt-4.0.4-5720-1432972080-1071.3881-21-0@openssl.org>
 <59F59E65-E5AC-446C-AD57-361500FABC31@akamai.com>
Message-ID: <rt-4.0.19-12873-1434633036-1381.3881-6-0@openssl.org>

Updates to the buffer heap memory usage patch:
Updated documentation.

Github link:
https://github.com/akamai/openssl/commit/222f0d2d94be8b92c306c062320fd15b59a9000a

And attached file.

Thank you,

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 30, 2015, at 3:48 AM, Joy Tu via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description:  Instrument OpenSSL buffer heap memory usage

Added function to register callbacks to allocate and free data buffers.

These callbacks can then allocate and free the memory as needed, while
also recording buffer allocations.

This permits a user-definable implementation of FREE_BUFLIST, which has been removed.

(Yes, documentation is lacking at this point).

Github link:

https://github.com/akamai/openssl/commit/4a6d71bbd2f4fe38ebcbe2f9917a1c7fedd117f8

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?

<0022-Instrument-OpenSSL-buffer-heap-memory-usage.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0021-RT3881-Instrument-OpenSSL-buffer-heap-memory-usage.patch
Type: application/octet-stream
Size: 5789 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/5e2cc67c/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/5e2cc67c/attachment.htm>

From rt at openssl.org  Thu Jun 18 13:16:41 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:16:41 +0000
Subject: [openssl-dev] [openssl.org #3875] [PATCH] Add external
	X509_STORE to SSL_CTX
In-Reply-To: <2641C6DE-3D16-4CED-A4B2-30F3724A6A44@akamai.com>
References: <RT-Ticket-3875@openssl.org>
 <007C934D-7A2C-47A2-94B2-B681EED65F4E@akamai.com>
 <rt-4.0.4-1870-1432758764-57.3875-21-0@openssl.org>
 <2641C6DE-3D16-4CED-A4B2-30F3724A6A44@akamai.com>
Message-ID: <rt-4.0.19-9054-1434633401-811.3875-6-0@openssl.org>

Updated this patch with new documentation.

Github link:
https://github.com/akamai/openssl/commit/34cd12929b479f0c229bb9d564e2d2eec3d8df5d

And attachment.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 27, 2015, at 4:32 PM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add external X509_STORE to SSL_CTX

Add SSL_CTX_set_cert_store_ref() API to add an external X509_STORE to
an SSL_CTX. (There is no get API).
Github link:
https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?

<0018-Add-external-X509_STORE-to-SSL_CTX.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0018-RT3875-Add-external-X509_STORE-to-SSL_CTX.patch
Type: application/octet-stream
Size: 4714 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/fd5b02ca/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/fd5b02ca/attachment.htm>

From appro at openssl.org  Thu Jun 18 13:20:11 2015
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 18 Jun 2015 15:20:11 +0200
Subject: [openssl-dev] 32 bit compilation of armv8 assembly
	support(openssl-1.0.2a)
In-Reply-To: <CAJ+HfNbUZQ9FqXpR4tfQvLhxHodtbT-VYrb70RWrRRwiWrL8uw@mail.gmail.com>
References: <CAJ+HfNav2Wp2h8L8cc9y0Ho2TcERYsSMvSROnm-k1a7YdkoAtg@mail.gmail.com>
 <5579455E.7070409@openssl.org>
 <CAJ+HfNbW-f7+yiHZYkgR5jv65w+yZep=StB09qqWNnpgqSb6CQ@mail.gmail.com>
 <5581DA56.80205@openssl.org> <5582A2E8.8070601@openssl.org>
 <CAJ+HfNbUZQ9FqXpR4tfQvLhxHodtbT-VYrb70RWrRRwiWrL8uw@mail.gmail.com>
Message-ID: <5582C58B.2010107@openssl.org>

> It is compiling successfully and all openssl test are passing for ILP32
> abi.

There are remaining questions.

The fact that tests pass is definitely good sign, but there still is an
open and burning question. What if relocations were not resolved
correctly and run-time switch doesn't really work as intended. It's
possible to confirm this indirectly by comparing results for
'apps/openssl speed sha' and 'env OPENSSL_armcap=0 apps/openssl speed
sha'. Can you do that?

Development branch has more ARMv8 code. Can you test that too?

And last question is not really a question. All this ought to mean that
you have put together all those not-yet-upstreamed bits together, i.e.
glibc, multilib, kernel patches, huh? For public reference I want once
again to point out that additional ABI for AArch64 is work in very
progress, and so far the only way to compile 32-bit code and target
ARMv8 was to adhere to usual 32-bit ARM support (which does utilize
ARMv8 crypto extensions), and that is currently the supported way, for
good or bad.


From rt at openssl.org  Thu Jun 18 13:49:29 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:49:29 +0000
Subject: [openssl-dev] [openssl.org #3865] [Patch] Add
	DISALLOW_RENEGOTIATION option
In-Reply-To: <BEC6ABE1-CA8C-437B-B3F6-CFDED7B72AB1@akamai.com>
References: <RT-Ticket-3865@openssl.org>
 <ADAC4C23-AE6F-473C-8F45-6C73F2AE4372@akamai.com>
 <rt-4.0.4-20614-1432666570-540.3865-21-0@openssl.org>
 <BEC6ABE1-CA8C-437B-B3F6-CFDED7B72AB1@akamai.com>
Message-ID: <rt-4.0.19-13366-1434635369-1107.3865-6-0@openssl.org>

Hello,

Please find an updated patch that includes updated documentation.

Github link:

https://github.com/akamai/openssl/commit/9f3a6ecb83e80cbfebc038a860d5ce63817e0098

Thanks.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 26, 2015, at 2:56 PM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add DISALLOW_RENEGOTIATION option

Add support to disallow renegotiation in openssl
The bit definition may need to change when pulled.

Github link:
https://github.com/akamai/openssl/commit/fcab621995d55d8873a02a96d5a8157f38469ebb

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet."

<0010-Add-DISALLOW_RENEGOTIATION-option.patch>
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0010-RT3865-Add-DISALLOW_RENEGOTIATION-option.patch
Type: application/octet-stream
Size: 4792 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/483c2dc6/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/483c2dc6/attachment-0001.htm>

From rt at openssl.org  Thu Jun 18 13:56:10 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:56:10 +0000
Subject: [openssl-dev] [openssl.org #3868] [PATCH] Add
	SSL_get0_peer_certificate()
In-Reply-To: <CA822569-210A-4660-989D-73C4ED3ED4E6@akamai.com>
References: <RT-Ticket-3868@openssl.org>
 <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com>
 <rt-4.0.4-20929-1432667343-1334.3868-21-0@openssl.org>
 <CA822569-210A-4660-989D-73C4ED3ED4E6@akamai.com>
Message-ID: <rt-4.0.19-13366-1434635770-1327.3868-6-0@openssl.org>

Hello,

We have an updated version of the patch that includes updated documentation.

GitHub link:
https://github.com/akamai/openssl/commit/980d0b6e67dce0088dcb49e6fa66bbb868f43000

And attachment

Thanks,

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0013-RT3868-Add-SSL_get0_peer_certificate.patch
Type: application/octet-stream
Size: 3600 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/97a8bd13/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/97a8bd13/attachment.htm>

From rt at openssl.org  Thu Jun 18 14:03:07 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 14:03:07 +0000
Subject: [openssl-dev] [openssl.org #3869] [PATCH] Add shared session
	lists in SSL_CTX
In-Reply-To: <B2C85C44-D0FE-42D1-AECD-5FECFD42D5A3@akamai.com>
References: <RT-Ticket-3869@openssl.org>
 <DDA91451-862F-4594-9883-0AE1E82AFA11@akamai.com>
 <rt-4.0.4-21735-1432672191-269.3869-21-0@openssl.org>
 <B2C85C44-D0FE-42D1-AECD-5FECFD42D5A3@akamai.com>
Message-ID: <rt-4.0.19-12873-1434636187-1641.3869-6-0@openssl.org>

Hello,

We have an updated patch for this: updated documentation

Github link:
https://github.com/akamai/openssl/commit/246b86ee329c70cbf8c822e852cc31e1076d53fd

And attachment.

Thanks,
--
-Todd Short
// tshort at akamai.com
// "One if by land, two if by sea, three if by the Internet."

On May 26, 2015, at 4:29 PM, Short, Todd via RT <rt at openssl.org> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add shared session lists in SSL_CTX

Support for shared session lists via SSL_CTX_share_session_cache().
Added locking during the sharing and cleanup.

Github link:
https://github.com/akamai/openssl/commit/fe1e4ac33a89e9176af0b645eafc2aaec5fc2266

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?

<0014-Add-shared-session-lists-in-SSL_CTX.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0014-RT3869-Add-shared-session-lists-in-SSL_CTX.patch
Type: application/octet-stream
Size: 10359 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/ccf48b7e/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/ccf48b7e/attachment.htm>

From rt at openssl.org  Thu Jun 18 14:05:11 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 14:05:11 +0000
Subject: [openssl-dev] [openssl.org #3870] [PATCH] Async TLSEXT
	servername support.
In-Reply-To: <29247FC8-23F3-4D0E-9517-C2072990D68B@akamai.com>
References: <RT-Ticket-3870@openssl.org>
 <F03C5B27-F5A2-457E-8129-F4630EBD42F8@akamai.com>
 <rt-4.0.4-21743-1432672193-634.3870-21-0@openssl.org>
 <29247FC8-23F3-4D0E-9517-C2072990D68B@akamai.com>
Message-ID: <rt-4.0.19-13366-1434636311-1579.3870-6-0@openssl.org>

Hello,

We have an updated patch for this, which includes updated documentation, unit-tests and copyright.

Github link:
https://github.com/akamai/openssl/commit/1f26946f7e5cf85b20c3b97a8c0e6a869f9a04fa

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 26, 2015, at 4:29 PM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Async TLSEXT servername support.

Adds support for processing the servername TLSEXT asynchronously,
using the SSL_WANT_EVENT mechanism (RT 3724).

Github link:
https://github.com/akamai/openssl/commit/0205cc4eee7084e65a69995293ad584f7da21fa9

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet."

<0015-Async-TLSEXT-servername-support.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0015-RT3870-Async-TLSEXT-servername-support.patch
Type: application/octet-stream
Size: 21277 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/de585421/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/de585421/attachment-0001.htm>

From rt at openssl.org  Thu Jun 18 14:07:36 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 14:07:36 +0000
Subject: [openssl-dev] [openssl.org #3873] [PATCH] Add traffic counters
In-Reply-To: <81E22218-CB15-45CF-94CF-4A42DBDE73CB@akamai.com>
References: <RT-Ticket-3873@openssl.org>
 <38061981-5F00-4E0E-85CC-5FFAD7F29A92@akamai.com>
 <rt-4.0.4-1870-1432758752-749.3873-21-0@openssl.org>
 <81E22218-CB15-45CF-94CF-4A42DBDE73CB@akamai.com>
Message-ID: <rt-4.0.19-13366-1434636456-508.3873-6-0@openssl.org>

Hello,

We have an updated patch for this: includes documentation.

Github link:
https://github.com/akamai/openssl/commit/956053b4b4a6f374df939c3d830cb1a095428ac9

And attachment.

Thanks,
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 27, 2015, at 4:32 PM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add traffic counters

Add data counters to SSL structure bytes_written and bytes_read
Includes SSL_get_byte_counters() API.

Github link:
https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?

<0016-Add-traffic-counters.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0016-RT3873-Add-traffic-counters.patch
Type: application/octet-stream
Size: 4944 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/17647a2f/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/17647a2f/attachment.htm>

From tshort at akamai.com  Thu Jun 18 14:09:37 2015
From: tshort at akamai.com (Short, Todd)
Date: Thu, 18 Jun 2015 14:09:37 +0000
Subject: [openssl-dev] [openssl.org #3874] [PATCH] Add certificate
	verify	data to SSL struct
In-Reply-To: <rt-4.0.4-1888-1432758754-1080.3874-21-0@openssl.org>
References: <RT-Ticket-3874@openssl.org>
 <0734FE78-5086-4625-9CAC-DCA7DB6E59B8@akamai.com>
 <rt-4.0.4-1888-1432758754-1080.3874-21-0@openssl.org>
Message-ID: <8210FF8A-1467-4DCD-AF20-4248BFE2B7B7@akamai.com>

Hello:

We have an updated patch with documentation for this.

Github link:
https://github.com/akamai/openssl/commit/e431afa72e77da4463c8cdcac8893336b9b32b04

And attachment.

Thanks,

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 27, 2015, at 4:32 PM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add certificate verify data to SSL struct

Add app_verify_callback and app_verify_arg to the SSL structure and add
SSL_SESSION_set_verify_result() API. The values are copied from the
SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API.

Github link:
https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?

<0017-Add-certificate-verify-data-to-SSL-struct.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/fb3fe57d/attachment.html>

From rt at openssl.org  Thu Jun 18 14:09:52 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 14:09:52 +0000
Subject: [openssl-dev] [openssl.org #3874] [PATCH] Add certificate
	verify data to SSL struct
In-Reply-To: <8210FF8A-1467-4DCD-AF20-4248BFE2B7B7@akamai.com>
References: <RT-Ticket-3874@openssl.org>
 <0734FE78-5086-4625-9CAC-DCA7DB6E59B8@akamai.com>
 <rt-4.0.4-1888-1432758754-1080.3874-21-0@openssl.org>
 <8210FF8A-1467-4DCD-AF20-4248BFE2B7B7@akamai.com>
Message-ID: <rt-4.0.19-13366-1434636592-1743.3874-6-0@openssl.org>

Hello:

We have an updated patch with documentation for this.

Github link:
https://github.com/akamai/openssl/commit/e431afa72e77da4463c8cdcac8893336b9b32b04

And attachment.

Thanks,

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On May 27, 2015, at 4:32 PM, Short, Todd via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add certificate verify data to SSL struct

Add app_verify_callback and app_verify_arg to the SSL structure and add
SSL_SESSION_set_verify_result() API. The values are copied from the
SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API.

Github link:
https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet.?

<0017-Add-certificate-verify-data-to-SSL-struct.patch>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



From scott.opensshdev.2015 at scottrix.co.uk  Thu Jun 18 22:55:34 2015
From: scott.opensshdev.2015 at scottrix.co.uk (scott.opensshdev.2015 at scottrix.co.uk)
Date: Thu, 18 Jun 2015 23:55:34 +0100
Subject: [openssl-dev] HMAC ABI fix.
In-Reply-To: <mailman.2037.1434665480.26108.openssl-dev@openssl.org>
References: <mailman.2037.1434665480.26108.openssl-dev@openssl.org>
Message-ID: <20150618225534.GB705@scottrix.co.uk>

Hi,

We use openssl extensively in our product, today we upgraded from openssl 
1.0.2b to 1.0.2c (we build everything from source so the ABI change from 
1.0.2a to 1.0.2b didn't affect us), and are seeing issues.  I think I have 
tracked it down to the lines below from HMAC_init_ex, which were introduced 
as part of the HMAC ABI fix (1030f89f5ea238820645e3d34049eb1bd30e81c4):

+    /* If we are changing MD then we must have a key */
+    if (md != NULL && md != ctx->md && (key == NULL || len < 0))
+        return 0;

previously you could call HMAC_init_ex with an evp_md and a NULL key, this 
would save the evp_md in the HMAC_ctx and return, now it just returns and 
on first call you need to provide both a key and an evp_md.  Before I go 
and modify our code, is this change intentional ?

The docs (http://www.openssl.org/docs/crypto/hmac.html) state:

HMAC_Init_ex() initialises or reuses a HMAC_CTX structure to use the 
function evp_md and key key. Either can be NULL, in which case the existing 
one will be reused. HMAC_CTX_init() must have been called before the first 
use of an HMAC_CTX in this function.

Thanks in advance for the clarification,

Scott Harrison


From matt at openssl.org  Fri Jun 19 00:04:08 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Jun 2015 01:04:08 +0100
Subject: [openssl-dev] HMAC ABI fix.
In-Reply-To: <20150618225534.GB705@scottrix.co.uk>
References: <mailman.2037.1434665480.26108.openssl-dev@openssl.org>
 <20150618225534.GB705@scottrix.co.uk>
Message-ID: <55835C78.1080906@openssl.org>



On 18/06/15 23:55, scott.opensshdev.2015 at scottrix.co.uk wrote:
> Hi,
> 
> We use openssl extensively in our product, today we upgraded from
> openssl 1.0.2b to 1.0.2c (we build everything from source so the ABI
> change from 1.0.2a to 1.0.2b didn't affect us), and are seeing issues. 
> I think I have tracked it down to the lines below from HMAC_init_ex,
> which were introduced as part of the HMAC ABI fix
> (1030f89f5ea238820645e3d34049eb1bd30e81c4):
> 
> +    /* If we are changing MD then we must have a key */
> +    if (md != NULL && md != ctx->md && (key == NULL || len < 0))
> +        return 0;
> 
> previously you could call HMAC_init_ex with an evp_md and a NULL key,
> this would save the evp_md in the HMAC_ctx and return, now it just
> returns and on first call you need to provide both a key and an evp_md. 
> Before I go and modify our code, is this change intentional ?

Yes. The previous code was quite broken in this area - this change
seemed the least impact option without breaking the ABI and resolving
the issues.

> The docs (http://www.openssl.org/docs/crypto/hmac.html) state:
> 
> HMAC_Init_ex() initialises or reuses a HMAC_CTX structure to use the
> function evp_md and key key. Either can be NULL, in which case the
> existing one will be reused. HMAC_CTX_init() must have been called
> before the first use of an HMAC_CTX in this function.

In order to reuse an existing one there has to be something there in the
first place to reuse - so whilst what you were doing worked, I don't
think that was guaranteed by the documentation! Although actually the
docs probably need updating because I don't think it ever makes sense to
change the MD and reuse the key (the previous code wouldn't have worked
doing this anyway).

Matt


From rt at openssl.org  Fri Jun 19 01:13:40 2015
From: rt at openssl.org (Geoff_Lowe@McAfee.com via RT)
Date: Fri, 19 Jun 2015 01:13:40 +0000
Subject: [openssl-dev] [openssl.org #3915] BUG/PATCH: ssl_sess.c no longer
	compiles when no-tlsext is specified
In-Reply-To: <28a8d7a0c911455c9b1e255dca52a2fa@MIVEXUSR1N01.corpzone.internalzone.com>
References: <RT-Ticket-3915@openssl.org>
 <28a8d7a0c911455c9b1e255dca52a2fa@MIVEXUSR1N01.corpzone.internalzone.com>
Message-ID: <rt-4.0.19-13889-1434676420-1829.3915-21-0@openssl.org>

>From ticket 2720, it seems the official position is that "no-tlsext" is NOT supported.  However, for those who still try to use it, the recent fixes for CVE-2015-1791 seem to have introduced more problems for the 0.9.8 code base (and maybe others - not sure).

This report can be added to RT#2720.

@@ -151,12 +151,12 @@
         * the case of an error whilst halfway through constructing dest
         */
        dest->ciphers = NULL;
 #ifndef OPENSSL_NO_TLSEXT
        dest->tlsext_hostname = NULL;
-#endif
        dest->tlsext_tick = NULL;
+#endif
        memset(&dest->ex_data, 0, sizeof(dest->ex_data));
 
        /* We deliberately don't copy the prev and next pointers */
        dest->prev = NULL;
        dest->next = NULL;
@@ -185,20 +185,20 @@
                dest->tlsext_hostname = BUF_strdup(src->tlsext_hostname);
                if (dest->tlsext_hostname == NULL) {
                        goto err;
                }
        }
-#endif
 
        if (ticket != 0) {
                dest->tlsext_tick = BUF_memdup(src->tlsext_tick, src->tlsext_ticklen);
                if(dest->tlsext_tick == NULL)
                        goto err;
        } else {
                dest->tlsext_tick_lifetime_hint = 0;
                dest->tlsext_ticklen = 0;
        }
+#endif
 
        return dest;
 err:
        SSLerr(SSL_F_SSL_SESSION_DUP, ERR_R_MALLOC_FAILURE);
        SSL_SESSION_free(dest);


Geoff

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From scott.opensshdev.2015 at scottrix.co.uk  Fri Jun 19 06:53:34 2015
From: scott.opensshdev.2015 at scottrix.co.uk (Scott Harrison)
Date: Fri, 19 Jun 2015 07:53:34 +0100
Subject: [openssl-dev] HMAC ABI fix.
In-Reply-To: <55835C78.1080906@openssl.org>
References: <mailman.2037.1434665480.26108.openssl-dev@openssl.org>
 <20150618225534.GB705@scottrix.co.uk>
 <55835C78.1080906@openssl.org>
Message-ID: <20150619065333.GA4537@scottrix.co.uk>

Matt,

Thanks for the clarification.

Scott.

On Fri, Jun 19, 2015 at 01:04:08AM +0100, Matt Caswell wrote:
>
>
>On 18/06/15 23:55, scott.opensshdev.2015 at scottrix.co.uk wrote:
>> Hi,
>>
>> We use openssl extensively in our product, today we upgraded from
>> openssl 1.0.2b to 1.0.2c (we build everything from source so the ABI
>> change from 1.0.2a to 1.0.2b didn't affect us), and are seeing issues.
>> I think I have tracked it down to the lines below from HMAC_init_ex,
>> which were introduced as part of the HMAC ABI fix
>> (1030f89f5ea238820645e3d34049eb1bd30e81c4):
>>
>> +    /* If we are changing MD then we must have a key */
>> +    if (md != NULL && md != ctx->md && (key == NULL || len < 0))
>> +        return 0;
>>
>> previously you could call HMAC_init_ex with an evp_md and a NULL key,
>> this would save the evp_md in the HMAC_ctx and return, now it just
>> returns and on first call you need to provide both a key and an evp_md.
>> Before I go and modify our code, is this change intentional ?
>
>Yes. The previous code was quite broken in this area - this change
>seemed the least impact option without breaking the ABI and resolving
>the issues.
>
>> The docs (http://www.openssl.org/docs/crypto/hmac.html) state:
>>
>> HMAC_Init_ex() initialises or reuses a HMAC_CTX structure to use the
>> function evp_md and key key. Either can be NULL, in which case the
>> existing one will be reused. HMAC_CTX_init() must have been called
>> before the first use of an HMAC_CTX in this function.
>
>In order to reuse an existing one there has to be something there in the
>first place to reuse - so whilst what you were doing worked, I don't
>think that was guaranteed by the documentation! Although actually the
>docs probably need updating because I don't think it ever makes sense to
>change the MD and reuse the key (the previous code wouldn't have worked
>doing this anyway).
>
>Matt
>
>_______________________________________________
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From cuoq at trust-in-soft.com  Fri Jun 19 11:47:32 2015
From: cuoq at trust-in-soft.com (Pascal Cuoq)
Date: Fri, 19 Jun 2015 11:47:32 +0000
Subject: [openssl-dev] In s_server.c,
	inconsistent file when FIONBIO is not defined
Message-ID: <187FBFD6-E684-4DED-AD61-CA9FE3DD2FFD@trust-in-soft.com>

Following additional OpenSSL tests being suggested after the call on this list (many thanks! we'll have more to say later?), we are parsing and executing previously unvisited parts of OpenSSL in a C interpreter.

The interpreter can be considered as a different compilation platform (although the long-term goal is to accurately mimic the widespread existing ones). In particular, we find ourselves pre-processing and parsing the file apps/s_server.c without FIONBIO being defined because this is not a full Unix environment yet (FIONBIO is a pre-POSIX macro usually defined by some system header). It seems to me that s_server.c is not a valid C file in these conditions, because then this file avoids declaring a variable s_nbio line 231:

https://github.com/openssl/openssl/blob/3b061a00e39d2e4ad524ff01cbdc0c53fe8171ee/apps/s_server.c#L231

? but it still uses the variable s_nbio in places without a #ifdef FIONBIO guard, e.g. line 395:

https://github.com/openssl/openssl/blob/3b061a00e39d2e4ad524ff01cbdc0c53fe8171ee/apps/s_server.c#L395

I see three options:

- I am doing something utterly wrong (beyond trying to execute OpenSSL in this C interpreter. I will stick to that mistake). If you see what, please tell me.

- the intention is to have s_server.c be compilable without FIONBIO being defined, but it drifted out of this state because it was seldom compiled in this mode. A patch like the one attached to this email should fix this. Any reviewer should pay particular attention to the last hunk, about what should happen to the original line ?s_nbio = s_nbio_test = 1;?

- the fact that s_server.c does not compile any more without FIONBIO being defined is a sign that no one uses it in this mode anymore. Thus all tests for the presence of this macro should be suppressed from the file in order to remove cruft and ease code review.

Any additional alternative? We can prepare a patch for the third option if it is the rightest one.

Pascal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_ifdef.patch
Type: application/octet-stream
Size: 1133 bytes
Desc: fix_ifdef.patch
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150619/d68c42dc/attachment.obj>

From rsalz at akamai.com  Fri Jun 19 15:14:50 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Jun 2015 15:14:50 +0000
Subject: [openssl-dev] In s_server.c,
 inconsistent file when FIONBIO is not defined
In-Reply-To: <187FBFD6-E684-4DED-AD61-CA9FE3DD2FFD@trust-in-soft.com>
References: <187FBFD6-E684-4DED-AD61-CA9FE3DD2FFD@trust-in-soft.com>
Message-ID: <6a0aaacea10e464f9ea7be6c9bfef136@ustx2ex-dag1mb2.msg.corp.akamai.com>

Sounds like a bug.

We don't/can't build with all #ifdef options tested.  Send a patch?

From rt at openssl.org  Sat Jun 20 11:20:31 2015
From: rt at openssl.org (=?UTF-8?B?TWFydGluIFZlam7DoXI=?= via RT)
Date: Sat, 20 Jun 2015 11:20:31 +0000
Subject: [openssl-dev] [openssl.org #3917] Bug report -- potential memory
	leak
In-Reply-To: <e93221e7796d424c976b6a5058f8dd7c@EX13-CZ-02.cz.avg.com>
References: <RT-Ticket-3917@openssl.org>
 <e93221e7796d424c976b6a5058f8dd7c@EX13-CZ-02.cz.avg.com>
Message-ID: <rt-4.0.19-8352-1434799231-1079.3917-21-0@openssl.org>

Hi,

affects all systems, happens at least in OpenSSL 1.0.2c.

In `crypto/cms/cms_smime.c`, the function `CMS_verify` will leak memory pointed to by `cms_certs` and `crls` variables if the call to `BIO_new_mem_buf` on line 374 fails.

Thanks,
--
Martin


-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rt at openssl.org  Sat Jun 20 11:20:32 2015
From: rt at openssl.org (Loganaden Velvindron via RT)
Date: Sat, 20 Jun 2015 11:20:32 +0000
Subject: [openssl-dev] [openssl.org #3918] check return value of EC_POINT_mul
In-Reply-To: <CAOp4FwR1-VKEkiiXgkEen23_R_8at5fCh0f636HoBhhgNh0QfQ@mail.gmail.com>
References: <RT-Ticket-3918@openssl.org>
 <CAOp4FwR1-VKEkiiXgkEen23_R_8at5fCh0f636HoBhhgNh0QfQ@mail.gmail.com>
Message-ID: <rt-4.0.19-6035-1434799232-802.3918-21-0@openssl.org>

Hi folks,

Check return value of EC_POINT_mul in VKO_compute_key.. Add an err
label when bailing out. A question remains however: shouldn't the



function itself (VKO_compute_key) have a way to check returned values
instead of returning 32.

Diff here:

http://elandsys.com/~logan/opensssl_483285.diff

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Sat Jun 20 19:34:01 2015
From: rt at openssl.org (bug-reporting0000@cneufeld.ca via RT)
Date: Sat, 20 Jun 2015 19:34:01 +0000
Subject: [openssl-dev] [openssl.org #3905] AutoReply: Bug report:
	segfault while cleaning up in libgost
In-Reply-To: <201506201933.t5KJXfLO005803@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
 <rt-4.0.19-12424-1434142231-1971.3905-3-0@openssl.org>
 <201506201933.t5KJXfLO005803@cneufeld.ca>
Message-ID: <rt-4.0.19-8352-1434828840-31.3905-6-0@openssl.org>

Just to finish off this thread, I've got a small patch that aims to prevent
issues with parallel builds.

Now, the openssl Makefile hides the $(MAKE) variable in another variable
expansion, which means that the jobserver can't tell that there are
submakes in the subdir rules, so those submakes are invoked with -j1,
meaning that each subdirectory itself is serially compiled.  However, the
toplevel Makefile as it exists in 1.0.2b allows the parallel invocation of
several of these submakes.  So, running "make -j8" will invoke a serial
compilation in each of the directories crypto, ssl, engines, apps, test,
and tools.  The problem is that some of these subdirectories call back to
the toplevel and ask it to build one of the other directories.  So, for
instance, engines depends on crypto, but rather than making the dependency
explicit in the toplevel Makefile, engines calls its own make on the
../crypto directory.  Now you've got two independent makes running in
crypto, and havoc ensues.


This patch puts in some dependencies on the subdirectory builds and
prevents them from interfering with one another in this way when parallel
makes are run.  Note that it does not allow "make -j <NUM>" to build in
parallel, because of the issue I mentioned above relating to the $(MAKE)
variable, it simply prevents an imprudent -j invocation from corrupting the
build and producing bad libraries.


--- openssl-1.0.2b/Makefile.org 2015-06-11 09:50:11.000000000 -0400
+++ openssl-1.0.2b.PATCHED/Makefile.org 2015-06-20 15:24:44.000000000 -0400
@@ -280,11 +280,11 @@
        @dir=crypto; target=all; $(BUILD_ONE_CMD)
 build_ssl:
        @dir=ssl; target=all; $(BUILD_ONE_CMD)
-build_engines:
+build_engines: build_crypto
        @dir=engines; target=all; $(BUILD_ONE_CMD)
-build_apps:
+build_apps: build_crypto build_ssl build_engines
        @dir=apps; target=all; $(BUILD_ONE_CMD)
-build_tests:
+build_tests: build_crypto build_ssl
        @dir=test; target=all; $(BUILD_ONE_CMD)
 build_tools:
        @dir=tools; target=all; $(BUILD_ONE_CMD)


-- 
 Christopher Neufeld
 Home page:  http://www.cneufeld.ca/neufeld
 "Don't edit reality for the sake of simplicity"



From rt at openssl.org  Sat Jun 20 20:59:44 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Sat, 20 Jun 2015 20:59:44 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <201506121905.t5CJ5TJN030362@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
Message-ID: <rt-4.0.19-8352-1434833984-924.3905-6-0@openssl.org>

Can you take a look at Makefile.org on master? I think it has these all these
changes, so we could just backport it.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From mehdisotoodeh at gmail.com  Sat Jun 20 23:24:43 2015
From: mehdisotoodeh at gmail.com (Mehdi Sotoodeh)
Date: Sat, 20 Jun 2015 16:24:43 -0700
Subject: [openssl-dev] curve25519
Message-ID: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>

I have developed a compact library capable of curve25519-DH as well as
ed25519 keygen, sign and verify. It is hosted at:
https://github.com/msotoodeh/curve25519

This library is very fast (looks like it is the fastest) while it is based
on a very portable C code.

Major features of this library include:

* Microsoft and GNU assembly for X86_64 platforms.
* Constant-time (partially) and blinding support for side channel security.
* FOLDING: a new technique that speeds up the point multiplication by a
factor of 4.
* MIT license.

I am looking to find a good home for this code. Is OpenSSL a good fit?


Thanks,
Mehdi Sotoodeh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150620/690ad4e6/attachment-0001.html>

From rt at openssl.org  Sat Jun 20 23:57:58 2015
From: rt at openssl.org (bug-reporting0000@cneufeld.ca via RT)
Date: Sat, 20 Jun 2015 23:57:58 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <201506202357.t5KNvi30015888@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
 <rt-4.0.19-8352-1434833984-924.3905-6-0@openssl.org>
 <201506202357.t5KNvi30015888@cneufeld.ca>
Message-ID: <rt-4.0.19-6035-1434844678-397.3905-6-0@openssl.org>

On Sat, 20 Jun 2015 20:59:44 +0000, Rich Salz via RT <rt at openssl.org> said:

> Can you take a look at Makefile.org on master? I think it has these all
> these changes, so we could just backport it.

I've checked.  Master has similar changes.  The only functional difference
between the version in git and the version in the patch I posted is that
the version in git makes build_ssl dependent on build_crypto, I somehow
missed that dependency in my testing.

The git fixes are in master, but not in either of the tags for 1.0.2b or
1.0.2c.


-- 
 Christopher Neufeld
 Home page:  http://www.cneufeld.ca/neufeld
 "Don't edit reality for the sake of simplicity"



From aaronmdjones at gmail.com  Sun Jun 21 14:53:50 2015
From: aaronmdjones at gmail.com (Aaron Jones)
Date: Sun, 21 Jun 2015 14:53:50 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
Message-ID: <5586CFFE.9030501@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 20/06/15 23:24, Mehdi Sotoodeh wrote:
> [...] Major features of this library include: [...] *
> Constant-time (partially) and blinding support for side channel
> security.

I really have to question the wisdom of adding implementations
of Curve25519 and/or Ed25519 that are not completely constant-
time.

The almost entire design goal was to produce a scheme that does
not perform branches on secret data (branch predictor timing
attack), load from secret addresses (cache timing attack), etc
etc.

Adding blinding support only serves to (attempt to) correct the
mistake of introducing timing attacks in the first place.

- -- 
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVhs/vAAoJEG6FTA+q1M6kTb4QALX1F9I1mOiddk1OoyVDRuC3
CsFWNl9WJiPCBipW3YIwi4QfZhrOgLBWajaTXfkZ3+hvOFBzJDouciIOi/dYe2sI
Evs2Dfa4d6C1KzZ3VpMP/EFbHPuuEXvE+KY4qZd1aoVrPYsbLNBrAK/swAkmOJ4b
zKGB+jUi1hziwYLB/fDCcozPVzN57F3SAd6MSSPaSDm7iADdrK9N0OvtNJsl/KF4
GoYLrSNwbUjEfFV0bI+IjHxK8r2GLX/0t/d1LrEazjeiIpOtUB4mVKZwFMjmPrhZ
63CVZVutpPOxfl5WXzpEY5armoF+vT/Z1ZZFD3jzdu2tspJ5OuLEGH+mwiI0EEJV
eF6zPmhlUrmO9RxtRgTNBuYhXp3U+/lOihfrSA0jxpdr2+xFpVDk2i4S+dp5Hq7y
7bRSRHHCfzvziTjF34wANctCz6UWKKCn6Uw4QXgDaLkVcU4PQtwPtrMWXZdcpuH5
iEL0v8IHreLiA6Jgf8uuZErzNm9iKDoE8F676l+ep8Uze2TR6zGRDVanl7tfeW34
Lgh+gissiF289Sv/7InxKD+tA3/k7qA8MjL8gt5XEqV1HvXCR5HxL+R6sm7rrLh9
CsfnLtkewBNxmGGnCaYRP7lTW2MQJXmbtejhJH0pu9loX/MTddZuiErIgwZWnchF
YXeYK6jV4IpnzflfXrnX
=qRQd
-----END PGP SIGNATURE-----

From rsalz at akamai.com  Sun Jun 21 16:54:58 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 21 Jun 2015 16:54:58 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <5586CFFE.9030501@gmail.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
Message-ID: <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>


> I really have to question the wisdom of adding implementations of
> Curve25519 and/or Ed25519 that are not completely constant- time.

It's unlikely to happen.



From beldmit at gmail.com  Sun Jun 21 16:59:47 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sun, 21 Jun 2015 19:59:47 +0300
Subject: [openssl-dev] curve25519
In-Reply-To: <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>

Hello Rich,

On Sun, Jun 21, 2015 at 7:54 PM, Salz, Rich <rsalz at akamai.com> wrote:

>
> > I really have to question the wisdom of adding implementations of
> > Curve25519 and/or Ed25519 that are not completely constant- time.
>
> It's unlikely to happen.
>
>
BTW, is there any tool for checking C code whether it is constant-time?

Thank you!


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/46380afe/attachment.html>

From mehdisotoodeh at gmail.com  Sun Jun 21 17:05:53 2015
From: mehdisotoodeh at gmail.com (Mehdi Sotoodeh)
Date: Sun, 21 Jun 2015 10:05:53 -0700
Subject: [openssl-dev] curve25519
In-Reply-To: <5586CFFE.9030501@gmail.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
Message-ID: <CANgBTQQV9qdkSWuDWgmczGVdm4jt-3dFFfL56EhLuDKjOTTZSg@mail.gmail.com>

Hi Aaron,
Did you look at the text regarding side channel security on the front page?
It is located towards the end of page and I think you missed it.
My reasoning is the fact that the goal of constant time is not achievable
by software only approaches. A lot depends on the underlying hardware.

Thanks
mehdi.

On Sun, Jun 21, 2015 at 7:53 AM, Aaron Jones <aaronmdjones at gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 20/06/15 23:24, Mehdi Sotoodeh wrote:
> > [...] Major features of this library include: [...] *
> > Constant-time (partially) and blinding support for side channel
> > security.
>
> I really have to question the wisdom of adding implementations
> of Curve25519 and/or Ed25519 that are not completely constant-
> time.
>
> The almost entire design goal was to produce a scheme that does
> not perform branches on secret data (branch predictor timing
> attack), load from secret addresses (cache timing attack), etc
> etc.
>
> Adding blinding support only serves to (attempt to) correct the
> mistake of introducing timing attacks in the first place.
>
> - --
> Aaron Jones
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJVhs/vAAoJEG6FTA+q1M6kTb4QALX1F9I1mOiddk1OoyVDRuC3
> CsFWNl9WJiPCBipW3YIwi4QfZhrOgLBWajaTXfkZ3+hvOFBzJDouciIOi/dYe2sI
> Evs2Dfa4d6C1KzZ3VpMP/EFbHPuuEXvE+KY4qZd1aoVrPYsbLNBrAK/swAkmOJ4b
> zKGB+jUi1hziwYLB/fDCcozPVzN57F3SAd6MSSPaSDm7iADdrK9N0OvtNJsl/KF4
> GoYLrSNwbUjEfFV0bI+IjHxK8r2GLX/0t/d1LrEazjeiIpOtUB4mVKZwFMjmPrhZ
> 63CVZVutpPOxfl5WXzpEY5armoF+vT/Z1ZZFD3jzdu2tspJ5OuLEGH+mwiI0EEJV
> eF6zPmhlUrmO9RxtRgTNBuYhXp3U+/lOihfrSA0jxpdr2+xFpVDk2i4S+dp5Hq7y
> 7bRSRHHCfzvziTjF34wANctCz6UWKKCn6Uw4QXgDaLkVcU4PQtwPtrMWXZdcpuH5
> iEL0v8IHreLiA6Jgf8uuZErzNm9iKDoE8F676l+ep8Uze2TR6zGRDVanl7tfeW34
> Lgh+gissiF289Sv/7InxKD+tA3/k7qA8MjL8gt5XEqV1HvXCR5HxL+R6sm7rrLh9
> CsfnLtkewBNxmGGnCaYRP7lTW2MQJXmbtejhJH0pu9loX/MTddZuiErIgwZWnchF
> YXeYK6jV4IpnzflfXrnX
> =qRQd
> -----END PGP SIGNATURE-----
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/8f6624c5/attachment.html>

From rsalz at akamai.com  Sun Jun 21 17:10:48 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 21 Jun 2015 17:10:48 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
Message-ID: <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>

> BTW, is there any tool for checking C code whether it is constant-time?

I'm not aware of any.  The body of information about it, for C, is slowly starting to emerge.  There was some talk about an IETF draft on techniques, but I don't recall seeing it yet.

The big thing is "avoid data-dependant jumps."  For example, memcmp() always runs the full length, almost any "if" statement needs careful scrutiny, and so on.  In openssl master, look at include/internal/constat_time_locl.h and test/constant_time_test.c

(PS:  What does SY stand for; "see you"? :)


From openssl-users at dukhovni.org  Sun Jun 21 17:14:50 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 21 Jun 2015 17:14:50 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150621171450.GE14121@mournblade.imrryr.org>

On Sun, Jun 21, 2015 at 05:10:48PM +0000, Salz, Rich wrote:

> The big thing is "avoid data-dependant jumps.

Not only data-dependent branches, but also data-dependent memory
access patterns.  Both the sequence of instrucutions executed and
the sequence of memory addresses accessed must not depend on either
data or keys.

-- 
	Viktor.

From sneves at dei.uc.pt  Sun Jun 21 17:27:15 2015
From: sneves at dei.uc.pt (Samuel Neves)
Date: Sun, 21 Jun 2015 18:27:15 +0100
Subject: [openssl-dev] curve25519
In-Reply-To: <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <5586F3F3.1080300@dei.uc.pt>

On 21-06-2015 18:10, Salz, Rich wrote:
> The big thing is "avoid data-dependant jumps."  For example, memcmp() always runs the full length, almost any "if" statement needs careful scrutiny, and so on. 

Case in point: https://github.com/msotoodeh/curve25519/blob/master/source/curve25519_dh.c#L108-145

This high-key-bit leak is only saved by X25519's insistence on setting the highest bit to 1 on every secret key. See
https://eprint.iacr.org/2011/232 for a case without such safeguards.

From rsalz at akamai.com  Sun Jun 21 17:33:30 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 21 Jun 2015 17:33:30 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <5586F3F3.1080300@dei.uc.pt>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <5586F3F3.1080300@dei.uc.pt>
Message-ID: <bb52e6f1bcfc48a1aa77c286f8e6b0d7@ustx2ex-dag1mb2.msg.corp.akamai.com>


> This high-key-bit leak is only saved by X25519's insistence on setting the
> highest bit to 1 on every secret key.

This is not a coincidence.  Djb was the first, and is still one of the few, cryptographers who think about it from a full systems approach and design things so that proper implementation is relatively easy.

From rt at openssl.org  Sun Jun 21 19:00:55 2015
From: rt at openssl.org (Giuseppe D'Angelo via RT)
Date: Sun, 21 Jun 2015 19:00:55 +0000
Subject: [openssl-dev] [openssl.org #2464] TLS-RSA-PSK support
In-Reply-To: <558707EA.8090703@kdab.com>
References: <RT-Ticket-2464@openssl.org> <558707EA.8090703@kdab.com>
Message-ID: <rt-4.0.19-14079-1434913255-332.2464-6-0@openssl.org>

Yet another version after some refactorings that landed in master.

Please, pretty please, with sugar on top, could anyone review this code 
so that it can get merged?

It's becoming a difficult exercise to keep track of upstream changes and 
adapt the patch every single time...

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Introduce-TLS-RSA-PSK-support.patch
Type: text/x-patch
Size: 32719 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/745fcf72/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/745fcf72/attachment-0003.bin>

From rt at openssl.org  Sun Jun 21 19:28:50 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 21 Jun 2015 19:28:50 +0000
Subject: [openssl-dev] [openssl.org #3905] Bug report: segfault while
	cleaning up in libgost
In-Reply-To: <201506121905.t5CJ5TJN030362@cneufeld.ca>
References: <RT-Ticket-3905@openssl.org>
 <201506121905.t5CJ5TJN030362@cneufeld.ca>
Message-ID: <rt-4.0.19-13926-1434914930-1831.3905-6-0@openssl.org>

Cherry-picked to 1.0.2 and 1.0.1; thanks.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Sun Jun 21 21:55:51 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Sun, 21 Jun 2015 21:55:51 +0000
Subject: [openssl-dev] [openssl.org #3917] Bug report -- potential memory
	leak
In-Reply-To: <e93221e7796d424c976b6a5058f8dd7c@EX13-CZ-02.cz.avg.com>
References: <RT-Ticket-3917@openssl.org>
 <e93221e7796d424c976b6a5058f8dd7c@EX13-CZ-02.cz.avg.com>
Message-ID: <rt-4.0.19-13926-1434923751-617.3917-6-0@openssl.org>

OpenSSL_1_0_2-stable 4475451 RT3917: add cleanup on an error path
master 7fba840 RT3917: add cleanup on an error path

Author: Rich Salz <rsalz at akamai.com>
Date: Sun Jun 21 15:37:53 2015 -0400

RT3917: add cleanup on an error path

Reviewed-by: Richard Levitte <levitte at openssl.org>

--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From mehdisotoodeh at gmail.com  Sun Jun 21 21:56:32 2015
From: mehdisotoodeh at gmail.com (Mehdi Sotoodeh)
Date: Sun, 21 Jun 2015 14:56:32 -0700
Subject: [openssl-dev] curve25519
In-Reply-To: <bb52e6f1bcfc48a1aa77c286f8e6b0d7@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <5586F3F3.1080300@dei.uc.pt>
 <bb52e6f1bcfc48a1aa77c286f8e6b0d7@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CANgBTQSnpXjr2BgYBZ603TdMqFJ-xzo8oJKFQ_TpXdWxbcOdeA@mail.gmail.com>

Does anyone have any comment on my reasoning regarding the constant time?

Here is the text:

Side Channel Security:
----------------------
This library uses multiple measures with the gaol of eliminating leakage of
secret
keys during cryptographic operations. Constant-time is one of these
measures and
is implemented for private keys when they are directly operated on (no
conditional
operation based on key values).
The second and more effective measure that this library uses is blinding.
Blinding
hides the private keys by combining them with a random value.

This is a fact that constant-time implementation does not necessarily
translate to
constant-power-consumption, constant-electro-magnetic-radiation and so on.
It also
depends on how the underlying hardware manipulates different circuitry for
each
operation. For example, a hardware multiplier may use the primitive
technique of
shift-and-conditional-add or it may use barrel shifter when multiplying a
power of
2 number.

Blinding is the more effective measure with less performance penalty.
Constant-time alone, pushes attackers to dig deeper for clues.


On Sun, Jun 21, 2015 at 10:33 AM, Salz, Rich <rsalz at akamai.com> wrote:

>
> > This high-key-bit leak is only saved by X25519's insistence on setting
> the
> > highest bit to 1 on every secret key.
>
> This is not a coincidence.  Djb was the first, and is still one of the
> few, cryptographers who think about it from a full systems approach and
> design things so that proper implementation is relatively easy.
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/1c6d2748/attachment.html>

From rsalz at akamai.com  Sun Jun 21 22:00:33 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 21 Jun 2015 22:00:33 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <CANgBTQSnpXjr2BgYBZ603TdMqFJ-xzo8oJKFQ_TpXdWxbcOdeA@mail.gmail.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <5586F3F3.1080300@dei.uc.pt>
 <bb52e6f1bcfc48a1aa77c286f8e6b0d7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CANgBTQSnpXjr2BgYBZ603TdMqFJ-xzo8oJKFQ_TpXdWxbcOdeA@mail.gmail.com>
Message-ID: <c2a0e9b0bce3493f99cf6ed36f53ffa5@ustx2ex-dag1mb2.msg.corp.akamai.com>

Your analysis is incorrect for servers over the Internet, where the only thing that an attacker can measure is time.  Power and radiation require close proximity and, often, physical intervention. Those are reasonable attacks to have in the threat model, but comes after timing considerations.


--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/0360b1bd/attachment.html>

From rt at openssl.org  Sun Jun 21 22:14:38 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Sun, 21 Jun 2015 22:14:38 +0000
Subject: [openssl-dev] [openssl.org #3919] ssl.h uses ALL in its default
	cipher list
In-Reply-To: <CAH8yC8nxVO_ayuT1i6wduNxa+ZNqdGt3ANbAjVZ54oFvo9t67A@mail.gmail.com>
References: <RT-Ticket-3919@openssl.org>
 <CAH8yC8nxVO_ayuT1i6wduNxa+ZNqdGt3ANbAjVZ54oFvo9t67A@mail.gmail.com>
Message-ID: <rt-4.0.19-13926-1434924878-667.3919-21-0@openssl.org>

The following is from ssl.h, around line 285:

    /*
     * The following cipher list is used by default. It also is substituted when
     * an application-defined cipher list string starts with 'DEFAULT'.
     */
    # define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL"

Its 2015, and its probably best to change that to something like:

    # define SSL_DEFAULT_CIPHER_LIST "HIGH:!aNULL:!eNULL"

Or:

    # define SSL_DEFAULT_CIPHER_LIST "HIGH:!aNULL:!eNULL:!RC4:!MD5"

I personally have less of a problem with MD5 in this context because
the HMAC must be broken in 2-MSL, and many/most attackers cannot do
it. But its a compliance thing....

Also, browser are now warning about outputted cryptography, that
includes the LOW and MEDIUM stuff (and RC4 and MD5). For example, see
http://security.stackexchange.com/q/83831 and
http://stackoverflow.com/q/30270788. So anything using OpenSSL with
those settings could cause problems for unsuspecting users.

The change also means the library is more secure out of the box, and
easier to use correctly and harder to use incorrectly.

For those who want Opportunistic Security
(http://tools.ietf.org/html/rfc7435), they can use different settings
that suite their taste.

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From cuoq at trust-in-soft.com  Sun Jun 21 22:36:30 2015
From: cuoq at trust-in-soft.com (Pascal Cuoq)
Date: Sun, 21 Jun 2015 22:36:30 +0000
Subject: [openssl-dev] curve25519
In-Reply-To: <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>,
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
Message-ID: <9e60ce4089ea45769e366f55287379e2@S1688.EX1688.lan>

Dmitry Belyavsky <beldmit at gmail.com> wrote:

> BTW, is there any tool for checking C code whether it is constant-time?

Short answer:

No tools that are useful for usable implementations of asymmetric cryptography, that I know of, but useful tools for confirming that symmetric cryptography designed for constant-time implementation was correctly implemented.

Long answer:

The C standards says nothing about execution time;  the 600+ pages of the latest (C11) one only describe the functional effects of defined C programs. But if you are willing to assume that your knowledge about the time taken by assembly instructions is correct, you can check that the execution time of a piece of assembly code does not depend on secrets (at least the dependencies of instructions' outputs with respects to their inputs is well documented and understood, so it is possible to know which of the inputs of the sequence an intermediate value depends on; what isn't documented is what inputs of an instruction can influence the execution time of that instruction). If you are willing to add the assumption that the C compiler translates a program line by line to the straightforward corresponding assembly, it is theoretically possible to check the same property for C code.

Following this line of reasoning gives you two tools that you can use:

- ctgrind, by agl, based on Valgrind.
https://github.com/agl/ctgrind
https://www.imperialviolet.org/2010/04/01/ctgrind.html
 Valgrind works at the binary level but you just assumed that compilation from C to binary was straightforward. ctgrind checks that the secrets are not used in the computation of addresses or in conditionals along one execution path. The property that it provides is more general than it looks, because since it checks that execution does not depend on the secrets in this way, you can infer that if the secrets had been different, the same property would have held. However, using ctgrind once only provides a guarantee for the particular values of non-secret inputs that were used. In this context, key length and message length are non-secret inputs, so if you checked with ctgrind that execution time did not depend on secrets for key length=512, that doesn't mean it's also the case for key length=1024, and if you check that a message of length 64 is encoded in ?constant time? by a symmetric cipher, that does not prove that a message of length 65 is.

- experimental options of the existing Frama-C dependency plug-in:
http://blog.frama-c.com/index.php?post/2011/12/31/Do-not-use-AES-in-a-context-where-timing-attacks-are-possible
I wrote these (the full story is in the blog post, no point in repeating it here). This works on C, which in this case is a drawback (it means that you have no choice but to assume that the C compiler translates a program line by line to the straightforward corresponding assembly, which is not true of existing compilers and will only become more untrue as time passes.

There are two problems with both these approaches:

- the assumption about knowledge about the time taken by assembly instructions. Both Frama-C and, to the best of my knowledge, ctgrind, ignore intermediate values computed from secrets and passed as arguments to the division instruction. On a modern processor the execution time of division reveals information about its inputs:
http://users.elis.ugent.be/~brdsutte/research/publications/2012TACOvancleemput.pdf (?Compiler Mitigations for Time Attacks on Modern x86 Processors?). There is no theoretical difficulty in adding division as an instruction that both tools watch for, but currently, they don't watch for it.
Another example: shift is usually constant-time nowadays, but its execution time used to depend on its second input, and this could still be the case on a processor designed for low consumption
Another example: cmov takes constant time on current processors, but in the next generation of Intel processors, cmovcc mem, reg will be faster when the condition is false (joke: I do not actually know that, but there is no official commitment on the part of Intel that would disprove it, either).
Another example: it is possible to conceive a memory dependence speculation system in which reading at address A after a secret-dependent value has been written at address A is faster if the value that was written turned out to be identical to the value that was previously at address A:
http://stackoverflow.com/a/29949891/139746
So to summarize the first problem, there are a lot of assumptions. That doesn't prevent going forward, and taking any new discovery of an information leak through timing as a bug and fixing them as flaws are discovered in our assumptions, but you won't be ?checking? that C code is ?constant-time? in the sense that you might check the proof of a theorem. But even more serious is the second problem:

- no current implementation of asymmetric cryptography primitives for a general-purpose processor without special support would be fast enough to be used if it was written to be constant-time according to the above criteria.
The above methods work fine to check that the implementor did not mess up the implementation of a symmetric cipher that was designed to be implemented as ?constant-time?. But implementations of asymmetric cryptography intended for real use, in OpenSSL or elsewhere, when they try to be ?constant-time?, do not absolutely avoid dereferencing addresses computed from secrets. Instead they lay out the data to access so that, with low-level assumptions about cache line sizes and the internals of modern processors, the time taken to access a group of addresses computed from secrets take the same time for all values of the secrets. You could call it a false positive of the tools ctgrind and Frama-C, but the end result is that you cannot use these tools to check that your usable asymmetric cryptography implementation is constant-time, because they will tell you that it's not. Also you should bear in mind that when implementing cache-aware constant-time look-up tables, you are really assuming a lot of things about the behavior of the processor.
By the same token, ctgrind and Frama-C will tell you that the third solution in the blog post below, ?[AES implemented with] a single 256-bytes S-box?, has execution time that depends on secrets, because it fails their criterion although it was designed so that the amount of information was so low as to be (probably) impossible to exploit.
https://securityblog.redhat.com/2014/07/02/its-all-a-question-of-time-aes-timing-attacks-on-openssl/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/0642c5f7/attachment-0001.html>

From naynjain at in.ibm.com  Sun Jun 21 22:42:29 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Mon, 22 Jun 2015 04:12:29 +0530
Subject: [openssl-dev] X509_verify() error -  block type is not 01
Message-ID: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>


Hi,

I am trying to verify X509 certificate against two private keys such that
atleast one of them it should match.
I used the API as

X509_verify(x509, pkey) where pkey is of EVP_PKEY type

However, for one of the private key it is failing with error "block type is
not 01"    // And this key is supposed to be matching the certificate.

and for other key it is failing with error "padding check failed"

Can someone help me to understand these errors and how to fix, even though
when I know the key with "block type error" does matches the certificate.


Thanks & Regards,
Nayna Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150622/f7c88ff8/attachment.html>

From kudzu at tenebras.com  Sun Jun 21 23:03:06 2015
From: kudzu at tenebras.com (Michael Sierchio)
Date: Sun, 21 Jun 2015 16:03:06 -0700
Subject: [openssl-dev] curve25519
In-Reply-To: <c2a0e9b0bce3493f99cf6ed36f53ffa5@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <c68f39cd76d541279a68eb1b96471bd8@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <5586F3F3.1080300@dei.uc.pt>
 <bb52e6f1bcfc48a1aa77c286f8e6b0d7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CANgBTQSnpXjr2BgYBZ603TdMqFJ-xzo8oJKFQ_TpXdWxbcOdeA@mail.gmail.com>
 <c2a0e9b0bce3493f99cf6ed36f53ffa5@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAHu1Y70icatxvM5tC+OG1Sd8SycQpeveSh7DTjiyMVCOgVYiug@mail.gmail.com>

On Sun, Jun 21, 2015 at 3:00 PM, Salz, Rich <rsalz at akamai.com> wrote:

 Your analysis is incorrect for servers over the Internet, where the only
> thing that an attacker can measure is time.  Power and radiation require
> close proximity and, often, physical intervention. Those are reasonable
> attacks to have in the threat model, but comes after timing considerations.
>

Timing attacks, as Rich notes, can be done remotely.  Power and radiant
energy measurements are infeasible in the case of remote servers, esp. in
the case of EC2 instances.  The right design goal was adopted in the case
of curve25519 - as you would expect of Dan Bernstein.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150621/7c897264/attachment.html>

From openssl-users at dukhovni.org  Mon Jun 22 02:08:07 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Jun 2015 02:08:07 +0000
Subject: [openssl-dev] [openssl-users] X509_verify() error - block type
	is not 01
In-Reply-To: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>
References: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>
Message-ID: <20150622020807.GG14121@mournblade.imrryr.org>

On Mon, Jun 22, 2015 at 04:12:29AM +0530, Nayna Jain wrote:

> I am trying to verify X509 certificate against two private keys such that
> atleast one of them it should match.

What do you mean by "match"?  Was either key used to sign the
certificate, or is one of the keys the public key of the subject?

> X509_verify(x509, pkey) where pkey is of EVP_PKEY type

This checks whether the key signed the certificate.

-- 
	Viktor.

From naynjain at in.ibm.com  Mon Jun 22 02:26:37 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Mon, 22 Jun 2015 07:56:37 +0530
Subject: [openssl-dev] [openssl-users] X509_verify() error - block
 type	is not 01
In-Reply-To: <20150622020807.GG14121@mournblade.imrryr.org>
References: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>
 <20150622020807.GG14121@mournblade.imrryr.org>
Message-ID: <OFBEBD8C27.56F3B1CB-ON65257E6C.000D4876-65257E6C.000D69A0@in.ibm.com>


Thanks Victor,

I want to match the certificate with the private key for whose public key
that certificate is provided.

If this verifies who signed the certificate, then how do I verify whether
the certificate provided is for the private key which was generated,

Thanks & Regards,
Nayna Jain



From:	Viktor Dukhovni <openssl-users at dukhovni.org>
To:	openssl-users at openssl.org, openssl-dev at openssl.org
Date:	06/22/2015 07:39 AM
Subject:	Re: [openssl-dev] [openssl-users] X509_verify() error - block
            type	is not 01
Sent by:	"openssl-dev" <openssl-dev-bounces at openssl.org>



On Mon, Jun 22, 2015 at 04:12:29AM +0530, Nayna Jain wrote:

> I am trying to verify X509 certificate against two private keys such that
> atleast one of them it should match.

What do you mean by "match"?  Was either key used to sign the
certificate, or is one of the keys the public key of the subject?

> X509_verify(x509, pkey) where pkey is of EVP_PKEY type

This checks whether the key signed the certificate.

--
		 Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150622/e2a91cfb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150622/e2a91cfb/attachment.gif>

From openssl-users at dukhovni.org  Mon Jun 22 02:29:52 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Jun 2015 02:29:52 +0000
Subject: [openssl-dev] [openssl-users] X509_verify() error - block
	type	is not 01
In-Reply-To: <OFBEBD8C27.56F3B1CB-ON65257E6C.000D4876-65257E6C.000D69A0@in.ibm.com>
References: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>
 <20150622020807.GG14121@mournblade.imrryr.org>
 <OFBEBD8C27.56F3B1CB-ON65257E6C.000D4876-65257E6C.000D69A0@in.ibm.com>
Message-ID: <20150622022951.GH14121@mournblade.imrryr.org>

On Mon, Jun 22, 2015 at 07:56:37AM +0530, Nayna Jain wrote:

> I want to match the certificate with the private key for whose public key
> that certificate is provided.

That's the subject key, and unless the certificate is self-signed,
the X509_verify() function is not the right interface.  You want
to extract the certificate's public key and compare it with the
key you have.  You can compare (memcmp()) the DER encoding of 
the public key from the certificate with the DER encoding of
the desired key.

> If this verifies who signed the certificate, then how do I verify whether
> the certificate provided is for the private key which was generated,

You compare the keys, or the key fingerprints.

-- 
	Viktor.

From naynjain at in.ibm.com  Mon Jun 22 03:27:08 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Mon, 22 Jun 2015 08:57:08 +0530
Subject: [openssl-dev] [openssl-users] X509_verify() error -
 block	type	is not 01
In-Reply-To: <20150622022951.GH14121@mournblade.imrryr.org>
References: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>
 <20150622020807.GG14121@mournblade.imrryr.org>
 <OFBEBD8C27.56F3B1CB-ON65257E6C.000D4876-65257E6C.000D69A0@in.ibm.com>
 <20150622022951.GH14121@mournblade.imrryr.org>
Message-ID: <OF84D6BDAA.472BB077-ON65257E6C.0012C511-65257E6C.0012F445@in.ibm.com>


OK.. I think I understood this API wrongly then.

What will X509_verify() will verify if I pass it public key.

I mean in place of private key , if I try to match the public key than
rather than doing keys comparision, will passing the public key to this
API, help ?

I mean does it check the private key with which certificate was signed, or
the public key which this certificate signs.

Sorry, I think I am still bit not clear on purpose of the API.

Thanks & Regards,
Nayna Jain



From:	Viktor Dukhovni <openssl-users at dukhovni.org>
To:	openssl-users at openssl.org, openssl-dev at openssl.org
Date:	06/22/2015 08:00 AM
Subject:	Re: [openssl-dev] [openssl-users] X509_verify() error - block
            type	is not 01
Sent by:	"openssl-dev" <openssl-dev-bounces at openssl.org>



On Mon, Jun 22, 2015 at 07:56:37AM +0530, Nayna Jain wrote:

> I want to match the certificate with the private key for whose public key
> that certificate is provided.

That's the subject key, and unless the certificate is self-signed,
the X509_verify() function is not the right interface.  You want
to extract the certificate's public key and compare it with the
key you have.  You can compare (memcmp()) the DER encoding of
the public key from the certificate with the DER encoding of
the desired key.

> If this verifies who signed the certificate, then how do I verify whether
> the certificate provided is for the private key which was generated,

You compare the keys, or the key fingerprints.

--
		 Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150622/204524f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150622/204524f4/attachment-0001.gif>

From openssl-users at dukhovni.org  Mon Jun 22 03:31:39 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Jun 2015 03:31:39 +0000
Subject: [openssl-dev] [openssl-users] X509_verify() error -
	block	type	is not 01
In-Reply-To: <OF84D6BDAA.472BB077-ON65257E6C.0012C511-65257E6C.0012F445@in.ibm.com>
References: <OF7B8A7613.C3B6E87D-ON65257E6B.007C7F60-65257E6B.007CBAC6@in.ibm.com>
 <20150622020807.GG14121@mournblade.imrryr.org>
 <OFBEBD8C27.56F3B1CB-ON65257E6C.000D4876-65257E6C.000D69A0@in.ibm.com>
 <20150622022951.GH14121@mournblade.imrryr.org>
 <OF84D6BDAA.472BB077-ON65257E6C.0012C511-65257E6C.0012F445@in.ibm.com>
Message-ID: <20150622033139.GI14121@mournblade.imrryr.org>

On Mon, Jun 22, 2015 at 08:57:08AM +0530, Nayna Jain wrote:

> What will X509_verify() will verify if I pass it public key.

It checks the signature of the certificate using the supplied key.

> I mean does it check the private key with which certificate was signed, or
> the public key which this certificate signs.

It checks whether the given key *signed* the certificate.  It does
not examine the key in the certificate (the subject public key).

> Sorry, I think I am still bit not clear on purpose of the API.

X509_verify() verifies the certificate signature via the issuer
public key.

-- 
	Viktor.

From Matthias.St.Pierre at ncp-e.com  Mon Jun 22 11:11:07 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Mon, 22 Jun 2015 13:11:07 +0200
Subject: [openssl-dev] Comments on the new ECDSA_METHOD_*() and
	RSA_METHOD_*() APIs
Message-ID: <5587ED4B.2060601@ncp-e.com>


Hello,

first of all, I'd like to say that I agree with the core developers that it's a good idea to make
all these OpenSSL structs opaque and provide an API for creation/desruction and member access instead.

I have two comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs in particular,
and a general question concerning the *_METHOD_*() API in general.


1) The ECDSA_METHOD_*() api is not const correct: the "copy constructor" and the name setter
   are lacking a 'const' in the last argument.
   
     ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_meth)
     void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name)   

   Instead, I should be 

     ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_meth)
     void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name)

   I have prepared a patch fixing the const-correctness, which I'll post to the request tracker.
   
   It would be nice if the change could be added to the 1.0.2 stable branch. Although it's a header change
   it would not break the ABI and force no recompilation of existing code, as far as I understand it,
   since there is no name decoration in C. This opion was also shared by Rich Salz recently:

   Re: [openssl-dev] Missing API features
   On 04/20/2015 10:25 PM, Salz, Rich wrote:>
   > Changing the return type here should be binary compatible on any sane platform, but it might cause source incompatibilities.


   I think it would be better to correct the error right away, before people start working around it
   by casting away the const's in their code.
   
 

2) A corresponding RSA_METHOD_*() api is still completely missing (even on master) and the 'struct rsa_meth_st'
   members are still publicly visible.

   Are there any plans to add it in the near future? 



3) Looking at the set of exported functions in util/libeay.num, one sees that the *_METHOD_*() API is still
   rather rudimentary. Are there any plans to change this?

   util/libeay.num:
     DSO_METHOD_null                         2270    EXIST::FUNCTION:
     DSO_METHOD_openssl                      2271    EXIST::FUNCTION:
     DSO_METHOD_dlfcn                        2272    EXIST::FUNCTION:
     DSO_METHOD_win32                        2273    EXIST::FUNCTION:
     DSO_METHOD_dl                           2275    EXIST::FUNCTION:
     DSO_METHOD_vms                          2462    EXIST::FUNCTION:
     EC_METHOD_get_field_type                3528    EXIST::FUNCTION:EC
     DSO_METHOD_beos                         4122    NOEXIST::FUNCTION:
     X509_CRL_METHOD_free                    4241    EXIST::FUNCTION:
     X509_CRL_METHOD_new                     4371    EXIST::FUNCTION:
     ECDSA_METHOD_set_name                   4723    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_flags                  4726    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_sign_setup             4727    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_sign                   4733    EXIST::FUNCTION:EC
     ECDSA_METHOD_new                        4751    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_verify                 4755    EXIST::FUNCTION:EC
     ECDSA_METHOD_free                       4759    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_app_data               4768    EXIST::FUNCTION:EC
     ECDSA_METHOD_get_app_data               4770    EXIST::FUNCTION:EC


From nico at cryptonector.com  Mon Jun 22 17:37:42 2015
From: nico at cryptonector.com (Nico Williams)
Date: Mon, 22 Jun 2015 12:37:42 -0500
Subject: [openssl-dev] curve25519
In-Reply-To: <9e60ce4089ea45769e366f55287379e2@S1688.EX1688.lan>
References: <CANgBTQRa1icGYMMU06-seEmKrhoyN6YH3Va9dZDkV-mgj6qUDQ@mail.gmail.com>
 <5586CFFE.9030501@gmail.com>
 <c02eb68e3ce34a73bbb201e77df6920c@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CADqLbzKLYk08WWUQb9+DJp-nNA7fwF5eUeHayCn_YPyCrzbO8g@mail.gmail.com>
 <9e60ce4089ea45769e366f55287379e2@S1688.EX1688.lan>
Message-ID: <20150622173740.GL6117@localhost>

On Sun, Jun 21, 2015 at 10:36:30PM +0000, Pascal Cuoq wrote:
> Short answer:
> 
> No tools that are useful for usable implementations of asymmetric
> cryptography, that I know of, but useful tools for confirming that
> symmetric cryptography designed for constant-time implementation was
> correctly implemented.
> 
> Long answer:
> 
> [...]
> 
> Following this line of reasoning gives you two tools that you can use:
>
> [...]
> 
> There are two problems with both these approaches:
> 
> - the assumption about knowledge about the time taken by assembly
> instructions. Both Frama-C and, to the best of my knowledge, ctgrind,
> ignore intermediate values computed from secrets and passed as
> arguments to the division instruction. On a modern processor the
> execution time of division reveals information about its inputs:

That's correct.

Reasoning about CT is hard, and doing so from C source is harder because
the optimizer can potentially convert CT code to not-CT code.

This argues for analyzing assembly, not C.

> So to summarize the first problem, there are a lot of assumptions.
> That doesn't prevent going forward, and taking any new discovery of an
> information leak through timing as a bug and fixing them as flaws are
> discovered in our assumptions, but you won't be ?checking? that C code
> is ?constant-time? in the sense that you might check the proof of a
> theorem. But even more serious is the second problem:
> [...]
>                                                      [...]. Also you
> should bear in mind that when implementing cache-aware constant-time
> look-up tables, you are really assuming a lot of things about the
> behavior of the processor.  [...]

At some point one is forced to dispense with -or, rather, augment-
static analysis with dynamic analysis.

The beauty of dynamic analysis is that it really short-circuits all of
these considerations and gives you an answer you can trust.  But one
does have to make sure to eliminate sources of jitter (e.g., quiesce the
system, disable interrupts on the CPU doing the benchmarking, ...).  If
one is able to trace execution to pinpoint sources of variability, then
dynamic analysis can even point out where secrets leak into timing.

Nico
-- 

From rt at openssl.org  Mon Jun 22 19:17:21 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 22 Jun 2015 19:17:21 +0000
Subject: [openssl-dev] [openssl.org #3570] [DOC] ciphers(1) documentation
In-Reply-To: <A31CC7AA43A1B748AC06B6ADC61837DD1F2B93A0@WPHXMAIL1.phx.axway.int>
References: <RT-Ticket-3570@openssl.org>
 <A31CC7AA43A1B748AC06B6ADC61837DD1F2B93A0@WPHXMAIL1.phx.axway.int>
Message-ID: <rt-4.0.19-5561-1435000641-1695.3570-6-0@openssl.org>

Fixed in master with some other doc/typo fixes with commit
4c583c36596cd86feebd983b0313733fe9870500
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Mon Jun 22 19:17:43 2015
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Mon, 22 Jun 2015 19:17:43 +0000
Subject: [openssl-dev] [openssl.org #3920] ECDSA_METHOD_new() argument
	should be constified?
In-Reply-To: <CADqLbzK7eATtNTtCVas_ffKW+twQsi81FCmO858d-hOTfeLRag@mail.gmail.com>
References: <RT-Ticket-3920@openssl.org>
 <CADqLbzK7eATtNTtCVas_ffKW+twQsi81FCmO858d-hOTfeLRag@mail.gmail.com>
Message-ID: <rt-4.0.19-5560-1435000663-850.3920-21-0@openssl.org>

Hello all,

I try to provide my own ECDSA method using engine. I want to use common
functions for verifying the signature and a custom one for signing.

My code is

...
  const ECDSA_METHOD * meth1 = ECDSA_OpenSSL();
  forwarder_ec_method = ECDSA_METHOD_new(meth1);
...

Compiling it, I get an error:

error: passing argument 1 of ?ECDSA_METHOD_new? discards ?const? qualifier
from pointer target type [-Werror]

Shouldn't the argument of the ECDSA_METHOD_new() function be const struct
ECDSA_METHOD * instead of struct ECDSA_METHOD *?

Thank you!

-- 
SY, Dmitry Belyavsky

-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From rt at openssl.org  Mon Jun 22 19:51:40 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 22 Jun 2015 19:51:40 +0000
Subject: [openssl-dev] [openssl.org #3907] Script testssl uses bash feature
	(non-POSIX)
In-Reply-To: <557BEFB2.7010007@kippdata.de>
References: <RT-Ticket-3907@openssl.org> <557BEFB2.7010007@kippdata.de>
Message-ID: <rt-4.0.19-5560-1435002700-1216.3907-6-0@openssl.org>

OpenSSL_1_0_1-stable 9ad2eb6 RT3907: avoid "local" in testssl script
OpenSSL_1_0_2-stable 57bd71b RT3907: avoid "local" in testssl script
master 75ba5c5 RT3907: avoid "local" in testssl script

Author: Rich Salz <rsalz at akamai.com>
Date: Sat Jun 13 17:18:47 2015 -0400

RT3907: avoid "local" in testssl script

Reviewed-by: Richard Levitte <levitte at openssl.org>

--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Mon Jun 22 20:07:43 2015
From: rt at openssl.org (Dr. Matthias St. Pierre via RT)
Date: Mon, 22 Jun 2015 20:07:43 +0000
Subject: [openssl-dev] [openssl.org #3921] [PATCH] Fix const-correctness
	issues of new ECDSA_METHOD api
In-Reply-To: <1434971453-8175-1-git-send-email-Matthias.St.Pierre@ncp-e.com>
References: <RT-Ticket-3921@openssl.org>
 <1434971453-8175-1-git-send-email-Matthias.St.Pierre@ncp-e.com>
Message-ID: <rt-4.0.19-5561-1435003663-25.3921-21-0@openssl.org>

- The function ECDSA_METHOD_new() acts like a copy constructor, but unfortunately
  its argument is not declared const. This leads to compiler errors when it is
  used as follows:

    ECDSA_METHOD * method = ECDSA_METHOD_new(ECDSA_OpenSSL());

- The ECDSA_METHOD_set_name() should take a 'const char *' instead of a 'char *',
  because that's the type of the ecdsa_method 'name' member.
---
 crypto/ecdsa/ecdsa.h   | 4 ++--
 crypto/ecdsa/ecs_lib.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/crypto/ecdsa/ecdsa.h b/crypto/ecdsa/ecdsa.h
index c4016ac..d31cebc 100644
--- a/crypto/ecdsa/ecdsa.h
+++ b/crypto/ecdsa/ecdsa.h
@@ -233,7 +233,7 @@ void *ECDSA_get_ex_data(EC_KEY *d, int idx);
  *  \return pointer to a ECDSA_METHOD structure or NULL if an error occurred
  */
 
-ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_method);
+ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_method);
 
 /** frees a ECDSA_METHOD structure
  *  \param  ecdsa_method  pointer to the ECDSA_METHOD structure
@@ -295,7 +295,7 @@ void ECDSA_METHOD_set_flags(ECDSA_METHOD *ecdsa_method, int flags);
  *   \param  flags flags value to set
  */
 
-void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name);
+void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name);
 
 /**  Set the name field in the ECDSA_METHOD
  *   \param  ecdsa_method  pointer to existing ECDSA_METHOD
diff --git a/crypto/ecdsa/ecs_lib.c b/crypto/ecdsa/ecs_lib.c
index 1c02310..05dab09 100644
--- a/crypto/ecdsa/ecs_lib.c
+++ b/crypto/ecdsa/ecs_lib.c
@@ -276,7 +276,7 @@ void *ECDSA_get_ex_data(EC_KEY *d, int idx)
     return (CRYPTO_get_ex_data(&ecdsa->ex_data, idx));
 }
 
-ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_meth)
+ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_meth)
 {
     ECDSA_METHOD *ret;
 
@@ -332,7 +332,7 @@ void ECDSA_METHOD_set_flags(ECDSA_METHOD *ecdsa_method, int flags)
     ecdsa_method->flags = flags | ECDSA_METHOD_FLAG_ALLOCATED;
 }
 
-void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name)
+void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name)
 {
     ecdsa_method->name = name;
 }
-- 
2.3.6

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Mon Jun 22 20:07:43 2015
From: rt at openssl.org (David von Oheimb via RT)
Date: Mon, 22 Jun 2015 20:07:43 +0000
Subject: [openssl-dev] [openssl.org #3922] Bug: EVP_get_digestbynid() does
	not support ECDSA
In-Reply-To: <5587E336.4030209@siemens.com>
References: <RT-Ticket-3922@openssl.org> <5587E336.4030209@siemens.com>
Message-ID: <rt-4.0.19-5561-1435003663-1240.3922-21-0@openssl.org>

Hi OpenSSL maintainers,

I tried checking the status of the EVP_get_digestbynid issue via
http://rt.openssl.org/Install/index.html
but the server appears currently misconfigured:
> Config file /etc/request-tracker4/RT_SiteConfig.pm is locked 

Yet I found an old conversation on this topic:
http://openssl.6102.n7.nabble.com/Question-about-EVP-get-digestbynid-and-ECDSA-td28312.html

With OpenSSL 1.0.2 one still gets NULL when giving ECDSA NIDs as input.
Here is the workaround we currently use for EC support in CMPforOpenSSL:

> const EVP_MD *extended_EVP_get_digestbynid(int nid) {
> 	  switch (nid) {
> 	  case  NID_ecdsa_with_SHA1:
> 	      return EVP_sha1();
> 	  case  NID_ecdsa_with_SHA224:
> 	      return EVP_sha224();
> 	  case  NID_ecdsa_with_SHA256:
> 	      return EVP_sha256();
> 	  case  NID_ecdsa_with_SHA384:
> 	      return EVP_sha384();
> 	  case  NID_ecdsa_with_SHA512:
> 	      return EVP_sha512();
> 	  default:
> 	      return EVP_get_digestbynid(nid);
> 	}
> }

I just commented on this issue also at
https://sourceforge.net/p/cmpforopenssl/bugs/14/

Regards,
	David

--
+------------------------------------------------------------------<><-+
|  Dr. David von Oheimb        Senior Key Expert Research Scientist    |
|  Siemens CT RTC ITS SEA-DE   Phone: +49 89 636 41173                 |
|  Otto-Hahn-Ring 6            Fax  : +49 89 636 48000                 |
|  D-81739 M?nchen, Germany    EMail: David.von.Oheimb at siemens.com     |
|  http://scd.siemens.de/db4/lookUp?tcgid=Z000ECRO   http://ddvo.net/  |
+----------------------------------------------------------------------+

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From levitte at openssl.org  Mon Jun 22 20:14:21 2015
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 22 Jun 2015 22:14:21 +0200 (CEST)
Subject: [openssl-dev] RT was down today, please resend
Message-ID: <20150622.221421.538175214323483934.levitte@openssl.org>

Hi,

due to a mysql screwup, whatever was sent to openssl-bugs at openssl.org
after 06:00 UTC today was lost (everything before that was safely
backed up).  If you did send something, I would like to kindly ask you
to resend it.

Sorry for the inconvenience.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rt at openssl.org  Mon Jun 22 21:14:37 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 22 Jun 2015 21:14:37 +0000
Subject: [openssl-dev] [openssl.org #2464] [PATCH] Experimental TLS-RSA-PSK
	support for OpenSSL
In-Reply-To: <rt-4.0.19-14079-1434913255-1172.2464-6-0@openssl.org>
References: <RT-Ticket-2464@openssl.org> <558707EA.8090703@kdab.com>
 <rt-4.0.19-14079-1434913255-1172.2464-6-0@openssl.org>
Message-ID: <rt-4.0.19-5560-1435007677-660.2464-6-0@openssl.org>

On Sun Jun 21 19:00:55 2015, giuseppe.dangelo at kdab.com wrote:
> Yet another version after some refactorings that landed in master.
>
> Please, pretty please, with sugar on top, could anyone review this code
> so that it can get merged?
>
> It's becoming a difficult exercise to keep track of upstream changes and
> adapt the patch every single time...
>

I'm currently looking at the OpenSSL PSK code. I'll look into incopoorating
your changes (in a modified form) as part of that so there is no need to keep
it up to date with the changing master branch.

I hope to revise the PSK code and make it more flexible so it can support
{RSA,DH,ECDH}+PSK more cleanly.

FYI, I can tell you the cause of the GCM crash: the cipher structure isn't set
up correctly in your patch, it needs to use SSL_AEAD not SSL_SHA256 (compare it
with other GCM entries).

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From rainer.jung at kippdata.de  Mon Jun 22 21:20:57 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Mon, 22 Jun 2015 23:20:57 +0200
Subject: [openssl-dev] [openssl-commits] [openssl] master update
In-Reply-To: <1435002581.169693.1777.nullmailer@dev.openssl.org>
References: <1435002581.169693.1777.nullmailer@dev.openssl.org>
Message-ID: <55887C39.10709@kippdata.de>

Am 22.06.2015 um 21:49 schrieb Rich Salz:
> The branch master has been updated
>         via  75ba5c58c6b3b3326a6c3198100830afa120e7c3 (commit)
>        from  389ebcecae2575188a4ff9566389ce694352be43 (commit)
>
>
> - Log -----------------------------------------------------------------
> commit 75ba5c58c6b3b3326a6c3198100830afa120e7c3
> Author: Rich Salz <rsalz at akamai.com>
> Date:   Sat Jun 13 17:18:47 2015 -0400
>
>      RT3907: avoid "local" in testssl script
>
>      Reviewed-by: Richard Levitte <levitte at openssl.org>
>
> -----------------------------------------------------------------------
>
> Summary of changes:
>   test/testssl | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/test/testssl b/test/testssl
> index 7e834a7..cb8e56a 100644
> --- a/test/testssl
> +++ b/test/testssl
> @@ -118,11 +118,10 @@ echo test sslv2/sslv3 with both client and server authentication via BIO pair an
>   $ssltest -bio_pair -server_auth -client_auth -app_verify $CA $extra || exit 1
>
>   test_cipher() {
> -  local cipher=$1
> -  local protocol=$2
> +    _cipher=$1

It seems "_cipher" is never used and instead the function still uses 
"cipher" (which is the variable which is set elsewhere before calling 
the function "test_cipher").

>       echo "Testing $cipher"
>       prot=""
> -    if [ $protocol = "SSLv3" ] ; then
> +    if [ $2 = "SSLv3" ] ; then
>         prot="-ssl3"
>       fi
>       $ssltest -cipher $cipher $prot

Regards,

Rainer

From rsalz at akamai.com  Mon Jun 22 21:24:56 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Jun 2015 21:24:56 +0000
Subject: [openssl-dev] [openssl-commits] [openssl] master update
In-Reply-To: <55887C39.10709@kippdata.de>
References: <1435002581.169693.1777.nullmailer@dev.openssl.org>
 <55887C39.10709@kippdata.de>
Message-ID: <ce60a6ec77b04383965aca6996df6d1a@ustx2ex-dag1mb4.msg.corp.akamai.com>

Rats.  Looked at the wrong build output ;(  thanks.  Will fix shortly.



From simplesec2012 at gmail.com  Tue Jun 23 01:51:48 2015
From: simplesec2012 at gmail.com ((( \/\/|||"'""/'")) ((\"""" )) (( ))\\\"\\"\)
Date: Mon, 22 Jun 2015 22:51:48 -0300
Subject: [openssl-dev] OpenSSL Non blocking SSL_read() ?
Message-ID: <CAHx8p8khkAy0Qimbu3TCLYjBVv26iq6bucGu2g-sGNDkZBmygQ@mail.gmail.com>

Currently in my OpenSSL client, when I am reading data from the ssl socket,
my client will always call SSL_read() until the terminator is found to be
as the last bytes of the received data. This works well but I don't think
it's the proper way.

while (1)
 {
            if (!rc)
            {
                rc = malloc (readSize + 1);

            }
            else
            {
                ReallocSize = (count + 1) * (readSize + 1);
                rc = realloc (rc, ReallocSize);
            }

            received = SSL_read (c->sslHandle, buffer, readSize);

            if (received <= 0)
            {
                printf(" received equal to or less than 0\n");
                switch (SSL_get_error(c->sslHandle, r))
                {
                case SSL_ERROR_NONE:
                    printf("SSL_ERROR_NONE\n");
                    break;
                case SSL_ERROR_ZERO_RETURN:
                    printf("SSL_ERROR_ZERO_RETURN\n");
                    break;
                case SSL_ERROR_WANT_READ:
                    printf("SSL_ERROR_WANT_READ\n");
                    break;
                default:
                    printf("error happens %i\n", r);
                }
                break;
            }

          if (TerminatorFound)
              break;

            count++;
        }

Here is how I am establishing the connection:

c->socket = tcpConnect ();
  if (c->socket)
    {
      // Register the error strings for libcrypto & libssl
      SSL_load_error_strings ();
      // Register the available ciphers and digests
      SSL_library_init ();

      // New context saying we are a client, and using SSL 2 or 3
      c->sslContext = SSL_CTX_new (SSLv23_client_method ());
      if (c->sslContext == NULL)
        ERR_print_errors_fp (stderr);

      // Create an SSL struct for the connection
      c->sslHandle = SSL_new (c->sslContext);
      if (c->sslHandle == NULL)
        ERR_print_errors_fp (stderr);

      // Connect the SSL struct to our connection
      if (!SSL_set_fd (c->sslHandle, c->socket))
        ERR_print_errors_fp (stderr);

      // Initiate SSL handshake
      if (SSL_connect (c->sslHandle) != 1)
        ERR_print_errors_fp (stderr);
    }
  else
    {
      perror ("Connect failed");
    }

Also, SSL_pending() always returns 0, even if there is data to be read from
the socket.

My goal is to know if there is data to be read without resorting to a
terminating character.

If there is no data, then the call to SSL_read will hang. What function
must I call so that SSL_read will return and not hang? This way I can tell
if data is there without having to look in the response for a terminating
character.

Thank you for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150622/82b07f99/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Tue Jun 23 08:40:52 2015
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 23 Jun 2015 10:40:52 +0200
Subject: [openssl-dev] [openssl.org #3920] ECDSA_METHOD_new() argument
 should be constified?
In-Reply-To: <rt-4.0.19-5560-1435000663-850.3920-21-0@openssl.org>
References: <RT-Ticket-3920@openssl.org>
 <CADqLbzK7eATtNTtCVas_ffKW+twQsi81FCmO858d-hOTfeLRag@mail.gmail.com>
 <rt-4.0.19-5560-1435000663-850.3920-21-0@openssl.org>
Message-ID: <55891B94.5080105@ncp-e.com>

On 06/22/2015 09:17 PM, Dmitry Belyavsky via RT wrote:
> Hello all,
> 
> I try to provide my own ECDSA method using engine. I want to use common
> functions for verifying the signature and a custom one for signing.
> 
> My code is
> 
> ...
>   const ECDSA_METHOD * meth1 = ECDSA_OpenSSL();
>   forwarder_ec_method = ECDSA_METHOD_new(meth1);
> ...
> 
> Compiling it, I get an error:
> 
> error: passing argument 1 of ?ECDSA_METHOD_new? discards ?const? qualifier
> from pointer target type [-Werror]
> 
> Shouldn't the argument of the ECDSA_METHOD_new() function be const struct
> ECDSA_METHOD * instead of struct ECDSA_METHOD *?


Just happened to submit a patch fixing two const-correctness issues of the ECDSA_METHOD api
almost simultaneously to your post, see [openssl.org #3921]

Regards,
MSP

From rt at openssl.org  Tue Jun 23 09:27:28 2015
From: rt at openssl.org (Tomasz Sawicki via RT)
Date: Tue, 23 Jun 2015 09:27:28 +0000
Subject: [openssl-dev] [openssl.org #3923] PKCS12_parse leaks meaningless
	error from X509_check_private_key
In-Reply-To: <55890AD8.5060709@gmail.com>
References: <RT-Ticket-3923@openssl.org> <55890AD8.5060709@gmail.com>
Message-ID: <rt-4.0.19-9024-1435051648-939.3923-21-0@openssl.org>

Hi,

PKCS12_parse uses X509_check_private_key to distinguish the certificate 
which matches the private key from extra certificates. When extra 
certificates are checked first, X509_check_private_key puts 
X509_R_KEY_VALUES_MISMATCH error on error stack which is not cleared by 
PKCS12_parse and can trigger weird behaviour in libraries using 
PKCS12_parse.

Bad effect seen in PHP bug #69882[1].

[1] https://bugs.php.net/bug.php?id=69882

-- 
Tomasz Sawicki

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Tue Jun 23 12:05:30 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 23 Jun 2015 12:05:30 +0000
Subject: [openssl-dev] [openssl.org #3856] [PATCH] Fix memory leaks in test
	code
In-Reply-To: <1432223660-30551-1-git-send-email-russell.webb@intel.com>
References: <RT-Ticket-3856@openssl.org>
 <1432223660-30551-1-git-send-email-russell.webb@intel.com>
Message-ID: <rt-4.0.19-9052-1435061130-303.3856-6-0@openssl.org>

Fixed in master and 1.0.2; thanks!
OpenSSL_1_0_2-stable 295c629 RT3856: Fix memory leaks in test code
master 2d54040 RT3856: Fix memory leaks in test code

Author: Russell Webb <russell.webb at intel.com>
Date: Sat Jun 13 10:35:55 2015 -0400

RT3856: Fix memory leaks in test code

Reviewed-by: Matt Caswell <matt at openssl.org>


--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Tue Jun 23 12:16:24 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 23 Jun 2015 12:16:24 +0000
Subject: [openssl-dev] [openssl.org #3682] [PATCH] Fix double free in
	ocsp_main()
In-Reply-To: <CADujJWUYvp9bB14XckHJisxZ-wZBZDgH-WXr+3rhwWfBmHR+Kg@mail.gmail.com>
References: <RT-Ticket-3682@openssl.org>
 <CADujJWUYvp9bB14XckHJisxZ-wZBZDgH-WXr+3rhwWfBmHR+Kg@mail.gmail.com>
Message-ID: <rt-4.0.19-10320-1435061784-1669.3682-6-0@openssl.org>

fixed in master and 1.0.2 by adding "thost = tport = tpath = NULL;"
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Tue Jun 23 17:05:26 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 23 Jun 2015 17:05:26 +0000
Subject: [openssl-dev] [openssl.org #3922] Bug: EVP_get_digestbynid() does
	not support ECDSA
In-Reply-To: <5587E336.4030209@siemens.com>
References: <RT-Ticket-3922@openssl.org> <5587E336.4030209@siemens.com>
Message-ID: <rt-4.0.19-10602-1435079126-307.3922-6-0@openssl.org>

On Mon Jun 22 20:07:43 2015, David.von.Oheimb at siemens.com wrote:
> Hi OpenSSL maintainers,
>
> I tried checking the status of the EVP_get_digestbynid issue via
> http://rt.openssl.org/Install/index.html
> but the server appears currently misconfigured:
> > Config file /etc/request-tracker4/RT_SiteConfig.pm is locked
>
> Yet I found an old conversation on this topic:
> http://openssl.6102.n7.nabble.com/Question-about-EVP-get-digestbynid-
> and-ECDSA-td28312.html
>
> With OpenSSL 1.0.2 one still gets NULL when giving ECDSA NIDs as
> input.
> Here is the workaround we currently use for EC support in
> CMPforOpenSSL:
>

That's expected behaviour. The EVP_get_digestbynid funtion expects a digest NID
whereas you are passing a signature NID instead. It does accept some signature
NIDs for historical compatibility reasons.

The thread you mention shows you how to convert a signature NID into the digest
and public key algorithm NID.

However I suspect you shouldn't be trying to do things at that level for
signatures. If you need to sign or verify ASN.1 data you can use ASN1_item_sign
or ASN1_item_verify and key and digest handling and lookup is handled
automatically.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From rt at openssl.org  Tue Jun 23 20:09:36 2015
From: rt at openssl.org (Giuseppe D'Angelo via RT)
Date: Tue, 23 Jun 2015 20:09:36 +0000
Subject: [openssl-dev] [openssl.org #2464] [PATCH] Experimental
	TLS-RSA-PSK support for OpenSSL
In-Reply-To: <5589BCEF.2080709@kdab.com>
References: <RT-Ticket-2464@openssl.org> <558707EA.8090703@kdab.com>
 <rt-4.0.19-14079-1434913255-1172.2464-6-0@openssl.org>
 <rt-4.0.19-5560-1435007677-660.2464-6-0@openssl.org>
 <5589BCEF.2080709@kdab.com>
Message-ID: <rt-4.0.19-10320-1435090176-517.2464-6-0@openssl.org>

Il 22/06/2015 23:14, Stephen Henson via RT ha scritto:
> On Sun Jun 21 19:00:55 2015, giuseppe.dangelo at kdab.com wrote:
>> Yet another version after some refactorings that landed in master.
>>
>> Please, pretty please, with sugar on top, could anyone review this code
>> so that it can get merged?
>>
>> It's becoming a difficult exercise to keep track of upstream changes and
>> adapt the patch every single time...
>>
>
> I'm currently looking at the OpenSSL PSK code. I'll look into incopoorating
> your changes (in a modified form) as part of that so there is no need to keep
> it up to date with the changing master branch.

Great, thank you! If you have questions on the implementation just ask. 
It should me mostly straightforward with the RFC at hand, with a small 
section copied as-is from the plain RSA code.

> I hope to revise the PSK code and make it more flexible so it can support
> {RSA,DH,ECDH}+PSK more cleanly.
>
> FYI, I can tell you the cause of the GCM crash: the cipher structure isn't set
> up correctly in your patch, it needs to use SSL_AEAD not SSL_SHA256 (compare it
> with other GCM entries).

A-ha! That explains the silly mistake, thank you.

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150623/bb85b561/attachment.bin>

From giuseppe.dangelo at kdab.com  Tue Jun 23 20:09:19 2015
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Tue, 23 Jun 2015 22:09:19 +0200
Subject: [openssl-dev] [openssl.org #2464] [PATCH] Experimental
 TLS-RSA-PSK support for OpenSSL
In-Reply-To: <rt-4.0.19-5560-1435007677-660.2464-6-0@openssl.org>
References: <RT-Ticket-2464@openssl.org> <558707EA.8090703@kdab.com>
 <rt-4.0.19-14079-1434913255-1172.2464-6-0@openssl.org>
 <rt-4.0.19-5560-1435007677-660.2464-6-0@openssl.org>
Message-ID: <5589BCEF.2080709@kdab.com>

Il 22/06/2015 23:14, Stephen Henson via RT ha scritto:
> On Sun Jun 21 19:00:55 2015, giuseppe.dangelo at kdab.com wrote:
>> Yet another version after some refactorings that landed in master.
>>
>> Please, pretty please, with sugar on top, could anyone review this code
>> so that it can get merged?
>>
>> It's becoming a difficult exercise to keep track of upstream changes and
>> adapt the patch every single time...
>>
>
> I'm currently looking at the OpenSSL PSK code. I'll look into incopoorating
> your changes (in a modified form) as part of that so there is no need to keep
> it up to date with the changing master branch.

Great, thank you! If you have questions on the implementation just ask. 
It should me mostly straightforward with the RFC at hand, with a small 
section copied as-is from the plain RSA code.

> I hope to revise the PSK code and make it more flexible so it can support
> {RSA,DH,ECDH}+PSK more cleanly.
>
> FYI, I can tell you the cause of the GCM crash: the cipher structure isn't set
> up correctly in your patch, it needs to use SSL_AEAD not SSL_SHA256 (compare it
> with other GCM entries).

A-ha! That explains the silly mistake, thank you.

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: Firma crittografica S/MIME
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150623/bdf3d157/attachment.bin>

From sms at antinode.info  Wed Jun 24 03:30:34 2015
From: sms at antinode.info (Steven M. Schweda)
Date: Tue, 23 Jun 2015 22:30:34 -0500 (CDT)
Subject: [openssl-dev] OpenSSL on VMS v. HP -- SSLROOT v. SSL$ROOT (et al.)
Message-ID: <15062322303486_20200496@antinode.info>

   As a distraction from modern, important subjects, I offer the
following.

   For a long time, HP has distributed a modified version of OpenSSL for
VMS as "HP SSL" (most recently version V1.4-502, based (loosely?) on
0.9.8ze).

      http://h71000.www7.hp.com/openvms/security.html
      http://h71000.www7.hp.com/openvms/products/ssl/ssl.html    [Broken]
      http://h71000.www7.hp.com/openvms/products/ssl/ssl_doc.html
      http://h71000.www7.hp.com/openvms/products/ssl/ssl_source.html

   The set-up DCL script for the normal OpenSSL kit on VMS defines some
logical names, which point to particular directories.  For example:

  "OPENSSL" = "SSLINCLUDE:"
  "SSLCERTS" = "sslroot:[certs]"
  "SSLEXE" = "sslroot:[ALPHA_exe]"
  "SSLINCLUDE" = "sslroot:[include]"
  "SSLLIB" = "sslroot:[ALPHA_lib]"
  "SSLPRIVATE" = "sslroot:[private]"
  "SSLROOT" = "ALP$DKC100:[UTILITY.SOURCE.OPENSSL.1_0_1I.]"

   The HP-supplied kit uses similar logical names, but with a dollar
sign (which character is supposed to be reserved to HP).  For example:

  "OPENSSL" = "SSL$INCLUDE:"
  "SSL$CERT" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$CERTS" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$COM" = "SSL$ROOT:[COM]"
  "SSL$CONF" = "SSL$ROOT:[DEMOCA.CONF]"
  "SSL$CRL" = "SSL$ROOT:[DEMOCA.CRL]"
  "SSL$EXAMPLES" = "SYS$COMMON:[SYSHLP.EXAMPLES.SSL]"
  "SSL$EXE" = "SSL$ROOT:[Alpha_EXE]"
  "SSL$INCLUDE" = "SSL$ROOT:[INCLUDE]"
  "SSL$KEY" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$KEYS" = "SSL$ROOT:[DEMOCA.CERTS]"
  "SSL$PRIVATE" = "SSL$ROOT:[DEMOCA.PRIVATE]"
  "SSL$ROOT" = "SYS$SYSDEVICE:[VMS$COMMON.SSL.]"

   This would all be harmless, except that dollar-free names like
"SSLCERTS", "SSLPRIVATE", and "SSLROOT" are baked into the source code
(crypto/cryptlib.h and crypto/engine/eng_list.c), and the folks at HP
seem not to have noticed this.  One result of this oversight is that a
typical application, like, say, Wget, when built using the HP SSL kit,
can fail at run time when it can't find the OpenSSL configuration file
(because the HP SSL DCL set-up script defines "SSL$ROOT", not
"SSLROOT").  For example:

REX $ mcr [-.SRC.IA64L]wget --no-check-certificate https://google.com
--2015-06-22 14:16:13--  https://google.com/
Auto configuration failed
551552061:error:02001006:system library:fopen:no such device or address:BSS_FILE
:126:fopen('SSLROOT:[000000]openssl.cnf','r')
551552061:error:2006D002:BIO routines:BIO_new_file:system lib:BSS_FILE:131:
551552061:error:0E078002:configuration file routines:DEF_LOAD:system lib:CONF_DE
F:199:

   There's a simple work-around (not documented anywhere):
      DEFINE SSLROOT SSL$ROOT
(and perhaps similar commands for the other names, if needed), but it
might make some sense if the two relevant source files could be told to
use the alternate names.  For example, in crypto/cryptlib.h, instead of:

      #define X509_CERT_AREA          "SSLROOT:[000000]"
      #define X509_CERT_DIR           "SSLCERTS:"
      #define X509_CERT_FILE          "SSLCERTS:cert.pem"
      #define X509_PRIVATE_DIR        "SSLPRIVATE:"

perhaps:

      #ifdef VMS_VENDOR
      # define X509_CERT_AREA         "SSL$ROOT:[000000]"
      # define X509_CERT_DIR          "SSL$CERTS:"
      # define X509_CERT_FILE         "SSL$CERTS:cert.pem"
      # define X509_PRIVATE_DIR       "SSL$PRIVATE:"
      #else
      # define X509_CERT_AREA         "SSLROOT:[000000]"
      # define X509_CERT_DIR          "SSLCERTS:"
      # define X509_CERT_FILE         "SSLCERTS:cert.pem"
      # define X509_PRIVATE_DIR       "SSLPRIVATE:"
      #endif

with something similar in crypto/engine/eng_list.c, like, say:

      #ifdef OPENSSL_SYS_VMS
      # ifdef VMS_VENDOR
      #  define VMS_ENGINES "SSL$ROOT:[ENGINES]"
      # else
      #  define VMS_ENGINES "SSLROOT:[ENGINES]"
      # endif
          if((load_dir = getenv("OPENSSL_ENGINES")) == 0)
           load_dir = VMS_ENGINES;
      #else

   On their own, these changes would not fix anything, but they would
make it relatively easy for HP (or their inheritors) to build the stuff
with the alternate (vendor-preferred) logical names baked in instead of
the normal ones.  At which point it would still be all their fault, but
at least we tried.

   Ideally, I claim, the file/path names with these logical-name
components would be defined at some higher level in the source tree,
where they'd be obvious and easy to change (instead of in the
subterranean files where they're found now), but I don't know where a
good spot would be.  If someone who knows more than I (almost anyone)
has a better organizational plan, then it'd most likely be ok with me,
but I'd settle for a little fiddling in the caves, as suggested above.

   As always, thanks for your consideration.

------------------------------------------------------------------------

   Steven M. Schweda               sms at antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547

From rt at openssl.org  Wed Jun 24 10:21:35 2015
From: rt at openssl.org (Dr. Matthias St. Pierre via RT)
Date: Wed, 24 Jun 2015 10:21:35 +0000
Subject: [openssl-dev] [openssl.org #3925] [PATCH] Removed trailing
	semicolon from macro body of three function-like macros
In-Reply-To: <1435136894-11007-1-git-send-email-Matthias.St.Pierre@ncp-e.com>
References: <RT-Ticket-3925@openssl.org>
 <1435136894-11007-1-git-send-email-Matthias.St.Pierre@ncp-e.com>
Message-ID: <rt-4.0.19-1697-1435141294-1342.3925-21-0@openssl.org>

The trailing semicolon turned the macros into statements and prevented
them from being used in arbitrary expressions.
---
 include/openssl/bio.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/openssl/bio.h b/include/openssl/bio.h
index 7fe88ec..12f59ac 100644
--- a/include/openssl/bio.h
+++ b/include/openssl/bio.h
@@ -540,11 +540,11 @@ int BIO_read_filename(BIO *b, const char *name);
 # define BIO_get_ssl(b,sslp)     BIO_ctrl(b,BIO_C_GET_SSL,0,(char *)sslp)
 # define BIO_set_ssl_mode(b,client)      BIO_ctrl(b,BIO_C_SSL_MODE,client,NULL)
 # define BIO_set_ssl_renegotiate_bytes(b,num) \
-        BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_BYTES,num,NULL);
+        BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_BYTES,num,NULL)
 # define BIO_get_num_renegotiates(b) \
-        BIO_ctrl(b,BIO_C_GET_SSL_NUM_RENEGOTIATES,0,NULL);
+        BIO_ctrl(b,BIO_C_GET_SSL_NUM_RENEGOTIATES,0,NULL)
 # define BIO_set_ssl_renegotiate_timeout(b,seconds) \
-        BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_TIMEOUT,seconds,NULL);
+        BIO_ctrl(b,BIO_C_SET_SSL_RENEGOTIATE_TIMEOUT,seconds,NULL)
 
 /* defined in evp.h */
 /* #define BIO_set_md(b,md)     BIO_ctrl(b,BIO_C_SET_MD,1,(char *)md) */
-- 
2.3.6

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Wed Jun 24 10:21:32 2015
From: rt at openssl.org (Dinesh Yegireddi -X via RT)
Date: Wed, 24 Jun 2015 10:21:32 +0000
Subject: [openssl-dev] [openssl.org #3924] Unable to compile OpenSSL 1.0.0s
	with no-tlsext option
In-Reply-To: <AB3502F483AF1F4696D828B026435F6910E5910F@xmb-rcd-x08.cisco.com>
References: <RT-Ticket-3924@openssl.org>
 <AB3502F483AF1F4696D828B026435F6910E5910F@xmb-rcd-x08.cisco.com>
Message-ID: <rt-4.0.19-1696-1435141292-142.3924-21-0@openssl.org>

Hi There,

I tried to compile OpenSSL 1.0.0s with no-tlsext option and got the following compilation error.

ssl_sess.c: In function 'ssl_session_dup':
ssl_sess.c:257: error: 'SSL_SESSION' has no member named 'tlsext_tick'
ssl_sess.c:324: error: 'SSL_SESSION' has no member named 'tlsext_tick'
ssl_sess.c:324: error: 'SSL_SESSION' has no member named 'tlsext_tick'
ssl_sess.c:324: error: 'SSL_SESSION' has no member named 'tlsext_ticklen'
ssl_sess.c:325: error: 'SSL_SESSION' has no member named 'tlsext_tick'
ssl_sess.c:328: error: 'SSL_SESSION' has no member named 'tlsext_tick_lifetime_hint'
ssl_sess.c:329: error: 'SSL_SESSION' has no member named 'tlsext_ticklen'
make[1]: *** [ssl_sess.o] Error 1
make[1]: Leaving directory `/root/openssl-1.0.0s/ssl'
make: *** [build_ssl] Error 1
[root at SSL-LINUX-SERVER-POD5 openssl-1.0.0s]#

Below were the steps followed for compilation.

[root at SSL-LINUX-SERVER-POD5 openssl-1.0.0s]# ./config no-tlsext

-----------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------
Since you've disabled or enabled at least one algorithm, you need to do
the following before building:

        make depend

Configured for linux-x86_64.
[root at SSL-LINUX-SERVER-POD5 openssl-1.0.0s]# make depend

-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
[root at SSL-LINUX-SERVER-POD5 openssl-1.0.0s]# make


I overcome it with below patch

[root at SSL-LINUX-SERVER-POD5 ~]# diff -crB openssl-1.0.0s/ssl/ssl_sess.c openssl-1.0.0s_changed/ssl/ssl_sess.c > openssl.patch
[root at SSL-LINUX-SERVER-POD5 ~]# cat openssl.patch
*** openssl-1.0.0s/ssl/ssl_sess.c       2015-06-11 07:10:15.000000000 -0700
--- openssl-1.0.0s_changed/ssl/ssl_sess.c       2015-06-24 02:39:53.000000000 -0700
***************
*** 253,260 ****
      dest->tlsext_ecpointformatlist = NULL;
      dest->tlsext_ellipticcurvelist = NULL;
  # endif
- #endif
      dest->tlsext_tick = NULL;
      memset(&dest->ex_data, 0, sizeof(dest->ex_data));

      /* We deliberately don't copy the prev and next pointers */
--- 253,260 ----
      dest->tlsext_ecpointformatlist = NULL;
      dest->tlsext_ellipticcurvelist = NULL;
  # endif
      dest->tlsext_tick = NULL;
+ #endif
      memset(&dest->ex_data, 0, sizeof(dest->ex_data));

      /* We deliberately don't copy the prev and next pointers */
***************
*** 318,324 ****
              goto err;
      }
  # endif
- #endif

      if (ticket != 0) {
          dest->tlsext_tick = BUF_memdup(src->tlsext_tick, src->tlsext_ticklen);
--- 318,323 ----
***************
*** 328,333 ****
--- 327,333 ----
          dest->tlsext_tick_lifetime_hint = 0;
          dest->tlsext_ticklen = 0;
      }
+ #endif

      return dest;
  err:
[root at SSL-LINUX-SERVER-POD5 ~]#

Could you please confirm, is it a known issue and can I continue with above patch?


Thanks & Regards,
Dinesh

-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From openssl-dev at mlists.thewrittenword.com  Wed Jun 24 15:56:23 2015
From: openssl-dev at mlists.thewrittenword.com (Albert Chin)
Date: Wed, 24 Jun 2015 10:56:23 -0500
Subject: [openssl-dev] Which patch to address CVE-2015-1788 in 0.9.8zg,
	1.0.0s?
Message-ID: <20150624155623.GD4859@thewrittenword.com>

What patchset was used to address CVE-2015-1788 in 1.0.0s and 0.9.8zg?
In the 1.0.1 branch, it's very clear:
  commit f61bbf8da532038ed0eae16a9a11771f3da22d30
  Author: Andy Polyakov <appro at openssl.org>
  Date:   Thu Jun 11 00:18:01 2015 +0200

      bn/bn_gf2m.c: avoid infinite loop wich malformed ECParamters.

      CVE-2015-1788

      Reviewed-by: Matt Caswell <matt at openssl.org>
      (cherry picked from commit

The CHANGES file in 1.0.0s and 0.9.8zg states:
  *) Malformed ECParameters causes infinite loop

     When processing an ECParameters structure OpenSSL enters an infinite loop
     if the curve specified is over a specially malformed binary polynomial
     field.

     This can be used to perform denial of service against any
     system which processes public keys, certificate requests or
     certificates.  This includes TLS clients and TLS servers with
     client authentication enabled.

     This issue was reported to OpenSSL by Joseph Barr-Pixton.
     (CVE-2015-1788)
     [Andy Polyakov]

-- 
albert chin (china at thewrittenword.com)

From matt at openssl.org  Wed Jun 24 16:14:53 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Jun 2015 17:14:53 +0100
Subject: [openssl-dev] Which patch to address CVE-2015-1788 in 0.9.8zg,
 1.0.0s?
In-Reply-To: <20150624155623.GD4859@thewrittenword.com>
References: <20150624155623.GD4859@thewrittenword.com>
Message-ID: <558AD77D.1070905@openssl.org>



On 24/06/15 16:56, Albert Chin wrote:
> What patchset was used to address CVE-2015-1788 in 1.0.0s and 0.9.8zg?
> In the 1.0.1 branch, it's very clear:
>   commit f61bbf8da532038ed0eae16a9a11771f3da22d30
>   Author: Andy Polyakov <appro at openssl.org>
>   Date:   Thu Jun 11 00:18:01 2015 +0200
> 
>       bn/bn_gf2m.c: avoid infinite loop wich malformed ECParamters.
> 
>       CVE-2015-1788
> 
>       Reviewed-by: Matt Caswell <matt at openssl.org>
>       (cherry picked from commit
> 
> The CHANGES file in 1.0.0s and 0.9.8zg states:
>   *) Malformed ECParameters causes infinite loop
> 
>      When processing an ECParameters structure OpenSSL enters an infinite loop
>      if the curve specified is over a specially malformed binary polynomial
>      field.
> 
>      This can be used to perform denial of service against any
>      system which processes public keys, certificate requests or
>      certificates.  This includes TLS clients and TLS servers with
>      client authentication enabled.
> 
>      This issue was reported to OpenSSL by Joseph Barr-Pixton.
>      (CVE-2015-1788)
>      [Andy Polyakov]
> 

That's an error. It should not be in the CHANGES file because no change
was made in the latest release. From the security advisory:

"This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent
1.0.0 and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are
affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0d (and below) users should upgrade to 1.0.0s
OpenSSL 0.9.8r (and below) users should upgrade to 0.9.8zg"

Matt

From openssl-dev at mlists.thewrittenword.com  Wed Jun 24 16:59:15 2015
From: openssl-dev at mlists.thewrittenword.com (Albert Chin)
Date: Wed, 24 Jun 2015 11:59:15 -0500
Subject: [openssl-dev] Which patch to address CVE-2015-1788 in 0.9.8zg,
 1.0.0s?
In-Reply-To: <558AD77D.1070905@openssl.org>
References: <20150624155623.GD4859@thewrittenword.com>
 <558AD77D.1070905@openssl.org>
Message-ID: <20150624165914.GE4859@thewrittenword.com>

On Wed, Jun 24, 2015 at 05:14:53PM +0100, Matt Caswell wrote:
> On 24/06/15 16:56, Albert Chin wrote:
> > What patchset was used to address CVE-2015-1788 in 1.0.0s and 0.9.8zg?
> > In the 1.0.1 branch, it's very clear:
> >   commit f61bbf8da532038ed0eae16a9a11771f3da22d30
> >   Author: Andy Polyakov <appro at openssl.org>
> >   Date:   Thu Jun 11 00:18:01 2015 +0200
> > 
> >       bn/bn_gf2m.c: avoid infinite loop wich malformed ECParamters.
> > 
> >       CVE-2015-1788
> > 
> >       Reviewed-by: Matt Caswell <matt at openssl.org>
> >       (cherry picked from commit
> > 
> > The CHANGES file in 1.0.0s and 0.9.8zg states:
> >   *) Malformed ECParameters causes infinite loop
> > 
> >      When processing an ECParameters structure OpenSSL enters an infinite loop
> >      if the curve specified is over a specially malformed binary polynomial
> >      field.
> > 
> >      This can be used to perform denial of service against any
> >      system which processes public keys, certificate requests or
> >      certificates.  This includes TLS clients and TLS servers with
> >      client authentication enabled.
> > 
> >      This issue was reported to OpenSSL by Joseph Barr-Pixton.
> >      (CVE-2015-1788)
> >      [Andy Polyakov]
> 
> That's an error. It should not be in the CHANGES file because no
> change was made in the latest release. From the security advisory:
> 
> "This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent 1.0.0
> and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are
> affected.

Ok, thanks.

-- 
albert chin (china at thewrittenword.com)

From kannanar at cisco.com  Wed Jun 24 18:57:22 2015
From: kannanar at cisco.com (Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco))
Date: Wed, 24 Jun 2015 18:57:22 +0000
Subject: [openssl-dev] Openssl Poodle Vulnerability Clarification
In-Reply-To: <20150611220725.GA18105@roeckx.be>
References: <AF70C7F70D95C54BAF2FCD161BADF2EB251EF249@xmb-aln-x13.cisco.com>
 <20150611220725.GA18105@roeckx.be>
Message-ID: <AF70C7F70D95C54BAF2FCD161BADF2EB27AB75FB@xmb-aln-x13.cisco.com>

Hi Kurt,

Thanks for the details. Syslog process is based on Java and disabling SSLv3 is not possible with that. We have tried to compile openssl with SSLv3 disabled but it didn't help. Can you share the steps if you have to disable via openssl compilation.

Thanks,
Kannan Narayanasamy.


-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Friday, June 12, 2015 3:37 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Openssl Poodle Vulnerability Clarification

On Thu, Jun 11, 2015 at 09:43:24PM +0000, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
> Hi All,
> 
> To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our application we have using openSSL through Apache. We have disabled using the below lines.
> 
> SSLProtocol all -SSLv2 -SSLv3
> 
> We are using 443 as SSL port. The command openssl s_client -connect <IPAddress>:443 -ssl3 shows the handshake failure message for 443 port. But for the ports 3333 and 4444 is connecting using SSLv3. The scanner as well report the high severity risk for those ports. In our application we are using those ports for syslog related tasks. If we change the port some other, then the scanner shows the new port in the list.
> 
> How to disable the SSLv3 connection for those ports as well since may customers are waiting for the fix. Your suggestion is much appreciated. 

There are 2 solutions:
- Change the configuration of syslog to disable SSLv3.  Not sure
  it can actually be configured.
- Build your openssl with SSLv3 disabled.


Kurt

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From rt at openssl.org  Wed Jun 24 19:20:25 2015
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Wed, 24 Jun 2015 19:20:25 +0000
Subject: [openssl-dev] [openssl.org #3904] [master] NULL handling Issues
	in i2c_ibuf() in a_int.c
In-Reply-To: <CADujJWUBLVNB89paqJdobH_RFfKvjzWOPhduWcXTnGU0-w6JXw@mail.gmail.com>
References: <RT-Ticket-3904@openssl.org>
 <CADujJWUDk73GSu_i87fxKRzqzUeWUKbDUPb6Vjr8ji0Wa=nVHA@mail.gmail.com>
 <rt-4.0.19-10987-1434123873-819.3904-21-0@openssl.org>
 <CADujJWUBLVNB89paqJdobH_RFfKvjzWOPhduWcXTnGU0-w6JXw@mail.gmail.com>
Message-ID: <rt-4.0.19-1697-1435173625-1148.3904-6-0@openssl.org>

This ticket can be closed I think, not sure why I haven't received a
response maybe the random RT issues. But it appears that it has been
fixed in response to this ticket in
f2dc4d517fa11208b90ba0e92a2590f8cfdafb28.

---
Kurt Cancemi
https://www.x64architecture.com



From dragon at dancingdragon.be  Wed Jun 24 21:21:42 2015
From: dragon at dancingdragon.be (Joey Yandle)
Date: Wed, 24 Jun 2015 14:21:42 -0700
Subject: [openssl-dev] Openssl Poodle Vulnerability Clarification
In-Reply-To: <AF70C7F70D95C54BAF2FCD161BADF2EB27AB75FB@xmb-aln-x13.cisco.com>
References: <AF70C7F70D95C54BAF2FCD161BADF2EB251EF249@xmb-aln-x13.cisco.com>
 <20150611220725.GA18105@roeckx.be>
 <AF70C7F70D95C54BAF2FCD161BADF2EB27AB75FB@xmb-aln-x13.cisco.com>
Message-ID: <558B1F66.5000609@dancingdragon.be>

The config script takes no-ssl2 and no-ssl3 args:

./config no-ssl2 no-ssl3 ...


On 06/24/2015 11:57 AM, Kannan Narayanasamy -X (kannanar - HCL 
TECHNOLOGIES LIMITED at Cisco) wrote:
> Hi Kurt,
>
> Thanks for the details. Syslog process is based on Java and disabling SSLv3 is not possible with that. We have tried to compile openssl with SSLv3 disabled but it didn't help. Can you share the steps if you have to disable via openssl compilation.
>
> Thanks,
> Kannan Narayanasamy.
>
>
> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Kurt Roeckx
> Sent: Friday, June 12, 2015 3:37 AM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] Openssl Poodle Vulnerability Clarification
>
> On Thu, Jun 11, 2015 at 09:43:24PM +0000, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
>> Hi All,
>>
>> To resolve openSSL POODLE vulnerability we need to disable the SSLv3. In our application we have using openSSL through Apache. We have disabled using the below lines.
>>
>> SSLProtocol all -SSLv2 -SSLv3
>>
>> We are using 443 as SSL port. The command openssl s_client -connect <IPAddress>:443 -ssl3 shows the handshake failure message for 443 port. But for the ports 3333 and 4444 is connecting using SSLv3. The scanner as well report the high severity risk for those ports. In our application we are using those ports for syslog related tasks. If we change the port some other, then the scanner shows the new port in the list.
>>
>> How to disable the SSLv3 connection for those ports as well since may customers are waiting for the fix. Your suggestion is much appreciated.
>
> There are 2 solutions:
> - Change the configuration of syslog to disable SSLv3.  Not sure
>    it can actually be configured.
> - Build your openssl with SSLv3 disabled.
>
>
> Kurt
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

From agostrer at gmail.com  Thu Jun 25 15:26:24 2015
From: agostrer at gmail.com (Alexander Gostrer)
Date: Thu, 25 Jun 2015 08:26:24 -0700
Subject: [openssl-dev] A new openssl engine
Message-ID: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>

Hi All,

Sorry for a wide distribution. I am in a process of writing an OpenSSL
engine to support my client hardware. The client requested to publish the
code on the openssl.org site. What are openssl criterions for publishing
new engines/adding new features? Is there a document or a person who can
help to understand the process?

Thank you,
Alexander Gostrer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/32544d40/attachment-0001.html>

From matt at openssl.org  Thu Jun 25 15:34:34 2015
From: matt at openssl.org (Matt Caswell)
Date: Thu, 25 Jun 2015 16:34:34 +0100
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
Message-ID: <558C1F8A.1070501@openssl.org>



On 25/06/15 16:26, Alexander Gostrer wrote:
> Hi All,
> 
> Sorry for a wide distribution. I am in a process of writing an OpenSSL
> engine to support my client hardware. The client requested to publish
> the code on the openssl.org <http://openssl.org> site. What are openssl
> criterions for publishing new engines/adding new features? Is there a
> document or a person who can help to understand the process?

Patches can be submitted by sending an email to rt at openssl.org. Either
attach the patch to the email, or provide a reference to a github pull
request.

Whether such a patch would be accepted though is an entirely different
thing. Personally I would prefer new engines to be maintained outside of
the OpenSSL tree. Inclusion in the OpenSSL tree implies that the OpenSSL
dev team will support the code. That becomes very difficult/impossible
if we do not have access to the hardware.

Matt


From openssl-users at dukhovni.org  Thu Jun 25 15:45:56 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 25 Jun 2015 15:45:56 +0000
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <558C1F8A.1070501@openssl.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
Message-ID: <20150625154556.GX14121@mournblade.imrryr.org>

On Thu, Jun 25, 2015 at 04:34:34PM +0100, Matt Caswell wrote:

> Whether such a patch would be accepted though is an entirely different
> thing. Personally I would prefer new engines to be maintained outside of
> the OpenSSL tree. Inclusion in the OpenSSL tree implies that the OpenSSL
> dev team will support the code. That becomes very difficult/impossible
> if we do not have access to the hardware.

In addition, in order to not dig the hole we're in deeper, the
contributed code would have to be high quality code.  That is,
clearly written, sensibly commented and well documented.

All in all, it seems unlikely that new engines will become part of
the OpenSSL official distribution.  If anything, some existing
engines are likely to be retired.

-- 
	Viktor.

From agostrer at gmail.com  Thu Jun 25 15:53:40 2015
From: agostrer at gmail.com (Alexander Gostrer)
Date: Thu, 25 Jun 2015 08:53:40 -0700
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <20150625154556.GX14121@mournblade.imrryr.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
Message-ID: <CAMv_ppvmittmL4pr67-A3xY_ENZE2nTxMfn0crF5aWat_9svog@mail.gmail.com>

Thank you, Matt, Viktor,

I very like "clearly written, sensibly commented and well documented"
code:) It will be not a problem:) But if you are going to retire existing
engines then looks like I have no choice.

Thank you,
Alex.

On Thu, Jun 25, 2015 at 8:45 AM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

> On Thu, Jun 25, 2015 at 04:34:34PM +0100, Matt Caswell wrote:
>
> > Whether such a patch would be accepted though is an entirely different
> > thing. Personally I would prefer new engines to be maintained outside of
> > the OpenSSL tree. Inclusion in the OpenSSL tree implies that the OpenSSL
> > dev team will support the code. That becomes very difficult/impossible
> > if we do not have access to the hardware.
>
> In addition, in order to not dig the hole we're in deeper, the
> contributed code would have to be high quality code.  That is,
> clearly written, sensibly commented and well documented.
>
> All in all, it seems unlikely that new engines will become part of
> the OpenSSL official distribution.  If anything, some existing
> engines are likely to be retired.
>
> --
>         Viktor.
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/8542390d/attachment.html>

From dwmw2 at infradead.org  Thu Jun 25 16:03:29 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 25 Jun 2015 17:03:29 +0100
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <20150625154556.GX14121@mournblade.imrryr.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
Message-ID: <1435248209.22827.61.camel@infradead.org>

On Thu, 2015-06-25 at 15:45 +0000, Viktor Dukhovni wrote:
> On Thu, Jun 25, 2015 at 04:34:34PM +0100, Matt Caswell wrote:
> 
> > Whether such a patch would be accepted though is an entirely 
> > different
> > thing. Personally I would prefer new engines to be maintained 
> > outside of
> > the OpenSSL tree. Inclusion in the OpenSSL tree implies that the 
> > OpenSSL
> > dev team will support the code. That becomes very 
> > difficult/impossible
> > if we do not have access to the hardware.
> 
> In addition, in order to not dig the hole we're in deeper, the
> contributed code would have to be high quality code.  That is,
> clearly written, sensibly commented and well documented.
> 
> All in all, it seems unlikely that new engines will become part of
> the OpenSSL official distribution.  If anything, some existing
> engines are likely to be retired.

FWIW I hope that a PKCS#11 engine might be an exception to that rule.

Note that I say "a" PKCS#11 engine not necessarily "the" PKCS#11
engine, given the comments about code quality.

Or rather than an engine, merging a suitably licensed version of
something like libp11 into crypto/p11/ and making PKCS#11 a first-class
citizen in OpenSSL would perhaps be a better option...


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/0e5b26a0/attachment.bin>

From agostrer at gmail.com  Thu Jun 25 17:48:41 2015
From: agostrer at gmail.com (Alexander Gostrer)
Date: Thu, 25 Jun 2015 10:48:41 -0700
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <1435248209.22827.61.camel@infradead.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
Message-ID: <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>

Matt,

When you say "would prefer new engines to be maintained outside of the
OpenSSL tree", do you mean a private webpage and/or GitHub? Is there a
central list of Engine implementations? Something that helps the outside
world to find a solution not covered by the openssl community?

Thank you,
Alex.

On Thu, Jun 25, 2015 at 9:03 AM, David Woodhouse <dwmw2 at infradead.org>
wrote:

> On Thu, 2015-06-25 at 15:45 +0000, Viktor Dukhovni wrote:
> > On Thu, Jun 25, 2015 at 04:34:34PM +0100, Matt Caswell wrote:
> >
> > > Whether such a patch would be accepted though is an entirely
> > > different
> > > thing. Personally I would prefer new engines to be maintained
> > > outside of
> > > the OpenSSL tree. Inclusion in the OpenSSL tree implies that the
> > > OpenSSL
> > > dev team will support the code. That becomes very
> > > difficult/impossible
> > > if we do not have access to the hardware.
> >
> > In addition, in order to not dig the hole we're in deeper, the
> > contributed code would have to be high quality code.  That is,
> > clearly written, sensibly commented and well documented.
> >
> > All in all, it seems unlikely that new engines will become part of
> > the OpenSSL official distribution.  If anything, some existing
> > engines are likely to be retired.
>
> FWIW I hope that a PKCS#11 engine might be an exception to that rule.
>
> Note that I say "a" PKCS#11 engine not necessarily "the" PKCS#11
> engine, given the comments about code quality.
>
> Or rather than an engine, merging a suitably licensed version of
> something like libp11 into crypto/p11/ and making PKCS#11 a first-class
> citizen in OpenSSL would perhaps be a better option...
>
>
> --
> dwmw2
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/981a632b/attachment-0001.html>

From rsalz at akamai.com  Thu Jun 25 18:13:22 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 25 Jun 2015 18:13:22 +0000
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org> <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
Message-ID: <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>

Most folks with crypto hardware usually include and maintain their ENGINE manipulation as part of their SDK.  Is there any reason why this approach doesn't work here? 

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

From agostrer at gmail.com  Thu Jun 25 18:38:49 2015
From: agostrer at gmail.com (Alexander Gostrer)
Date: Thu, 25 Jun 2015 11:38:49 -0700
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>

Hi Rich,

It was my customer's request. I can ask them why:). Personally I think that
it is a good idea to show what hardware is available and supported by
openssl (even if maintained by a private party as a part of their SDK).
Couple years ago I was looking for a good HSM with good openssl support. A
centralized list would help a lot then.

Thank you,
Alex.



On Thu, Jun 25, 2015 at 11:13 AM, Salz, Rich <rsalz at akamai.com> wrote:

> Most folks with crypto hardware usually include and maintain their ENGINE
> manipulation as part of their SDK.  Is there any reason why this approach
> doesn't work here?
>
> --
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/451c1660/attachment.html>

From beldmit at gmail.com  Thu Jun 25 20:36:58 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 25 Jun 2015 23:36:58 +0300
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
Message-ID: <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>

Hello Alexander,

On Thu, Jun 25, 2015 at 9:38 PM, Alexander Gostrer <agostrer at gmail.com>
wrote:

> Hi Rich,
>
> It was my customer's request. I can ask them why:). Personally I think
> that it is a good idea to show what hardware is available and supported by
> openssl (even if maintained by a private party as a part of their SDK).
> Couple years ago I was looking for a good HSM with good openssl support. A
> centralized list would help a lot then.
>
> I totally agree with this idea. It will be very useful to know whether
this or that HSM/token/RNG can be used with openssl.

BTW, what does the OpenSSL  Team plan regarding the GOST engine?

Thank you!


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/ea3f60e9/attachment.html>

From kurt at roeckx.be  Thu Jun 25 20:48:08 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 25 Jun 2015 22:48:08 +0200
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
Message-ID: <20150625204808.GA25359@roeckx.be>

On Thu, Jun 25, 2015 at 11:36:58PM +0300, Dmitry Belyavsky wrote:
> 
> BTW, what does the OpenSSL  Team plan regarding the GOST engine?

I think some of us want to get rid of it, because it's rather
crappy code.


Kurt


From openssl-users at dukhovni.org  Thu Jun 25 20:58:50 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 25 Jun 2015 20:58:50 +0000
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <20150625204808.GA25359@roeckx.be>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
 <20150625204808.GA25359@roeckx.be>
Message-ID: <20150625205850.GC14121@mournblade.imrryr.org>

On Thu, Jun 25, 2015 at 10:48:08PM +0200, Kurt Roeckx wrote:

> On Thu, Jun 25, 2015 at 11:36:58PM +0300, Dmitry Belyavsky wrote:
> > 
> > BTW, what does the OpenSSL  Team plan regarding the GOST engine?
> 
> I think some of us want to get rid of it, because it's rather
> crappy code.

I think that if GOST is really going to be a supported set of
algorithms, then it should not be an engine, and should be integrated
properly, with robust well written and carefully reviewed code.

The current engine is IMHO not a good long-term vehicle for providing
GOST support to OpenSSL users.

-- 
	Viktor.

From beldmit at gmail.com  Thu Jun 25 21:08:04 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 26 Jun 2015 00:08:04 +0300
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <20150625205850.GC14121@mournblade.imrryr.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
 <20150625204808.GA25359@roeckx.be>
 <20150625205850.GC14121@mournblade.imrryr.org>
Message-ID: <CADqLbz+ADxavPHoP7G1T75tvYuPDn_LbqbJsq9p6OL4DNpkbxA@mail.gmail.com>

Hello Viktor,

On Thu, Jun 25, 2015 at 11:58 PM, Viktor Dukhovni <
openssl-users at dukhovni.org> wrote:

> On Thu, Jun 25, 2015 at 10:48:08PM +0200, Kurt Roeckx wrote:
>
> > On Thu, Jun 25, 2015 at 11:36:58PM +0300, Dmitry Belyavsky wrote:
> > >
> > > BTW, what does the OpenSSL  Team plan regarding the GOST engine?
> >
> > I think some of us want to get rid of it, because it's rather
> > crappy code.
>
> I think that if GOST is really going to be a supported set of
> algorithms, then it should not be an engine, and should be integrated
> properly, with robust well written and carefully reviewed code.
>

Well, if GOST algorithms become 1st-class citizens, it can solve some
problems. I think it is possible to find some programmers (including me)
who are ready to participate in this work.


>
> The current engine is IMHO not a good long-term vehicle for providing
> GOST support to OpenSSL users.
>

Sure. For example, GOST94 signature algorithm is deprecated.
But the current engine can be used to demonstrate the proper way to provide
new algorithms through engine.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150626/02c21db2/attachment.html>

From matt at openssl.org  Thu Jun 25 23:17:55 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2015 00:17:55 +0100
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org> <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
Message-ID: <558C8C23.3070804@openssl.org>



On 25/06/15 18:48, Alexander Gostrer wrote:
> Matt,
> 
> When you say "would prefer new engines to be maintained outside of the
> OpenSSL tree", do you mean a private webpage and/or GitHub?

Yes. That's exactly what I had in mind.

> Is there a
> central list of Engine implementations? Something that helps the outside
> world to find a solution not covered by the openssl community?

No, not at the moment. We do have a page on the Wiki though that could
contain such a list quite nicely. See:

https://wiki.openssl.org/index.php/Related_Links

I think adding an "Engines" section to there would fit quite well.

Matt


From matt at openssl.org  Thu Jun 25 23:23:39 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2015 00:23:39 +0100
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <20150625205850.GC14121@mournblade.imrryr.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org> <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
 <20150625204808.GA25359@roeckx.be>
 <20150625205850.GC14121@mournblade.imrryr.org>
Message-ID: <558C8D7B.6000309@openssl.org>



On 25/06/15 21:58, Viktor Dukhovni wrote:
> On Thu, Jun 25, 2015 at 10:48:08PM +0200, Kurt Roeckx wrote:
> 
>> On Thu, Jun 25, 2015 at 11:36:58PM +0300, Dmitry Belyavsky wrote:
>>>
>>> BTW, what does the OpenSSL  Team plan regarding the GOST engine?
>>
>> I think some of us want to get rid of it, because it's rather
>> crappy code.
> 
> I think that if GOST is really going to be a supported set of
> algorithms, then it should not be an engine, and should be integrated
> properly, with robust well written and carefully reviewed code.
> 
> The current engine is IMHO not a good long-term vehicle for providing
> GOST support to OpenSSL users.
> 

I don't see GOST being integrated as a first class citizen in the near
future unless a member of the dev team volunteers to own it. So far I've
not seen any evidence of that happening (although to be fair I've not
asked the question until now!).

In the absence of such an owner stepping forward, my preferred solution
is to spin GOST out as a separately maintained engine - if we could find
someone willing to take it on.

Of course there's nothing to stop us doing both, i.e. in the short term
spin it out as a separate engine whilst looking towards a longer term
plan of integrating it as a first class citizen.

Matt

From agostrer at gmail.com  Thu Jun 25 23:47:35 2015
From: agostrer at gmail.com (Alexander Gostrer)
Date: Thu, 25 Jun 2015 16:47:35 -0700
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <558C8C23.3070804@openssl.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <558C8C23.3070804@openssl.org>
Message-ID: <CAMv_ppuWGrQq+L6CKFWk=1oA5coENP_ALQ3NTjKfaJBR-+R1sw@mail.gmail.com>

Hi Matt,

> No, not at the moment. We do have a page on the Wiki though that could
> contain such a list quite nicely. See:

> https://wiki.openssl.org/index.php/Related_Links

> I think adding an "Engines" section to there would fit quite well.

I think it is a good idea

Thank you,
Alex.

On Thu, Jun 25, 2015 at 4:17 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 25/06/15 18:48, Alexander Gostrer wrote:
> > Matt,
> >
> > When you say "would prefer new engines to be maintained outside of the
> > OpenSSL tree", do you mean a private webpage and/or GitHub?
>
> Yes. That's exactly what I had in mind.
>
> > Is there a
> > central list of Engine implementations? Something that helps the outside
> > world to find a solution not covered by the openssl community?
>
> No, not at the moment. We do have a page on the Wiki though that could
> contain such a list quite nicely. See:
>
> https://wiki.openssl.org/index.php/Related_Links
>
> I think adding an "Engines" section to there would fit quite well.
>
> Matt
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150625/a7f4272a/attachment.html>

From meissner at suse.de  Fri Jun 26 07:27:46 2015
From: meissner at suse.de (Marcus Meissner)
Date: Fri, 26 Jun 2015 09:27:46 +0200
Subject: [openssl-dev] testsuite error in Net-SSLeay
Message-ID: <20150626072746.GA25232@suse.de>

Hi,

I am debugging a testsuite error in the perl Net-SSLeay module, which got introduced between 1.0.2a
and 1.0.2c.

The test code looks like this:

  ... private key in $pk ...

  ok(my $alg2 = Net::SSLeay::EVP_get_cipherbyname("DES-EDE3-OFB"), "EVP_get_cipherbyname");
  like(my $key_pem4 = Net::SSLeay::PEM_get_string_PrivateKey($pk,"password",$alg2), qr/-----BEGIN (ENCRYPTED|RSA) PRIVATE KEY-----/, "PEM_get_string_PrivateKey+passwd+enc_alg");

Previously it returned a encrypted key, now it does not.

The error stack has:
	0:error:0D0A706C:asn1 encoding routines:PKCS5_pbe2_set_iv:cipher has no object identifier:p5_pbev2.c:104:
	0:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1 lib:p12_p8e.c:86:

Which I _think_ is caused by this change between 1.0.2a and 1.0.2c:

diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c
index 5cd755d..aca382a 100644
--- a/crypto/objects/obj_dat.c
+++ b/crypto/objects/obj_dat.c
@@ -400,6 +400,8 @@ static int obj_cmp(const ASN1_OBJECT *const *ap, const unsigned int *bp)
     j = (a->length - b->length);
     if (j)
	 return (j);
+    if (a->length == 0)
+        return 0;
     return (memcmp(a->data, b->data, a->length));
 }
 
@@ -415,6 +417,9 @@ int OBJ_obj2nid(const ASN1_OBJECT *a)
     if (a->nid != 0)
	 return (a->nid);
 
+    if (a->length == 0)
+        return NID_undef;
+
     if (added != NULL) {
	 ad.type = ADDED_DATA;
	 ad.obj = (ASN1_OBJECT *)a; /* XXX: ugly but harmless */


which comes from the objects entry:
obj_dat.h:{"DES-EDE3-CBC","des-ede3-cbc",NID_des_ede3_cbc,8,&(lvalues[235]),0},
obj_dat.h:{"DES-EDE3-OFB","des-ede3-ofb",NID_des_ede3_ofb64,0,NULL,0},

I was not able to find out why des-ede3-cbc does have length 8, but ofb does not? 

How to fix this? Should it have length 8 too?

Ciao, Marcus

From rt at openssl.org  Fri Jun 26 12:33:24 2015
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Fri, 26 Jun 2015 12:33:24 +0000
Subject: [openssl-dev] [openssl.org #3926] [PATCH] Fix -evp option in
	openssl speed command
In-Reply-To: <CADujJWWWGaR2ByK4nbG=EMk0RSTRagYwq9h1ueRMOKMLU-MUqA@mail.gmail.com>
References: <RT-Ticket-3926@openssl.org>
 <CADujJWWWGaR2ByK4nbG=EMk0RSTRagYwq9h1ueRMOKMLU-MUqA@mail.gmail.com>
Message-ID: <rt-4.0.19-13287-1435322004-1590.3926-21-0@openssl.org>

Hello,

The -evp option in the openssl speed command doesn't work in the
current master due to the check on line 952:
if (argc == 0) should be if (argc == 0 && !doit(D_EVP))

the reason is on line 856: argc = opt_num_rest(); which sets argc to 0
because the argument of -evp <insert cipher/hash> doesn't count as an
argument in the opt_num_rest() function.

See the attached patch

--
Kurt Cancemi
https://www.x64architecture.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-evp-option-in-openssl-speed-command.patch
Type: text/x-patch
Size: 682 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150626/51503963/attachment.bin>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

From levitte at openssl.org  Fri Jun 26 14:31:51 2015
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 26 Jun 2015 16:31:51 +0200 (CEST)
Subject: [openssl-dev] [BISECTED] make install_sw fails
In-Reply-To: <DUB123-W41F4CF0407278CBFC5F9D4EDAD0@phx.gbl>
References: <DUB123-W41F4CF0407278CBFC5F9D4EDAD0@phx.gbl>
Message-ID: <20150626.163151.1613841793466891260.levitte@openssl.org>

rm -f include/openssl/des_old.h

In message <DUB123-W41F4CF0407278CBFC5F9D4EDAD0 at phx.gbl> on Fri, 26 Jun 2015 16:08:13 +0200, Lukas Tribus <luky-37 at hotmail.com> said:

luky-37> Hi!
luky-37> 
luky-37> 
luky-37> Since commit dee502be89e7 ("Stop symlinking, move files to intended
luky-37> directory"), "make install_sw" fails with (and other, similar errors,
luky-37> depending on the git HEAD):
luky-37> 
luky-37> cp: cannot stat ?include/openssl/des_old.h?: No such file or directory
luky-37> make: *** [install_sw] Error 1
luky-37> 
luky-37> 
luky-37> I'm testing like this:
luky-37> rm -r /home/user/libsslbuild/
luky-37> mkdir /home/user/libsslbuild/
luky-37> cd /home/user/openssl/
luky-37> ./config --prefix=/home/user/libsslbuild/ no-shared
luky-37> make
luky-37> make install_sw
luky-37> 
luky-37> 
luky-37> 
luky-37> 
luky-37> Could you please take a look?
luky-37> 
luky-37> 
luky-37> 
luky-37> Thanks,
luky-37> 
luky-37> Lukas 		 	   		  

From beldmit at gmail.com  Fri Jun 26 16:36:19 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 26 Jun 2015 19:36:19 +0300
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <558C8D7B.6000309@openssl.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
 <20150625204808.GA25359@roeckx.be>
 <20150625205850.GC14121@mournblade.imrryr.org>
 <558C8D7B.6000309@openssl.org>
Message-ID: <CADqLbzLLMhYAo7W+X8svnV-kPWp5akLJwJZ-SQUO_CqJgLrFFQ@mail.gmail.com>

Dear Matt,

On Fri, Jun 26, 2015 at 2:23 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 25/06/15 21:58, Viktor Dukhovni wrote:
> > On Thu, Jun 25, 2015 at 10:48:08PM +0200, Kurt Roeckx wrote:
> >
> >> On Thu, Jun 25, 2015 at 11:36:58PM +0300, Dmitry Belyavsky wrote:
> >>>
> >>> BTW, what does the OpenSSL  Team plan regarding the GOST engine?
> >>
> >> I think some of us want to get rid of it, because it's rather
> >> crappy code.
> >
> > I think that if GOST is really going to be a supported set of
> > algorithms, then it should not be an engine, and should be integrated
> > properly, with robust well written and carefully reviewed code.
> >
> > The current engine is IMHO not a good long-term vehicle for providing
> > GOST support to OpenSSL users.
> >
>
> I don't see GOST being integrated as a first class citizen in the near
> future unless a member of the dev team volunteers to own it. So far I've
> not seen any evidence of that happening (although to be fair I've not
> asked the question until now!).
>
> In the absence of such an owner stepping forward, my preferred solution
> is to spin GOST out as a separately maintained engine - if we could find
> someone willing to take it on.
>

It's not a problem to start mantaining the engine code outside the main
OpenSSL tree.

But comrehensive support of GOST requires much more:
- TLS (the most messy)
- pkcs12
- OIDs for algs themselves and for some extensions used in Russia
- some smime-related stuff
etc

All the enumerated above seems to be much more complicated and could hardly
be supported separately from the main tree.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150626/2a99354e/attachment.html>

From matt at openssl.org  Fri Jun 26 18:12:53 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Jun 2015 19:12:53 +0100
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <CADqLbzLLMhYAo7W+X8svnV-kPWp5akLJwJZ-SQUO_CqJgLrFFQ@mail.gmail.com>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org> <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
 <20150625204808.GA25359@roeckx.be>
 <20150625205850.GC14121@mournblade.imrryr.org> <558C8D7B.6000309@openssl.org>
 <CADqLbzLLMhYAo7W+X8svnV-kPWp5akLJwJZ-SQUO_CqJgLrFFQ@mail.gmail.com>
Message-ID: <558D9625.1060607@openssl.org>



On 26/06/15 17:36, Dmitry Belyavsky wrote:
> Dear Matt,
> 
> On Fri, Jun 26, 2015 at 2:23 AM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 25/06/15 21:58, Viktor Dukhovni wrote:
>     > On Thu, Jun 25, 2015 at 10:48:08PM +0200, Kurt Roeckx wrote:
>     >
>     >> On Thu, Jun 25, 2015 at 11:36:58PM +0300, Dmitry Belyavsky wrote:
>     >>>
>     >>> BTW, what does the OpenSSL  Team plan regarding the GOST engine?
>     >>
>     >> I think some of us want to get rid of it, because it's rather
>     >> crappy code.
>     >
>     > I think that if GOST is really going to be a supported set of
>     > algorithms, then it should not be an engine, and should be integrated
>     > properly, with robust well written and carefully reviewed code.
>     >
>     > The current engine is IMHO not a good long-term vehicle for providing
>     > GOST support to OpenSSL users.
>     >
> 
>     I don't see GOST being integrated as a first class citizen in the near
>     future unless a member of the dev team volunteers to own it. So far I've
>     not seen any evidence of that happening (although to be fair I've not
>     asked the question until now!).
> 
>     In the absence of such an owner stepping forward, my preferred solution
>     is to spin GOST out as a separately maintained engine - if we could find
>     someone willing to take it on.
> 
> 
> It's not a problem to start mantaining the engine code outside the main
> OpenSSL tree. 
> 
> But comrehensive support of GOST requires much more:
> - TLS (the most messy)
> - pkcs12
> - OIDs for algs themselves and for some extensions used in Russia
> - some smime-related stuff
> etc
> 
> All the enumerated above seems to be much more complicated and could
> hardly be supported separately from the main tree.

Yes. I agree there are some things that could not be taken out. I am not
proposing to remove those - I'm just talking about taking out the main
engine itself.

Matt


From beldmit at gmail.com  Fri Jun 26 18:26:39 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 26 Jun 2015 21:26:39 +0300
Subject: [openssl-dev] A new openssl engine
In-Reply-To: <558D9625.1060607@openssl.org>
References: <CAMv_pps60beMuFVqcp0PAXne248OQ5S+cX1f0ysLmco9-GspyQ@mail.gmail.com>
 <558C1F8A.1070501@openssl.org>
 <20150625154556.GX14121@mournblade.imrryr.org>
 <1435248209.22827.61.camel@infradead.org>
 <CAMv_ppu3y9gvJzb0bGjQ5_K1Cbsk-QoaqoOCF=U=nmyLtz+Dfw@mail.gmail.com>
 <9ec405385c614d69888c38309d21ac1e@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <CAMv_ppty2rEXY+6QfPu7rcYSitwZuxdnp79vew=W5mNhd5X1aA@mail.gmail.com>
 <CADqLbzL6nN8D4DivAbz1F2Jm0cOM_eMcp8LAPaZ7aVE+mMG8QA@mail.gmail.com>
 <20150625204808.GA25359@roeckx.be>
 <20150625205850.GC14121@mournblade.imrryr.org>
 <558C8D7B.6000309@openssl.org>
 <CADqLbzLLMhYAo7W+X8svnV-kPWp5akLJwJZ-SQUO_CqJgLrFFQ@mail.gmail.com>
 <558D9625.1060607@openssl.org>
Message-ID: <CADqLbzLAFG_sa8MDGLUGprTmO0GVpreH459G6CD5VkYUjcQEzQ@mail.gmail.com>

Hello Matt,

On Fri, Jun 26, 2015 at 9:12 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 26/06/15 17:36, Dmitry Belyavsky wrote:
>
> > It's not a problem to start mantaining the engine code outside the main
> > OpenSSL tree.
> >
> > But comrehensive support of GOST requires much more:
> > - TLS (the most messy)
> > - pkcs12
> > - OIDs for algs themselves and for some extensions used in Russia
> > - some smime-related stuff
> > etc
> >
> > All the enumerated above seems to be much more complicated and could
> > hardly be supported separately from the main tree.
>
> Yes. I agree there are some things that could not be taken out. I am not
> proposing to remove those - I'm just talking about taking out the main
> engine itself.
>
>
Ok, let's discuss the best way to organize it (may be off-list).

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150626/3908222c/attachment-0001.html>

From rsteck at symsysresearch.com  Mon Jun 29 06:48:22 2015
From: rsteck at symsysresearch.com (rsteck at symsysresearch.com)
Date: Mon, 29 Jun 2015 02:48:22 -0400
Subject: [openssl-dev] RSA SigVer (FIPS 186-4) Issue
Message-ID: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>

I am getting incorrect False-Negative results when performing tests with 
186-4 vectors (generated by CAVS 17.6).

This vector is being reported false while CAVS says they should pass.

[mod = 1024]
n = 
d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009

SHAAlg = SHA512
e = 
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2acb
Msg = 
912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
S = 
122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3

I've added some debug output and I get the following:

DIGEST = 
423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
SIG = 
122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
N   = 
D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
RR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SUB = 
CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921CCCCDAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
IR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SigVer Result = 0

"RR" is the result of the power-E-mod-N operation, and "SUB" is the 
computed (N-RR) value.  "IR" is the choice of RR or (N-RR) used for the 
remainder of verification.

It seems clear to me that neither RR nor SUB has the correct form, and 
that this vector should not pass.

The lab is saying this must be a bug in OpenSSL, but no modification has 
been made that would introduce such a bug.  It's my contention that this 
is a bug in CAVS.  Can anyone shed some additional light onto the issue?

Thanks,
Randy Steck

From rsteck at symsysresearch.com  Sat Jun 27 22:52:28 2015
From: rsteck at symsysresearch.com (rsteck at symsysresearch.com)
Date: Sat, 27 Jun 2015 18:52:28 -0400
Subject: [openssl-dev] RSA SigVer (FIPS 186-4) Issue
Message-ID: <79b8a7617d9fef662e5089250f158a7b@symsysresearch.com>

I am getting incorrect False-Negative results when performing tests with 
186-4 vectors (generated by CAVS 17.6).

This vector is being reported false while CAVS says they should pass.

[mod = 1024]
n = 
d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009

SHAAlg = SHA512
e = 
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2acb
Msg = 
912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
S = 
122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3

I've added some debug output and I get the following:

DIGEST = 
423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
SIG = 
122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
N   = 
D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
RR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SUB = 
CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921CCCCDAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
IR  = 
CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
SigVer Result = 0

"RR" is the result of the power-E-mod-N operation, and "SUB" is the 
computed (N-RR) value.  "IR" is the choice of RR or (N-RR) used for the 
remainder of verification.

It seems clear to me that neither RR nor SUB has the correct form, and 
that this vector should not pass.

The lab is saying this must be a bug in OpenSSL, but no modification has 
been made that would introduce such a bug.  It's my contention that this 
is a bug in CAVS.  Can anyone shed some additional light onto the issue?

Thanks,
Randy Steck

From marquess at openssl.com  Mon Jun 29 12:53:29 2015
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 29 Jun 2015 08:53:29 -0400
Subject: [openssl-dev] RSA SigVer (FIPS 186-4) Issue
In-Reply-To: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>
References: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>
Message-ID: <55913FC9.7000106@openssl.com>

On 06/29/2015 02:48 AM, rsteck at symsysresearch.com wrote:
> I am getting incorrect False-Negative results when performing tests with
> 186-4 vectors (generated by CAVS 17.6).
> 
> This vector is being reported false while CAVS says they should pass.
> 
> [mod = 1024]
> ...

You're getting CAVS tests for 1024 bit RSA keys?

Keep in mind that the #1747 validation predates FPS 186-4, and we aren't
allowed to update it to meet that (or other) new requirements. So you
won't see FIPS 1806-4 support in the FIPS module until and if we're able
to do a new OSS based validation to succeed #1747.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From rt at openssl.org  Mon Jun 29 14:27:18 2015
From: rt at openssl.org (Marcus Meissner via RT)
Date: Mon, 29 Jun 2015 14:27:18 +0000
Subject: [openssl-dev] [openssl.org #3927] regression in 1.0.2c spotted by
	Net-SSLeay
In-Reply-To: <20150629125258.GB21786@suse.de>
References: <RT-Ticket-3927@openssl.org> <20150629125258.GB21786@suse.de>
Message-ID: <rt-4.0.19-30792-1435588038-1300.3927-21-0@openssl.org>

Hi,

I am debugging a testsuite error in the perl Net-SSLeay module, which got introduced between 1.0.2a
and 1.0.2c.

The test code looks like this:

  ... private key in $pk ...

  ok(my $alg2 = Net::SSLeay::EVP_get_cipherbyname("DES-EDE3-OFB"), "EVP_get_cipherbyname");
  like(my $key_pem4 = Net::SSLeay::PEM_get_string_PrivateKey($pk,"password",$alg2), qr/-----BEGIN (ENCRYPTED|RSA) PRIVATE KEY-----/, "PEM_get_string_PrivateKey+passwd+enc_alg");

Previously it returned a encrypted key, now it does not.

The error stack has:
	0:error:0D0A706C:asn1 encoding routines:PKCS5_pbe2_set_iv:cipher has no object identifier:p5_pbev2.c:104:
	0:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1 lib:p12_p8e.c:86:

Which I _think_ is caused by this change between 1.0.2a and 1.0.2c:

diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c
index 5cd755d..aca382a 100644
--- a/crypto/objects/obj_dat.c
+++ b/crypto/objects/obj_dat.c
@@ -400,6 +400,8 @@ static int obj_cmp(const ASN1_OBJECT *const *ap, const unsigned int *bp)
     j = (a->length - b->length);
     if (j)
	 return (j);
+    if (a->length == 0)
+        return 0;
     return (memcmp(a->data, b->data, a->length));
 }
 
@@ -415,6 +417,9 @@ int OBJ_obj2nid(const ASN1_OBJECT *a)
     if (a->nid != 0)
	 return (a->nid);
 
+    if (a->length == 0)
+        return NID_undef;
+
     if (added != NULL) {
	 ad.type = ADDED_DATA;
	 ad.obj = (ASN1_OBJECT *)a; /* XXX: ugly but harmless */


which comes from the objects entry:
obj_dat.h:{"DES-EDE3-CBC","des-ede3-cbc",NID_des_ede3_cbc,8,&(lvalues[235]),0},
obj_dat.h:{"DES-EDE3-OFB","des-ede3-ofb",NID_des_ede3_ofb64,0,NULL,0},

I was not able to find out why des-ede3-cbc does have length 8, but ofb does not? 

How to fix this? Should it have length 8 too?

Ciao, Marcus

_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod


From rt at openssl.org  Mon Jun 29 17:17:37 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Mon, 29 Jun 2015 17:17:37 +0000
Subject: [openssl-dev] [openssl.org #3927] regression in 1.0.2c spotted by
	Net-SSLeay
In-Reply-To: <20150629125258.GB21786@suse.de>
References: <RT-Ticket-3927@openssl.org> <20150629125258.GB21786@suse.de>
Message-ID: <rt-4.0.19-24823-1435598257-74.3927-6-0@openssl.org>

On Mon Jun 29 14:27:18 2015, meissner at suse.de wrote:
> Hi,
>
> I am debugging a testsuite error in the perl Net-SSLeay module, which
> got introduced between 1.0.2a
> and 1.0.2c.
>
> The test code looks like this:
>
> ... private key in $pk ...
>
> ok(my $alg2 = Net::SSLeay::EVP_get_cipherbyname("DES-EDE3-OFB"),
> "EVP_get_cipherbyname");
> like(my $key_pem4 =
> Net::SSLeay::PEM_get_string_PrivateKey($pk,"password",$alg2), qr/-----
> BEGIN (ENCRYPTED|RSA) PRIVATE KEY-----/,
> "PEM_get_string_PrivateKey+passwd+enc_alg");
>
> Previously it returned a encrypted key, now it does not.
>
> The error stack has:
> 0:error:0D0A706C:asn1 encoding
> routines:PKCS5_pbe2_set_iv:cipher has no object
> identifier:p5_pbev2.c:104:
> 0:error:2307D00D:PKCS12 routines:PKCS8_encrypt:ASN1
> lib:p12_p8e.c:86:
>
[snip]
>
> which comes from the objects entry:
> obj_dat.h:{"DES-EDE3-CBC","des-ede3-
> cbc",NID_des_ede3_cbc,8,&(lvalues[235]),0},
> obj_dat.h:{"DES-EDE3-OFB","des-ede3-ofb",NID_des_ede3_ofb64,0,NULL,0},
>
> I was not able to find out why des-ede3-cbc does have length 8, but
> ofb does not?
>
> How to fix this? Should it have length 8 too?
>

That should never have worked in the first place. It has a length 0 because the
NID has no corresponding object identifier and such NIDs cannot be properly
encoded in PKCS#8 format. The fact that OpenSSL let you do that previously
(with a garbage OID) is the bug.

The fix is to use a cipher mode which is properly supported for PKCS#8 format
such as CBC mode.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From steve at openssl.org  Mon Jun 29 17:33:19 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 29 Jun 2015 17:33:19 +0000
Subject: [openssl-dev] RSA SigVer (FIPS 186-4) Issue
In-Reply-To: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>
References: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>
Message-ID: <20150629173319.GA13114@openssl.org>

On Mon, Jun 29, 2015, rsteck at symsysresearch.com wrote:

> I am getting incorrect False-Negative results when performing tests
> with 186-4 vectors (generated by CAVS 17.6).
> 
> This vector is being reported false while CAVS says they should pass.
> 
> [mod = 1024]
> n = d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009
> 
> SHAAlg = SHA512
> e = 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2acb
> Msg = 912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
> S = 122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3
> 
> I've added some debug output and I get the following:
> 
> DIGEST = 423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
> SIG = 122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
> N   = D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
> RR  = CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
> SUB = CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921CCCCDAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
> IR  = CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
> SigVer Result = 0
> 
> "RR" is the result of the power-E-mod-N operation, and "SUB" is the
> computed (N-RR) value.  "IR" is the choice of RR or (N-RR) used for
> the remainder of verification.
> 
> It seems clear to me that neither RR nor SUB has the correct form,
> and that this vector should not pass.
> 
> The lab is saying this must be a bug in OpenSSL, but no modification
> has been made that would introduce such a bug.  It's my contention
> that this is a bug in CAVS.  Can anyone shed some additional light
> onto the issue?
> 

Which padding mode is being used?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Mon Jun 29 20:03:40 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 29 Jun 2015 20:03:40 +0000
Subject: [openssl-dev] RSA SigVer (FIPS 186-4) Issue
In-Reply-To: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>
References: <b1a76c57b0730f43fc184627b2dc7e15@symsysresearch.com>
Message-ID: <20150629200340.GA14834@openssl.org>

On Mon, Jun 29, 2015, rsteck at symsysresearch.com wrote:

> I am getting incorrect False-Negative results when performing tests
> with 186-4 vectors (generated by CAVS 17.6).
> 
> This vector is being reported false while CAVS says they should pass.
> 
> [mod = 1024]
> n = d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009
> 
> SHAAlg = SHA512
> e = 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f2acb
> Msg = 912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
> S = 122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3
> 
> I've added some debug output and I get the following:
> 
> DIGEST = 423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
> SIG = 122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
> N   = D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
> RR  = CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
> SUB = CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921CCCCDAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
> IR  = CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
> SigVer Result = 0
> 
> "RR" is the result of the power-E-mod-N operation, and "SUB" is the
> computed (N-RR) value.  "IR" is the choice of RR or (N-RR) used for
> the remainder of verification.
> 
> It seems clear to me that neither RR nor SUB has the correct form,
> and that this vector should not pass.
> 
> The lab is saying this must be a bug in OpenSSL, but no modification
> has been made that would introduce such a bug.  It's my contention
> that this is a bug in CAVS.  Can anyone shed some additional light
> onto the issue?
> 

The Unix "dc" utility produces the same result. That's suggesting a problem
with the test data.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rt at openssl.org  Tue Jun 16 08:09:07 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 16 Jun 2015 08:09:07 -0000
Subject: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with
	Poly1305 TLS Cipher Suites via the EVP interface
In-Reply-To: <557FD99B.6080807@openssl.org>
References: <RT-Ticket-3615@openssl.org>
 <CAHEojpGtHra-U6cWTnp7pGfRfgb5r7ZLdznZnC5eZLdr-jLFng@mail.gmail.com>
 <rt-4.0.4-15078-1427718018-1486.3615-6-0@openssl.org>
 <555A08F0.8030508@openssl.org>
 <rt-4.0.4-21778-1431963898-111.3615-6-0@openssl.org>
 <5561D3B3.1060506@openssl.org>
 <rt-4.0.4-8169-1432474571-661.3615-6-0@openssl.org>
 <5569D08B.6000608@openssl.org>
 <rt-4.0.4-9273-1432998047-1760.3615-6-0@openssl.org>
 <557FD99B.6080807@openssl.org>
Message-ID: <rt-4.0.19-1594-1434442142-1221.3615-6-0@openssl.org>

>>> More coming in.

Attached are ARMv8 modules. It might be worth noting that small-block
performance of all presented Poly1305 modules can be improved by
postponing pre-computations for vector code. I mean provided that a)
non-vector initialization procedure is totally inexpensive, while b)
vector initialization takes equivalent of several blocks; you can win by
avoiding latter in cases when you have to process small amount of
blocks, even if they will be processed by slower non-vector procedure.
This can be easily arranged.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: chacha-armv8.pl
Type: application/x-perl
Size: 27172 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150616/52857f0b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: poly1305-armv8.pl
Type: application/x-perl
Size: 19899 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150616/52857f0b/attachment-0003.bin>

From rt at openssl.org  Thu Jun 18 13:09:00 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:09:00 -0000
Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add
	IPv4/IPv6:port-based client cache
In-Reply-To: <35AB40F7-8B3C-4012-ABCC-03B3AF3E0BBA@akamai.com>
References: <RT-Ticket-3883@openssl.org>
 <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com>
 <rt-4.0.4-5720-1432972092-1373.3883-21-0@openssl.org>
 <20150531060603.GX2342@mournblade.imrryr.org>
 <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <rt-4.0.4-19811-1433078843-1044.3883-6-0@openssl.org>
 <2962ADAC-4338-456B-AB99-434F74267B86@akamai.com>
 <rt-4.0.4-19777-1433079130-1027.3883-6-0@openssl.org>
 <35AB40F7-8B3C-4012-ABCC-03B3AF3E0BBA@akamai.com>
Message-ID: <rt-4.0.19-9054-1434632927-0.3883-6-0@openssl.org>

Updates to the IPv4/IPv6: port-based client cache patch:

Updated documentation, unit-tests and copyright.

Github link:
https://github.com/akamai/openssl/commit/0a9ec5fc896c0fdc417e60366d03c1d95cc53033

And attached patch.

Thank you.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0023-RT3883-Add-IPv4-IPv6-port-based-client-cache.patch
Type: application/octet-stream
Size: 84441 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/0f634dc2/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/0f634dc2/attachment-0001.htm>

From rt at openssl.org  Thu Jun 18 13:34:22 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:34:22 -0000
Subject: [openssl-dev] [openssl.org #3724] Patch/Feature to add
	asynchronous processing for some operations
In-Reply-To: <A86899E5-0FDC-49D4-A188-5050DA62E7CD@akamai.com>
References: <RT-Ticket-3724@openssl.org>
 <81070344-6715-47E7-9BE6-F007FE307535@akamai.com>
 <rt-4.0.4-21159-1425068066-641.3724-21-0@openssl.org>
 <C2CE4172-C5F5-48B0-A2A9-C42B22D5BA71@akamai.com>
 <rt-4.0.4-19108-1432655180-70.3724-6-0@openssl.org>
 <A86899E5-0FDC-49D4-A188-5050DA62E7CD@akamai.com>
Message-ID: <rt-4.0.19-9054-1434634449-559.3724-6-0@openssl.org>

Hello,

Again, we have an updated patch for asynchronous processing: unit-tests and copyright.

Github link:
https://github.com/akamai/openssl/commit/92914accbb54ee085918451468575a5e76baba20

And attached file.

Thanks,

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-RT3724-Add-asynchronous-event-processing.patch
Type: application/octet-stream
Size: 106289 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/b96df8cf/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/b96df8cf/attachment-0001.htm>

From rt at openssl.org  Thu Jun 18 13:40:52 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Thu, 18 Jun 2015 13:40:52 -0000
Subject: [openssl-dev] [openssl.org #3729] Patch to add support for
	iovec-based IO in OpenSSL
In-Reply-To: <4CA92387-F48B-467E-94E8-ECEA8401C2F8@akamai.com>
References: <RT-Ticket-3729@openssl.org>
 <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com>
 <F93C21C9-51A3-4EBD-A652-95234B66CE05@akamai.com>
 <rt-4.0.4-30420-1425654123-33.3729-21-0@openssl.org>
 <068B2EAF-7258-401C-8B66-1F04611352BD@akamai.com>
 <4CA92387-F48B-467E-94E8-ECEA8401C2F8@akamai.com>
Message-ID: <rt-4.0.19-9054-1434634839-451.3729-6-0@openssl.org>

Hello,

We have another update for this patch: updates to documentation and APIs.

Github link:

https://github.com/akamai/openssl/commit/a6086d9cdde13a8b5ce22cbdcef3fe8733d0e892

And attachment:

Thanks,

--
-Todd Short
// tshort at akamai.com
// "One if by land, two if by sea, three if by the Internet."


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0009-RT3729-Add-iovec-based-I-O-routines.patch
Type: application/octet-stream
Size: 52490 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/fffc6fdd/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150618/fffc6fdd/attachment-0001.htm>

From rt at openssl.org  Fri Jun 19 01:50:41 2015
From: rt at openssl.org (Michael Wager via RT)
Date: Fri, 19 Jun 2015 01:50:41 -0000
Subject: [openssl-dev] [openssl.org #3916] [PATCH] Fix Uninitialized Values
In-Reply-To: <OFFFE34A56.A21F1D75-ON48257E69.00089326-48257E69.0009C527@au1.ibm.com>
References: <RT-Ticket-3916@openssl.org>
 <OFFFE34A56.A21F1D75-ON48257E69.00089326-48257E69.0009C527@au1.ibm.com>
Message-ID: <rt-4.0.19-14964-1434678634-1310.3916-21-0@openssl.org>

Hello

When I ran openSSL 1.0.1k under valgrind, it showed up 3 memory errors 
(below). 
I have attached a patch for 1.0.1o and verified that these errors no 
longer occur:


==30323== Conditional jump or move depends on uninitialised value(s)
==30323==    at 0x80C943F: ssl3_read_bytes (s3_pkt.c:1091)
==30323==    by 0x80CA0C2: ssl3_get_message (s3_both.c:539)
==30323==    by 0x80C9A55: ssl3_get_finished (s3_both.c:246)
==30323==    by 0x80C3586: ssl3_connect (s3_clnt.c:549)
==30323==    by 0x80DA5BB: SSL_connect (ssl_lib.c:943)
==30323==    by 0x80B9585: openSSLConnectionPb (ssl_connection.c:524)
==30323==    by 0x4050681: commsOpenClientSocket (bClientSocket.c:126)
==30323==    by 0x404F1A4: commsThread (smcomms.c:812)
==30323==    by 0x4529A48: start_thread (in /lib/libpthread-2.12.so)
==30323==    by 0x21CE1D: clone (in /lib/libc-2.12.so)
==30323==  Uninitialised value was created by a heap allocation
==30323==    at 0x40072B2: malloc (vg_replace_malloc.c:270)
==30323==    by 0x80F244B: default_malloc_ex (mem.c:79)
==30323==    by 0x80F29D7: CRYPTO_malloc (mem.c:312)
==30323==    by 0x81179E3: EVP_DigestInit_ex (digest.c:210)
==30323==    by 0x80FDA44: HMAC_Init_ex (hmac.c:130)
==30323==    by 0x815307D: pkey_hmac_ctrl (hm_pmeth.c:198)
==30323==    by 0x81207A6: EVP_PKEY_CTX_ctrl (pmeth_lib.c:408)
==30323==    by 0x811798D: EVP_DigestInit_ex (digest.c:225)
==30323==    by 0x8121C78: do_sigver_init (m_sigver.c:114)
==30323==    by 0x80D1679: tls1_PRF (t1_enc.c:179)

==29489== Conditional jump or move depends on uninitialised value(s)
==29489==    at 0x8171D09: RSA_padding_add_PKCS1_type_2 (rsa_pk1.c:169)
==29489==    by 0x816FF08: RSA_eay_public_encrypt (rsa_eay.c:198)
==29489==    by 0x810EBC2: RSA_public_encrypt (rsa_crpt.c:86)
==29489==    by 0x80C1723: ssl3_send_client_key_exchange (s3_clnt.c:2410)
==29489==    by 0x80C35C8: ssl3_connect (s3_clnt.c:406)
==29489==    by 0x80DA5BB: SSL_connect (ssl_lib.c:943)
==29489==    by 0x80CD21B: ssl23_connect (s23_clnt.c:805)
==29489==    by 0x80DA5D2: SSL_connect (ssl_lib.c:943)
==29489==    by 0x80B9585: openSSLConnectionPb (ssl_connection.c:524)
==29489==    by 0x4050681: commsOpenClientSocket (bClientSocket.c:126)
==29489==    by 0x404F1A4: commsThread (smcomms.c:812)
==29489==    by 0x4529A48: start_thread (in /lib/libpthread-2.12.so)
==29489==  Uninitialised value was created by a heap allocation
==29489==    at 0x40072B2: malloc (vg_replace_malloc.c:270)
==29489==    by 0x80F244B: default_malloc_ex (mem.c:79)
==29489==    by 0x80F29D7: CRYPTO_malloc (mem.c:312)
==29489==    by 0x816FCEA: RSA_eay_public_encrypt (rsa_eay.c:188)
==29489==    by 0x810EBC2: RSA_public_encrypt (rsa_crpt.c:86)
==29489==    by 0x80C1723: ssl3_send_client_key_exchange (s3_clnt.c:2410)
==29489==    by 0x80C35C8: ssl3_connect (s3_clnt.c:406)
==29489==    by 0x80DA5BB: SSL_connect (ssl_lib.c:943)
==29489==    by 0x80CD21B: ssl23_connect (s23_clnt.c:805)
==29489==    by 0x80DA5D2: SSL_connect (ssl_lib.c:943)
==29489==    by 0x80B9585: openSSLConnectionPb (ssl_connection.c:524)
==29489==    by 0x4050681: commsOpenClientSocket (bClientSocket.c:126)

==5127== Conditional jump or move depends on uninitialised value(s)
==5127==    at 0x8171D09: RSA_padding_add_PKCS1_type_2 (rsa_pk1.c:169)
==5127==    by 0x816FFF8: RSA_eay_public_encrypt (rsa_eay.c:199)
==5127==    by 0x810EBC2: RSA_public_encrypt (rsa_crpt.c:86)
==5127==    by 0x80C1723: ssl3_send_client_key_exchange (s3_clnt.c:2411)
==5127==    by 0x80C35C8: ssl3_connect (s3_clnt.c:406)
==5127==    by 0x80DA5BB: SSL_connect (ssl_lib.c:943)
==5127==    by 0x80CD21B: ssl23_connect (s23_clnt.c:805)
==5127==    by 0x80DA5D2: SSL_connect (ssl_lib.c:943)
==5127==    by 0x80B9585: openSSLConnectionPb (ssl_connection.c:524)
==5127==    by 0x4050681: commsOpenClientSocket (bClientSocket.c:126)
==5127==    by 0x404F1A4: commsThread (smcomms.c:812)
==5127==    by 0x4529A48: start_thread (in /lib/libpthread-2.12.so)
==5127==  Uninitialised value was created by a stack allocation
==5127==    at 0x80C1626: ssl3_send_client_key_exchange (s3_clnt.c:2341)

Thanks,
Michael



Michael Wager
 L2 1060 Hay St

Staff Software Engineer
 West Perth, 6005
Australia Development Laboratory (ADL)
 Australia
IBM Software Group, Tivoli
 

Phone:
+61-8-92618684
 

e-mail:
mwager at au1.ibm.com
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150619/a0b2374b/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mydiffs.patch
Type: application/octet-stream
Size: 1475 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150619/a0b2374b/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mydiffs.patch.zip
Type: application/zip
Size: 71094 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150619/a0b2374b/attachment-0001.zip>
-------------- next part --------------
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod