From levitte at openssl.org  Tue Nov  1 09:54:39 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 01 Nov 2016 10:54:39 +0100 (CET)
Subject: [openssl-dev] Still seeing test failure in openssl 1.0.2
 SNAPHOT 20161031
In-Reply-To: <20161031142938.GA97772@doctor.nl2k.ab.ca>
References: <20161031142938.GA97772@doctor.nl2k.ab.ca>
Message-ID: <20161101.105439.1148965401617886766.levitte@openssl.org>

I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and
in both cases, that test goes through with no trouble at all.

Could you tell us your exact configuration?  If I recall correctly,
you have your own hacked configuration, right?

Cheers,
Richard

In message <20161031142938.GA97772 at doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 08:29:38 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:

doctor> I saw this yesterday as well
doctor> 
doctor> ../util/shlib_wrap.sh ./heartbeat_test
doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1
doctor> ** test_dtls1_not_bleeding failed **
doctor> --------
doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
doctor> ** test_dtls1_not_bleeding_empty_payload failed **
doctor> --------
doctor> test_tls1_not_bleeding failed: expected return value 0, received -1
doctor> ** test_tls1_not_bleeding failed **
doctor> --------
doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
doctor> ** test_tls1_not_bleeding_empty_payload failed **
doctor> --------
doctor> 4 tests failed
doctor> *** Error code 1
doctor> 
doctor> Stop.
doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
doctor> *** Error code 1
doctor> 
doctor> Please fix
doctor> 
doctor> -- 
doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
doctor> God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
doctor> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
doctor> Time for the USA to hold a referendum on its republic and vote to dissolve!! 
doctor> -- 
doctor> openssl-dev mailing list
doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
doctor> 

From doctor at doctor.nl2k.ab.ca  Tue Nov  1 14:11:09 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 1 Nov 2016 08:11:09 -0600
Subject: [openssl-dev] Still seeing test failure in openssl 1.0.2
 SNAPHOT 20161031
In-Reply-To: <20161101.105439.1148965401617886766.levitte@openssl.org>
References: <20161031142938.GA97772@doctor.nl2k.ab.ca>
 <20161101.105439.1148965401617886766.levitte@openssl.org>
Message-ID: <20161101141109.GD27402@doctor.nl2k.ab.ca>

On Tue, Nov 01, 2016 at 10:54:39AM +0100, Richard Levitte wrote:
> I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and
> in both cases, that test goes through with no trouble at all.
> 
> Could you tell us your exact configuration?  If I recall correctly,
> you have your own hacked configuration, right?
> 
> Cheers,
> Richard

Certainly,

My configuration script is


#!/usr/local/bin/bash
CC=/usr/local/bin/clang39  ./Configure --prefix=/usr/ BSD-x86_64 enable-gmp experimental-jpake enable-rfc3779 enable-shared zlib-dynamic disable-sctp experimental-store enable-ssl-trace enable-unit-test; make depend

> 
> In message <20161031142938.GA97772 at doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 08:29:38 -0600, The Doctor <doctor at doctor.nl2k.ab.ca> said:
> 
> doctor> I saw this yesterday as well
> doctor> 
> doctor> ../util/shlib_wrap.sh ./heartbeat_test
> doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1
> doctor> ** test_dtls1_not_bleeding failed **
> doctor> --------
> doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
> doctor> ** test_dtls1_not_bleeding_empty_payload failed **
> doctor> --------
> doctor> test_tls1_not_bleeding failed: expected return value 0, received -1
> doctor> ** test_tls1_not_bleeding failed **
> doctor> --------
> doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
> doctor> ** test_tls1_not_bleeding_empty_payload failed **
> doctor> --------
> doctor> 4 tests failed
> doctor> *** Error code 1
> doctor> 
> doctor> Stop.
> doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
> doctor> *** Error code 1
> doctor> 
> doctor> Please fix
> doctor> 
> doctor> -- 
> doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
> doctor> God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
> doctor> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
> doctor> Time for the USA to hold a referendum on its republic and vote to dissolve!! 
> doctor> -- 
> doctor> openssl-dev mailing list
> doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> doctor> 

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From sebastian.kloska at snafu.de  Tue Nov  1 15:28:18 2016
From: sebastian.kloska at snafu.de (Sebastian Kloska)
Date: Tue, 1 Nov 2016 16:28:18 +0100
Subject: [openssl-dev] Problems with cert authentication under Turkish locale
Message-ID: <3a2fe67c-c3a1-4133-3bcd-47946a5c87ca@snafu.de>

Hi,

We have problems authenticating a a CERT while LC_CTYPE is set to 
tr_TR.UTF-8

The issue is triggered in libcurl but it seems to come out of libssl. It 
seems to be

related to http://mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug

Sample code below. We link against libssl 1.0.1s. Is this a known issue 
? Would

it help to switch to a newer Version ?

Any help is highly apprecjaited....



<snip>



#include <string>
#include <iostream>
#include <stdio.h>

#include <curl/curl.h>

void doCurlCall()
{
     std::cout << "Running with LC_CTYPE: " << setlocale(LC_CTYPE, NULL) 
<< std::endl;

     CURL *curl = curl_easy_init();

     curl_easy_setopt(curl, CURLOPT_URL, "https://www.hotmail.com");

     curl_easy_setopt(curl, CURLOPT_CAPATH, "/opt/etc/ssl/certs/");
     curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);


     CURLcode res = curl_easy_perform(curl);
     if(res == CURLE_OK)
     {
         std::cout << std::endl << "curl_easy_perform() succeeded" << 
std::endl;
     }
     else
     {
         std::cout << std::endl << "curl_easy_perform() failed: " << 
curl_easy_strerror(res) << std::endl;
     }
     curl_easy_cleanup(curl);
}

int main(int /*argc*/, char ** /*argv*/)
{
     setlocale(LC_CTYPE, "tr_TR.UTF-8");

     curl_global_init(CURL_GLOBAL_DEFAULT);

     // This call will fail with curl error:
     // Peer certificate cannot be authenticated with given CA certificates
     doCurlCall();

     setlocale(LC_CTYPE, "C");

     // This call will pass
     doCurlCall();

     curl_global_cleanup();
     return 0;
}


</snip>

-- 
**********************************
Dr. Sebastian Kloska
Hohenstaufenstr. 67
10781   Berlin
Handy:  +49-176-24621622
web:    www.oncaphillis.net
e-mail: sebastian.kloska at snafu.de
**********************************


From ishanthakur41 at yahoo.in  Wed Nov  2 13:57:47 2016
From: ishanthakur41 at yahoo.in (Ishan Thakur)
Date: Wed, 2 Nov 2016 13:57:47 +0000 (UTC)
Subject: [openssl-dev] OpenSSL 1.0.2h generates libss.so.1.0.0 instead of
	libssl.so.1.0.2
In-Reply-To: <255566131.718665.1478094069885@mail.yahoo.com>
References: <209029889.714083.1478093016087.ref@mail.yahoo.com>
 <209029889.714083.1478093016087@mail.yahoo.com>
 <255566131.718665.1478094069885@mail.yahoo.com>
Message-ID: <1296217267.724136.1478095067639@mail.yahoo.com>





Hi ,??? Why Building OpenSSL 1.0.2h generates libss.so.1.0.0/libcrypto.so.1.0.0 and not libssl.so.1.0.2/libcrypto.so.1.0.2 ?
Regards,Ishan



   

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

From levitte at openssl.org  Wed Nov  2 14:33:32 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 02 Nov 2016 15:33:32 +0100 (CET)
Subject: [openssl-dev] OpenSSL 1.0.2h generates libss.so.1.0.0 instead
 of libssl.so.1.0.2
In-Reply-To: <1296217267.724136.1478095067639@mail.yahoo.com>
References: <209029889.714083.1478093016087@mail.yahoo.com>
 <255566131.718665.1478094069885@mail.yahoo.com>
 <1296217267.724136.1478095067639@mail.yahoo.com>
Message-ID: <20161102.153332.2107102420662275291.levitte@openssl.org>

In message <1296217267.724136.1478095067639 at mail.yahoo.com> on Wed, 2 Nov 2016 13:57:47 +0000 (UTC), Ishan Thakur <ishanthakur41 at yahoo.in> said:

ishanthakur41> Hi ,
ishanthakur41> Why Building OpenSSL 1.0.2h generates
ishanthakur41> libss.so.1.0.0/libcrypto.so.1.0.0 and not
ishanthakur41> libssl.so.1.0.2/libcrypto.so.1.0.2 ?

Shared library versions aren't the same as software versions.  As long
as shared libraries are backward compatible on the ABI level, you
maintain the same shared library version.

We recognised that our shared library version numbering was confusing,
so from OpenSSL version 1.1.0 and up, the shared library version
retains the two first digits of the OpenSSL version only, which
reflects our intent that for any versions x.y.z where x.y stays the
same, ABI backward compatibility will be maintained.

Cheers,
Richard

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

From doctor at doctor.nl2k.ab.ca  Wed Nov  2 14:47:48 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 2 Nov 2016 08:47:48 -0600
Subject: [openssl-dev] iStill seeing heartbeat prolem in openssl 1.0.2
	STABLE Daily releases
Message-ID: <20161102144748.GA13285@doctor.nl2k.ab.ca>

Why is this not solved?

../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value 0, received -1
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value 0, received -1
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.

Using FreeBSD 11 .

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From matt at openssl.org  Wed Nov  2 16:45:11 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 2 Nov 2016 16:45:11 +0000
Subject: [openssl-dev] iStill seeing heartbeat prolem in openssl 1.0.2
 STABLE Daily releases
In-Reply-To: <20161102144748.GA13285@doctor.nl2k.ab.ca>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
Message-ID: <4c466d0c-91c6-61c0-82d7-8baed3685775@openssl.org>



On 02/11/16 14:47, The Doctor wrote:
> Why is this not solved?
> 
> ../util/shlib_wrap.sh ./v3nametest
> ../util/shlib_wrap.sh ./heartbeat_test
> test_dtls1_not_bleeding failed: expected return value 0, received -1
> ** test_dtls1_not_bleeding failed **
> --------
> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
> ** test_dtls1_not_bleeding_empty_payload failed **
> --------
> test_tls1_not_bleeding failed: expected return value 0, received -1
> ** test_tls1_not_bleeding failed **
> --------
> test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
> ** test_tls1_not_bleeding_empty_payload failed **
> --------
> 4 tests failed
> *** Error code 1
> 
> Stop.
> 
> Using FreeBSD 11 .
> 

Fix is here:

https://github.com/openssl/openssl/pull/1826

Matt

From doctor at doctor.nl2k.ab.ca  Wed Nov  2 16:50:37 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 2 Nov 2016 10:50:37 -0600
Subject: [openssl-dev] iStill seeing heartbeat prolem in openssl 1.0.2
 STABLE Daily releases
In-Reply-To: <4c466d0c-91c6-61c0-82d7-8baed3685775@openssl.org>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
 <4c466d0c-91c6-61c0-82d7-8baed3685775@openssl.org>
Message-ID: <20161102165037.GA2358@doctor.nl2k.ab.ca>

On Wed, Nov 02, 2016 at 04:45:11PM +0000, Matt Caswell wrote:
> 
> 
> On 02/11/16 14:47, The Doctor wrote:
> > Why is this not solved?
> > 
> > ../util/shlib_wrap.sh ./v3nametest
> > ../util/shlib_wrap.sh ./heartbeat_test
> > test_dtls1_not_bleeding failed: expected return value 0, received -1
> > ** test_dtls1_not_bleeding failed **
> > --------
> > test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
> > ** test_dtls1_not_bleeding_empty_payload failed **
> > --------
> > test_tls1_not_bleeding failed: expected return value 0, received -1
> > ** test_tls1_not_bleeding failed **
> > --------
> > test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
> > ** test_tls1_not_bleeding_empty_payload failed **
> > --------
> > 4 tests failed
> > *** Error code 1
> > 
> > Stop.
> > 
> > Using FreeBSD 11 .
> > 
> 
> Fix is here:
> 
> https://github.com/openssl/openssl/pull/1826

I usually use lynx and cannot see where to pull this.

I assume tomorrow  This can be tested i nthe daily snapshot?

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From rsalz at akamai.com  Wed Nov  2 17:00:27 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 2 Nov 2016 17:00:27 +0000
Subject: [openssl-dev] iStill seeing heartbeat prolem in openssl
	1.0.2	STABLE Daily releases
In-Reply-To: <20161102144748.GA13285@doctor.nl2k.ab.ca>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
Message-ID: <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com>


> Why is this not solved?

It will be solved before the next release.  No further promises.

From doctor at doctor.nl2k.ab.ca  Wed Nov  2 17:04:46 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 2 Nov 2016 11:04:46 -0600
Subject: [openssl-dev] [openssl-users] iStill seeing heartbeat prolem in
 openssl 1.0.2	STABLE Daily releases
In-Reply-To: <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
 <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161102170446.GB4023@doctor.nl2k.ab.ca>

On Wed, Nov 02, 2016 at 05:00:27PM +0000, Salz, Rich wrote:
> 
> > Why is this not solved?
> 
> It will be solved before the next release.  No further promises.

I will report back tomorrow.

Still It is a good thing to gripe if you see an issue.

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From matt at openssl.org  Wed Nov  2 17:07:17 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 2 Nov 2016 17:07:17 +0000
Subject: [openssl-dev] [openssl-users] iStill seeing heartbeat prolem in
 openssl 1.0.2 STABLE Daily releases
In-Reply-To: <20161102170446.GB4023@doctor.nl2k.ab.ca>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
 <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161102170446.GB4023@doctor.nl2k.ab.ca>
Message-ID: <bbf6b724-4443-39fb-aab7-0cf140e2595c@openssl.org>



On 02/11/16 17:04, The Doctor wrote:
> On Wed, Nov 02, 2016 at 05:00:27PM +0000, Salz, Rich wrote:
>>
>>> Why is this not solved?
>>
>> It will be solved before the next release.  No further promises.
> 
> I will report back tomorrow.
> 
> Still It is a good thing to gripe if you see an issue.

The fix is now in git.

Matt


From rsalz at akamai.com  Wed Nov  2 17:07:50 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 2 Nov 2016 17:07:50 +0000
Subject: [openssl-dev] [openssl-users] iStill seeing heartbeat prolem in
 openssl 1.0.2	STABLE Daily releases
In-Reply-To: <20161102170446.GB4023@doctor.nl2k.ab.ca>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
 <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161102170446.GB4023@doctor.nl2k.ab.ca>
Message-ID: <a5fbc3b28aca46f8afcdc282a6e26080@usma1ex-dag1mb1.msg.corp.akamai.com>


> Still It is a good thing to gripe if you see an issue.

Yup.  But maybe every other day? :)

From ssx at av8n.com  Wed Nov  2 17:16:43 2016
From: ssx at av8n.com (John Denker)
Date: Wed, 2 Nov 2016 10:16:43 -0700
Subject: [openssl-dev] github raw .patch ... also: still seeing
 heartbeat prolem in openssl 1.0.2 STABLE Daily releases
In-Reply-To: <20161102165037.GA2358@doctor.nl2k.ab.ca>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
 <4c466d0c-91c6-61c0-82d7-8baed3685775@openssl.org>
 <20161102165037.GA2358@doctor.nl2k.ab.ca>
Message-ID: <7613644d-22ce-adeb-732d-a71632833805@av8n.com>

On 11/02/2016 09:50 AM, The Doctor wrote:

> I usually use lynx and cannot see where to pull this.

AFAICT here is the relevant patch, in a raw form suitable for
direct download:

  https://github.com/openssl/openssl/commit/554ae58d09a9b09fa430553c3e6ba5bb5433150c.patch

In general, the procedure goes like this:
 Given the URL of the PR, go there.
   For example, https://github.com/openssl/openssl/pull/1826
 Click on the "Commits" tag
 In the list of commits, click on the SHA1 of the commit.
 (That is *not* the same as clicking on the name of the commit.)
   Example result: https://github.com/openssl/openssl/commits/554ae58d09a9b09fa430553c3e6ba5bb5433150c
 Munge the URL by changing /commits/ to /commit/ singular,
 and by adding .patch to the end.

Truly an astonishing user interface.


From doctor at doctor.nl2k.ab.ca  Wed Nov  2 19:24:08 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 2 Nov 2016 13:24:08 -0600
Subject: [openssl-dev] [openssl-users] iStill seeing heartbeat prolem in
 openssl 1.0.2	STABLE Daily releases
In-Reply-To: <a5fbc3b28aca46f8afcdc282a6e26080@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161102144748.GA13285@doctor.nl2k.ab.ca>
 <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161102170446.GB4023@doctor.nl2k.ab.ca>
 <a5fbc3b28aca46f8afcdc282a6e26080@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161102192408.GA60272@doctor.nl2k.ab.ca>

On Wed, Nov 02, 2016 at 05:07:50PM +0000, Salz, Rich wrote:
> 
> > Still It is a good thing to gripe if you see an issue.
> 
> Yup.  But maybe every other day? :)

Well I did bring this to your attention 3 days ago.

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From ishanthakur41 at yahoo.in  Thu Nov  3 11:29:53 2016
From: ishanthakur41 at yahoo.in (Ishan Thakur)
Date: Thu, 3 Nov 2016 11:29:53 +0000 (UTC)
Subject: [openssl-dev] After building 1.0.2h ,
 ldd output shows current version as 1.0.0. How to CHange this ,
 Why is this so ?
References: <1501043604.654494.1478172593718.ref@mail.yahoo.com>
Message-ID: <1501043604.654494.1478172593718@mail.yahoo.com>

Hi , 
When I run "otool -L in MAC" , or "ldd in linux" machines I get the current     version of OpenSSL as 1.0.0 but I have built OpenSSL v1.0.2h , how to change this "current version" in the libraries.$  otool -L ./libssl.dylib
   libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)

Regards,
Ishan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161103/84121322/attachment.html>

From levitte at openssl.org  Thu Nov  3 12:53:56 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 03 Nov 2016 13:53:56 +0100 (CET)
Subject: [openssl-dev] After building 1.0.2h ,
 ldd output shows current version as 1.0.0. How to CHange this ,
 Why is this so ?
In-Reply-To: <1501043604.654494.1478172593718@mail.yahoo.com>
References: <1501043604.654494.1478172593718.ref@mail.yahoo.com>
 <1501043604.654494.1478172593718@mail.yahoo.com>
Message-ID: <20161103.135356.1571694957013623952.levitte@openssl.org>

Hi,

I'm curious.  Why exactly do you want to change the shared library
version?

That being said, this is not a good idea.  I hope I explained why well
enough in the thread with the subject "OpenSSL 1.0.2h generates
libss.so.1.0.0 instead of libssl.so.1.0.2" started by you on
openssl-dev.  For reference, you can find my answer here:
https://mta.openssl.org/pipermail/openssl-dev/2016-November/008665.html

Cheers,
Richard

In message <1501043604.654494.1478172593718 at mail.yahoo.com> on Thu, 3 Nov 2016 11:29:53 +0000 (UTC), Ishan Thakur <ishanthakur41 at yahoo.in> said:

ishanthakur41> Hi ,
ishanthakur41> When I run "otool -L in MAC" , or "ldd in linux" machines I get the current     version of OpenSSL as 1.0.0 but I have built OpenSSL v1.0.2h , how to change this "current version" in the libraries.
ishanthakur41> $  otool -L ./libssl.dylib
ishanthakur41>    libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
ishanthakur41> 
ishanthakur41> Regards,
ishanthakur41> Ishan

From bkaduk at akamai.com  Thu Nov  3 20:11:10 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 3 Nov 2016 15:11:10 -0500
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <5694008D.20502@openssl.org>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <etPan.56916cfb.2c504d53.192@atlas.local>
 <f303ae3446014e1385c9b79e4a205658@usma1ex-dag1mb1.msg.corp.akamai.com>
 <201601110110.u0B1A1JX029122@d23av03.au.ibm.com>
 <1452507792.23391.2.camel@redhat.com>
 <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org>
 <5694008D.20502@openssl.org>
Message-ID: <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>

To revitalize an old thread (quoted below but summarized here), some
applications may desire source-code compatibility between the 1.0.2 API
and the 1.1.0 API.  It seems like the sense of the team is that such
accessor functions (or macros) should not be committed into the official
1.0.2 tree, but that the community could maintain an external
compatibility shim.  Is that correct?

Does anyone already have such a compatibility header, or thoughts about
where it should/could reside?

We have been noticing that a lot of accessor implementations can be
backported as static inline functions to a compatibility header or
headers with no further modification.  (But not all, as, e.g., HMAC_CTX
has changed to hold pointers instead of embedded structs.)

-Ben

On 01/11/2016 01:20 PM, Matt Caswell wrote:
>
> On 11/01/16 18:29, Viktor Dukhovni wrote:
>>> On Jan 11, 2016, at 5:23 AM, Tomas Mraz <tmraz at redhat.com> wrote:
>>>
>>> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote:
>>>> The point of using accessor FUNCTIONS is that the code doesn't break
>>>> if the structure size or offsets of fields in the underlying
>>>> structures change across binaries.
>>>>
>>>> Where that mainly has an impact is updating the crypto/ssl libs
>>>> underneath existing binaries is more likely to just work.
>>>>
>>>> #defines in the headers do not help at all here.
>>>>
>>> The point is in achieving reverse API compatibility between 1.1 and
>>> 1.0.2. No binary compatibility is expected between those branches.
>>>
>>> I think that having the API compatibility would be really useful thing
>>> easing porting application code to 1.1 branch.
>> Yes, although in practice may users of 1.0.x will have previous releases
>> that don't have the accessors, so the issue is difficult to address
>> retroactively in OpenSSL.  In Postfix, I add the macros myself:
>>
>> #if OPENSSL_VERSION_NUMBER < 0x10100000L
>> #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509))
>> #endif
>>
>> Which means that interestingly enough adding these to 1.0.x would break
>> my code and similar code elsewhere.
>>
>> So on the whole forward-compatibility macros don't fully address the
>> problem, and may do as much harm as good.
>>
>> I think that applications porting to 1.1.0 can and should implement
>> their own macros against a stable 1.0.x API that we don't change
>> at the last minute.  Providing your own forward-compatible glue
>> is easy enough...
>>
> Perhaps someone from the community could contribute a (separately
> maintained) compatibility layer to provide the relevant macros?
>
> 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/20161103/6538422b/attachment-0001.html>

From rsalz at akamai.com  Thu Nov  3 20:15:06 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 3 Nov 2016 20:15:06 +0000
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <etPan.56916cfb.2c504d53.192@atlas.local>
 <f303ae3446014e1385c9b79e4a205658@usma1ex-dag1mb1.msg.corp.akamai.com>
 <201601110110.u0B1A1JX029122@d23av03.au.ibm.com>
 <1452507792.23391.2.camel@redhat.com>
 <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org>
 <5694008D.20502@openssl.org>
 <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
Message-ID: <13c4190e93764e508f5996d8d56914f8@usma1ex-dag1mb1.msg.corp.akamai.com>

I hope that Daniel from CURL will speak up, and perhaps Richard from Qt.

I think a new header file, like ?openssl110compat.h? or something, hosted in a public repo would be great.  We could point to it in the 1.0.2 README, for example.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161103/81c1ef37/attachment.html>

From rsalz at akamai.com  Thu Nov  3 20:25:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 3 Nov 2016 20:25:03 +0000
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
	earlear
In-Reply-To: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
References: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
Message-ID: <7fb2100f99b846e8b75aaddbef72dd4e@usma1ex-dag1mb1.msg.corp.akamai.com>

You can decrypt old files by adding -md5 flag.

From openssl-dev at ml.breakpoint.cc  Thu Nov  3 20:29:00 2016
From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior)
Date: Thu, 3 Nov 2016 21:29:00 +0100
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
	earlear
In-Reply-To: <7fb2100f99b846e8b75aaddbef72dd4e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
 <7fb2100f99b846e8b75aaddbef72dd4e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161103202900.qzzts5zibhbj4mrv@breakpoint.cc>

On 2016-11-03 20:25:03 [+0000], Salz, Rich wrote:
> You can decrypt old files by adding -md5 flag.

Yes, I know. That is what suggested in Debian bug report. But if I close
this bug report with this information someone will run into it again.
The problem is that scripts will fail without a proper explanation.
So I ask here if it would be okay add a fallback. If not, the worstcase
scenario would be to add this hint to the error message.
But if it can work without it, it would be great.

Sebastian

From deengert at gmail.com  Thu Nov  3 20:31:00 2016
From: deengert at gmail.com (Douglas E Engert)
Date: Thu, 3 Nov 2016 15:31:00 -0500
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <etPan.56916cfb.2c504d53.192@atlas.local>
 <f303ae3446014e1385c9b79e4a205658@usma1ex-dag1mb1.msg.corp.akamai.com>
 <201601110110.u0B1A1JX029122@d23av03.au.ibm.com>
 <1452507792.23391.2.camel@redhat.com>
 <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org>
 <5694008D.20502@openssl.org>
 <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
Message-ID: <9b46ca6b-1391-2c17-0c74-cef062300158@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161103/d2a7f803/attachment.html>

From openssl-dev at ml.breakpoint.cc  Thu Nov  3 20:23:50 2016
From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior)
Date: Thu, 3 Nov 2016 21:23:50 +0100
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
	earlear
Message-ID: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>

Commit f8547f62c21 ("Use SHA256 not MD5 as default digest") changed the
default hash from md5 to sha256.
This leads to bug reports like this [0] where people can't access their
old encrypted files.
Would it work for if MD5 is tried if the now default options fails the
encryption? I see some output on the console before openssl's error
shows up so it does not look like a one liner.

[0] bugs.debian.org/843064

Sebastian

From levitte at openssl.org  Thu Nov  3 21:12:44 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 03 Nov 2016 22:12:44 +0100 (CET)
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
 earlear
In-Reply-To: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
References: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
Message-ID: <20161103.221244.1967755962836083402.levitte@openssl.org>

In message <20161103202349.ub4aq27wzv4whvay at breakpoint.cc> on Thu, 3 Nov 2016 21:23:50 +0100, Sebastian Andrzej Siewior <openssl-dev at ml.breakpoint.cc> said:

openssl-dev> Commit f8547f62c21 ("Use SHA256 not MD5 as default digest") changed the
openssl-dev> default hash from md5 to sha256.
openssl-dev> This leads to bug reports like this [0] where people can't access their
openssl-dev> old encrypted files.
openssl-dev> Would it work for if MD5 is tried if the now default options fails the
openssl-dev> encryption? I see some output on the console before openssl's error
openssl-dev> shows up so it does not look like a one liner.
openssl-dev> 
openssl-dev> [0] bugs.debian.org/843064

That would be quite a job.  The correctness of the key can't be
discovered before the last encrypted block, where the decrypted
padding will either be correct (because it was the right key) or not
(because it was the wrong key).  Take into account a pipe with a 10MB
file, I'm sure you see where that takes us.

The solution in that bug report seems sane, even though unfortunate.

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

From mort at bork.org  Fri Nov  4 12:30:21 2016
From: mort at bork.org (Martin Hicks)
Date: Fri, 4 Nov 2016 08:30:21 -0400
Subject: [openssl-dev] Engine support for HMAC sha
Message-ID: <CAJUS3XkTMPnapQiXkfdvZsgeQY4ZxgQfd8X1TVLtdnRh54VP2A@mail.gmail.com>

Hi,

I have hardware that supports doing HMAC for sha1 and sha2.  Is there any
way to offload the entire hmac operation via the ENGINE?  It seems like I
can offload the digests, but I'm not seeing how to do it for the entire
HMAC operation.

Thanks,
mh

-- 
Martin Hicks P.Eng.      |         mort at bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161104/46781e7f/attachment-0001.html>

From kurt at roeckx.be  Fri Nov  4 16:05:58 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 4 Nov 2016 17:05:58 +0100
Subject: [openssl-dev] After building 1.0.2h ,
 ldd output shows current version as 1.0.0. How to CHange this ,
 Why is this so ?
In-Reply-To: <20161103.135356.1571694957013623952.levitte@openssl.org>
References: <1501043604.654494.1478172593718.ref@mail.yahoo.com>
 <1501043604.654494.1478172593718@mail.yahoo.com>
 <20161103.135356.1571694957013623952.levitte@openssl.org>
Message-ID: <20161104160558.sgubm5wnmaxgmyvx@roeckx.be>

On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote:
> Hi,
> 
> I'm curious.  Why exactly do you want to change the shared library
> version?

I had to change the soname in Debian (because I dropped all SSLv2  
and SSLv3 symbols) and changed it to 1.0.2.


Kurt


From openssl-dev at ml.breakpoint.cc  Fri Nov  4 20:59:33 2016
From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior)
Date: Fri, 4 Nov 2016 21:59:33 +0100
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
 earlear
In-Reply-To: <20161103.221244.1967755962836083402.levitte@openssl.org>
References: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
 <20161103.221244.1967755962836083402.levitte@openssl.org>
Message-ID: <20161104205933.gw7pyvclnmdkvd73@breakpoint.cc>

On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote:
> 
> That would be quite a job.  The correctness of the key can't be
> discovered before the last encrypted block, where the decrypted
> padding will either be correct (because it was the right key) or not
> (because it was the wrong key).  Take into account a pipe with a 10MB
> file, I'm sure you see where that takes us.
> 
> The solution in that bug report seems sane, even though unfortunate.
okay. And since the encrypted file has no header there is nothing we
could hide. And if we add one now then it won't work with older openssl.

So I will try to put this in the release notes for the Debian package.
Do you have an idea where this would fit best in the Wiki? A new page
with one entry does not make sense and it does not look like it belongs
to
	https://wiki.openssl.org/index.php/1.1_API_Changes

Sebastian

From levitte at openssl.org  Sat Nov  5 02:58:02 2016
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 05 Nov 2016 03:58:02 +0100 (CET)
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
 earlear
In-Reply-To: <20161104205933.gw7pyvclnmdkvd73@breakpoint.cc>
References: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
 <20161103.221244.1967755962836083402.levitte@openssl.org>
 <20161104205933.gw7pyvclnmdkvd73@breakpoint.cc>
Message-ID: <20161105.035802.464964389322653088.levitte@openssl.org>

In message <20161104205933.gw7pyvclnmdkvd73 at breakpoint.cc> on Fri, 4 Nov 2016 21:59:33 +0100, Sebastian Andrzej Siewior <openssl-dev at ml.breakpoint.cc> said:

openssl-dev> On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote:
openssl-dev> > 
openssl-dev> > That would be quite a job.  The correctness of the key can't be
openssl-dev> > discovered before the last encrypted block, where the decrypted
openssl-dev> > padding will either be correct (because it was the right key) or not
openssl-dev> > (because it was the wrong key).  Take into account a pipe with a 10MB
openssl-dev> > file, I'm sure you see where that takes us.
openssl-dev> > 
openssl-dev> > The solution in that bug report seems sane, even though unfortunate.
openssl-dev> okay. And since the encrypted file has no header there is nothing we
openssl-dev> could hide. And if we add one now then it won't work with older openssl.
openssl-dev> 
openssl-dev> So I will try to put this in the release notes for the Debian package.
openssl-dev> Do you have an idea where this would fit best in the Wiki? A new page
openssl-dev> with one entry does not make sense and it does not look like it belongs
openssl-dev> to
openssl-dev> 	https://wiki.openssl.org/index.php/1.1_API_Changes

Actually, I would think that a parallell page for the openssl app
(program?) would be the perfect place.  It shouldn't matter if it
starts with just one item, it has to start somewhere (if you look at
the history of 1.1_API_Changes, you'll notice that it started small as
well).

Other things I can think of putting on such a page is the that the
1.1.0 'openssl' app takes all options before all non-option arguments,
there's no mixing them like there was in versions before 1.1.0.  I.e.,
this doesn't work any more:

    openssl ciphers AES -V

while this does:

    openssl ciphers -V AES

Cheers,
Richard

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

From kurt at roeckx.be  Sat Nov  5 08:55:13 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 5 Nov 2016 09:55:13 +0100
Subject: [openssl-dev] openssl enc changed behaviour between 1.1.0 and
 earlear
In-Reply-To: <20161104205933.gw7pyvclnmdkvd73@breakpoint.cc>
References: <20161103202349.ub4aq27wzv4whvay@breakpoint.cc>
 <20161103.221244.1967755962836083402.levitte@openssl.org>
 <20161104205933.gw7pyvclnmdkvd73@breakpoint.cc>
Message-ID: <20161105085513.wdpksphspjwfwrpr@roeckx.be>

On Fri, Nov 04, 2016 at 09:59:33PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote:
> > 
> > That would be quite a job.  The correctness of the key can't be
> > discovered before the last encrypted block, where the decrypted
> > padding will either be correct (because it was the right key) or not
> > (because it was the wrong key).  Take into account a pipe with a 10MB
> > file, I'm sure you see where that takes us.
> > 
> > The solution in that bug report seems sane, even though unfortunate.
> okay. And since the encrypted file has no header there is nothing we
> could hide. And if we add one now then it won't work with older openssl.
> 
> So I will try to put this in the release notes for the Debian package.
> Do you have an idea where this would fit best in the Wiki? A new page
> with one entry does not make sense and it does not look like it belongs
> to

Would it be useful to document this in the manpage?

Are there other places we should document it?


Kurt


From rt at openssl.org  Mon Nov  7 10:39:51 2016
From: rt at openssl.org (=?UTF-8?B?0JDQvdC00YDQtdC5INCf0YDQvtC60L7Qv9GM0LXQsg==?= via RT)
Date: Mon, 07 Nov 2016 10:39:51 +0000
Subject: [openssl-dev] [openssl.org #4504] Openssl cms encrypt bug.
In-Reply-To: <CAE2+cY3TqotYtD4N_fqK3wBhtbKVg0UVsZ+NjnLfqsUHLovMAw@mail.gmail.com>
References: <RT-Ticket-4504@openssl.org>
 <CAE2+cY2_bVyymeQxJ81XK7Z8oCrP0kutMAzh9p=BWYD5PQF74A@mail.gmail.com>
 <rt-4.0.19-23551-1462489511-1906.4504-6-0@openssl.org>
 <CAE2+cY3TqotYtD4N_fqK3wBhtbKVg0UVsZ+NjnLfqsUHLovMAw@mail.gmail.com>
Message-ID: <rt-4.0.19-8715-1478515191-1212.4504-6-0@openssl.org>

Hi, Stephen.

One more bug was found with enc option.


I want encrypt and decrypt any text with cipher "-des-ede3-cfb1". I used
"curl -h" to generete text.

curl -h | openssl enc -des-ede3-cfb1 -pass pass:test | openssl enc -d
-des-ede3-cfb1 -pass pass:test

Looks like openssl encrypts text with error or openssl can't decrypt text
correctly.

Thanks,
Andrew

2016-05-06 4:05 GMT+05:00 Stephen Henson via RT <rt at openssl.org>:

> Fixed now, thanks for the report.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4504
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4504
Please log in as guest with password guest if prompted


From openssl at openssl.org  Mon Nov  7 11:13:22 2016
From: openssl at openssl.org (OpenSSL)
Date: Mon, 7 Nov 2016 11:13:22 +0000 (GMT)
Subject: [openssl-dev] [openssl-announce] Forthcoming OpenSSL release
Message-ID: <alpine.LFD.2.20.1611071110490.8601@hatman>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Forthcoming OpenSSL release
===========================

The OpenSSL project team would like to announce the forthcoming release of
OpenSSL version 1.1.0c

This release will be made available on 10th November 2016 between 1200-1600
UTC and will fix several security defects.  The highest security defect
being fixed is classified as severity "High", and does not affect OpenSSL
versions prior to 1.1.0.

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Yours

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

iQEcBAEBCAAGBQJYIGF/AAoJEAEKUEB8TIy9lzYH/2M2KpYDo9dr1Nx8KobKx/jZ
uzT9lI7oXujxnauQPVvTGcbX3RYswXbWXCh6c5TUXXanLQH0RQNvWJgmrdYrIzzD
22Softp4Djf67QZqjGGssrtTVeRf2q5ShgGHfbB7ShI6BEgN9QCzaelplNIyIMvH
6CixH6li5K4RkkmgaUvkWPsXGbyra2IzPzvJJCQF8rS3OZZcvCWWUC4U5qSFyzQJ
KKj8C0loHimNVAYGXubuK8rZpsPzs+GQeLWI2koJLc9T3y96yumeJP9snUsN5pUi
vatIay5LxXr9xKzGl79X6k75xlrJuEAxJcImvbstFAlftgMRCjyEKy4LGyBIgqA=
=5j78
-----END PGP SIGNATURE-----
-- 
openssl-announce mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce

From michel.sales at free.fr  Mon Nov  7 19:46:39 2016
From: michel.sales at free.fr (Michel)
Date: Mon, 7 Nov 2016 20:46:39 +0100
Subject: [openssl-dev] [openssl.org #4504] Openssl cms encrypt bug.
In-Reply-To: <rt-4.0.19-8715-1478515191-1212.4504-6-0@openssl.org>
References: <RT-Ticket-4504@openssl.org>
 <CAE2+cY2_bVyymeQxJ81XK7Z8oCrP0kutMAzh9p=BWYD5PQF74A@mail.gmail.com>
 <rt-4.0.19-23551-1462489511-1906.4504-6-0@openssl.org>
 <CAE2+cY3TqotYtD4N_fqK3wBhtbKVg0UVsZ+NjnLfqsUHLovMAw@mail.gmail.com>
 <rt-4.0.19-8715-1478515191-1212.4504-6-0@openssl.org>
Message-ID: <000001d2392f$aa71da40$ff558ec0$@sales@free.fr>

Hi Andrew, 

I seem to recall that depending of the OpenSSL version, there was issue with
CFB1 mode.

Michel.
 
-----Message d'origine-----
De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de
?????? ????????? via RT
Envoy??: lundi 7 novembre 2016 11:40
Cc?: openssl-dev at openssl.org
Objet?: Re: [openssl-dev] [openssl.org #4504] Openssl cms encrypt bug.

Hi, Stephen.

One more bug was found with enc option.


I want encrypt and decrypt any text with cipher "-des-ede3-cfb1". I used
"curl -h" to generete text.

curl -h | openssl enc -des-ede3-cfb1 -pass pass:test | openssl enc -d
-des-ede3-cfb1 -pass pass:test

Looks like openssl encrypts text with error or openssl can't decrypt text
correctly.

Thanks,
Andrew




From tshort at akamai.com  Mon Nov  7 21:26:16 2016
From: tshort at akamai.com (Short, Todd)
Date: Mon, 7 Nov 2016 21:26:16 +0000
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <9b46ca6b-1391-2c17-0c74-cef062300158@gmail.com>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <etPan.56916cfb.2c504d53.192@atlas.local>
 <f303ae3446014e1385c9b79e4a205658@usma1ex-dag1mb1.msg.corp.akamai.com>
 <201601110110.u0B1A1JX029122@d23av03.au.ibm.com>
 <1452507792.23391.2.camel@redhat.com>
 <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org>
 <5694008D.20502@openssl.org>
 <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
 <9b46ca6b-1391-2c17-0c74-cef062300158@gmail.com>
Message-ID: <6B9E64A2-E9E6-4EBF-8C69-31E099A009FF@akamai.com>

The file below is LPGL 2.1, and may not be compatible with various projects. Can it be changed to use the OpenSSL license or equivalent?
--
-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 Nov 3, 2016, at 4:31 PM, Douglas E Engert <deengert at gmail.com<mailto:deengert at gmail.com>> wrote:



On 11/3/2016 3:11 PM, Benjamin Kaduk wrote:
To revitalize an old thread (quoted below but summarized here), some applications may desire source-code compatibility between the 1.0.2 API and the 1.1.0 API.  It seems like the sense of the team is that such accessor functions (or macros) should not be committed into the official 1.0.2 tree, but that the community could maintain an external compatibility shim.  Is that correct?

Does anyone already have such a compatibility header, or thoughts about where it should/could reside?

OpenSC has such a header file to address most of the OpenSSL functions used withing OpenSC.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSC_OpenSC_blob_master_src_libopensc_sc-2Dossl-2Dcompat.h&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=nIUo0yfKtaVnPewNDTpig52n6Mbim01ii8UnkmQwYLY&e=>




We have been noticing that a lot of accessor implementations can be backported as static inline functions to a compatibility header or headers with no further modification.  (But not all, as, e.g., HMAC_CTX has changed to hold pointers instead of embedded structs.)

-Ben

On 01/11/2016 01:20 PM, Matt Caswell wrote:

On 11/01/16 18:29, Viktor Dukhovni wrote:


On Jan 11, 2016, at 5:23 AM, Tomas Mraz <tmraz at redhat.com><mailto:tmraz at redhat.com> wrote:

On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote:


The point of using accessor FUNCTIONS is that the code doesn't break
if the structure size or offsets of fields in the underlying
structures change across binaries.

Where that mainly has an impact is updating the crypto/ssl libs
underneath existing binaries is more likely to just work.

#defines in the headers do not help at all here.



The point is in achieving reverse API compatibility between 1.1 and
1.0.2. No binary compatibility is expected between those branches.

I think that having the API compatibility would be really useful thing
easing porting application code to 1.1 branch.


Yes, although in practice may users of 1.0.x will have previous releases
that don't have the accessors, so the issue is difficult to address
retroactively in OpenSSL.  In Postfix, I add the macros myself:

#if OPENSSL_VERSION_NUMBER < 0x10100000L
#define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509))
#endif

Which means that interestingly enough adding these to 1.0.x would break
my code and similar code elsewhere.

So on the whole forward-compatibility macros don't fully address the
problem, and may do as much harm as good.

I think that applications porting to 1.1.0 can and should implement
their own macros against a stable 1.0.x API that we don't change
at the last minute.  Providing your own forward-compatible glue
is easy enough...



Perhaps someone from the community could contribute a (separately
maintained) compatibility layer to provide the relevant macros?

Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=PzZDcf-p6tMpMoz0dw0z21yscvoMGdBrpf08ZD7UAq8&e=>






--

 Douglas E. Engert  <DEEngert at gmail.com><mailto:DEEngert at gmail.com>



--
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/20161107/a1bd8bae/attachment-0001.html>

From kurt at roeckx.be  Mon Nov  7 21:32:06 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 7 Nov 2016 22:32:06 +0100
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <etPan.56916cfb.2c504d53.192@atlas.local>
 <f303ae3446014e1385c9b79e4a205658@usma1ex-dag1mb1.msg.corp.akamai.com>
 <201601110110.u0B1A1JX029122@d23av03.au.ibm.com>
 <1452507792.23391.2.camel@redhat.com>
 <766C9619-D75C-416E-AE17-F5B825A061BD@dukhovni.org>
 <5694008D.20502@openssl.org>
 <91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com>
Message-ID: <20161107213205.frlt4bdykd4txh5a@roeckx.be>

On Thu, Nov 03, 2016 at 03:11:10PM -0500, Benjamin Kaduk wrote:
> To revitalize an old thread (quoted below but summarized here), some
> applications may desire source-code compatibility between the 1.0.2 API
> and the 1.1.0 API.  It seems like the sense of the team is that such
> accessor functions (or macros) should not be committed into the official
> 1.0.2 tree, but that the community could maintain an external
> compatibility shim.  Is that correct?
> 
> Does anyone already have such a compatibility header, or thoughts about
> where it should/could reside?

I put a bunch I've used before on the wiki, which might not be
ideal.


Kurt


From graeme.perrow at sap.com  Mon Nov  7 21:19:27 2016
From: graeme.perrow at sap.com (Perrow, Graeme)
Date: Mon, 7 Nov 2016 21:19:27 +0000
Subject: [openssl-dev] PKI encryption failing on 32-bit Solaris
Message-ID: <a7f8c7f528fd48aa97a281db4d5f2db6@DEWDFE13DE14.global.corp.sap>

I sent this email to the openssl-users list the other day, but I wonder if openssl-dev might be a better place.

I have a small test program (source attached) that does a very simple PKI encrypt / decrypt. This program works on Windows, Linux, and Solaris (64-bit) but fails if I run a 32-bit version on Solaris 10. Solaris 11 is fine.

If I use "./config -kPIC -m32 -xarch=sparc" to build OpenSSL, I get a crash in bn_mul_mont_t4_32. I added "no-asm" and it no longer crashes but I get this error output:

OSSL error
4275158204:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error:rsa_pk1.c:272:

End OSSL error
decrypt failed

I also tried adding -d to the config line to build a debug OpenSSL and then the program succeeds though is very verbose. The fact that a debug OpenSSL works tells me that my code is likely OK.

Could this be a bug in OpenSSL, or am I configuring it incorrectly, or is there a bug in my code?

Thanks for any insight

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161107/34882280/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pkiencrypt.cpp
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161107/34882280/attachment.ksh>

From hkario at redhat.com  Tue Nov  8 12:04:04 2016
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 08 Nov 2016 13:04:04 +0100
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <6B9E64A2-E9E6-4EBF-8C69-31E099A009FF@akamai.com>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <9b46ca6b-1391-2c17-0c74-cef062300158@gmail.com>
 <6B9E64A2-E9E6-4EBF-8C69-31E099A009FF@akamai.com>
Message-ID: <1704751.zUCgUuyqMb@pintsize.usersys.redhat.com>

On Monday, 7 November 2016 21:26:16 CET Short, Todd wrote:
> The file below is LPGL 2.1, and may not be compatible with various projects.
> Can it be changed to use the OpenSSL license or equivalent? 

how LGPL may not be compatible with any project?

> --
> -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 Nov 3, 2016, at 4:31 PM, Douglas E Engert
> <deengert at gmail.com<mailto:deengert at gmail.com>> wrote:
> 
> 
> 
> On 11/3/2016 3:11 PM, Benjamin Kaduk wrote:
> To revitalize an old thread (quoted below but summarized here), some
> applications may desire source-code compatibility between the 1.0.2 API and
> the 1.1.0 API.  It seems like the sense of the team is that such accessor
> functions (or macros) should not be committed into the official 1.0.2 tree,
> but that the community could maintain an external compatibility shim.  Is
> that correct?
> 
> Does anyone already have such a compatibility header, or thoughts about
> where it should/could reside?
> 
> OpenSC has such a header file to address most of the OpenSSL functions used
> withing OpenSC.
> 
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSC_OpenS
> C_blob_master_src_libopensc_sc-2Dossl-2Dcompat.h&d=DgMDaQ&c=96ZbZZcaMF4w0F4j
> pN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyz
> FJ-b7mHMoeJeaJ6OXIq3Os&s=nIUo0yfKtaVnPewNDTpig52n6Mbim01ii8UnkmQwYLY&e=>
> 
> 
> 
> 
> We have been noticing that a lot of accessor implementations can be
> backported as static inline functions to a compatibility header or headers
> with no further modification.  (But not all, as, e.g., HMAC_CTX has changed
> to hold pointers instead of embedded structs.)
> 
> -Ben
> 
> On 01/11/2016 01:20 PM, Matt Caswell wrote:
> 
> On 11/01/16 18:29, Viktor Dukhovni wrote:
> 
> 
> On Jan 11, 2016, at 5:23 AM, Tomas Mraz
> <tmraz at redhat.com><mailto:tmraz at redhat.com> wrote:
> 
> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote:
> 
> 
> The point of using accessor FUNCTIONS is that the code doesn't break
> if the structure size or offsets of fields in the underlying
> structures change across binaries.
> 
> Where that mainly has an impact is updating the crypto/ssl libs
> underneath existing binaries is more likely to just work.
> 
> #defines in the headers do not help at all here.
> 
> 
> 
> The point is in achieving reverse API compatibility between 1.1 and
> 1.0.2. No binary compatibility is expected between those branches.
> 
> I think that having the API compatibility would be really useful thing
> easing porting application code to 1.1 branch.
> 
> 
> Yes, although in practice may users of 1.0.x will have previous releases
> that don't have the accessors, so the issue is difficult to address
> retroactively in OpenSSL.  In Postfix, I add the macros myself:
> 
> #if OPENSSL_VERSION_NUMBER < 0x10100000L
> #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509))
> #endif
> 
> Which means that interestingly enough adding these to 1.0.x would break
> my code and similar code elsewhere.
> 
> So on the whole forward-compatibility macros don't fully address the
> problem, and may do as much harm as good.
> 
> I think that applications porting to 1.1.0 can and should implement
> their own macros against a stable 1.0.x API that we don't change
> at the last minute.  Providing your own forward-compatible glue
> is easy enough...
> 
> 
> 
> Perhaps someone from the community could contribute a (separately
> maintained) compatibility layer to provide the relevant macros?
> 
> Matt
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.pro
> ofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dde
> v&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAw
> mtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=PzZDcf-p6tMpMoz0dw0z21
> yscvoMGdBrpf08ZD7UAq8&e=>
> 
> 
> 
> 
> 
> 
> --
> 
>  Douglas E. Engert  <DEEngert at gmail.com><mailto:DEEngert at gmail.com>
> 
> 
> 
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-- 
Regards,
Hubert Kario
Senior 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/20161108/6f113d82/attachment.sig>

From satta at debian.org  Tue Nov  8 12:41:15 2016
From: satta at debian.org (Sascha Steinbiss)
Date: Tue, 8 Nov 2016 13:41:15 +0100
Subject: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME
In-Reply-To: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
Message-ID: <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>

Dear OpenSSL developer team,

following up on the discussion quoted below on the openssl-users ML I
would like to ask your opinions on adding a OCSP_resp_get1_id() function:

int OCSP_resp_get1_id(const OCSP_BASICRESP *bs,
                      ASN1_OCTET_STRING **pid,
                      X509_NAME **pname);

to allow API users to obtain non-const values from responses to pass on
to downstream functions. Please also see my commit
https://github.com/satta/openssl/commit/4392b12a0caa8f8e7df0bb6e1c94de7f744407ba
implementing this. Looking forward to some comments -- if you are OK
with it I would be happy to file a pull request. My CLA has been signed
and emailed to OpenSSL Foundation's legal team.

Unfortunately I could not find any existing tests for the get0
counterpart in the OpenSSL source. Did I miss something? That's the
reason why I haven't included tests yet, having read the contributor's
guide.

Thanks and kind regards
Sascha


-------- Forwarded Message --------
Subject: 	Re: [openssl-users] Duplicating const X509_NAME
Date: 	Mon, 7 Nov 2016 12:54:03 -0600
From: 	Benjamin Kaduk <bkaduk at akamai.com>
Reply-To: 	openssl-users at openssl.org
To: 	openssl-users at openssl.org



On 11/07/2016 05:42 AM, Sascha Steinbiss wrote:
> Hi all,
>
> I was wondering how to properly make a clone of a const X509_NAME in
> OpenSSL 1.1?
>
> In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id()
> and would like to pass it to X509_find_by_subject() which takes a
> X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a
> local copy -- which looked like the obvious approach -- but that also
> only takes a non-const parameter.
>
> Any ideas? With
>

Hmm, seems like there may be a need for get1-style accessors, then.
Supposedly missing accessors will get backported from master to the 1.1
branch (though making it in time for 1.1.0c later this week could be
tough).  It might be worth filing a pull request with such things.

-Ben
-------------- next part --------------
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From matt at openssl.org  Tue Nov  8 13:10:00 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 8 Nov 2016 13:10:00 +0000
Subject: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const
 X509_NAME
In-Reply-To: <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>
References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
 <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>
Message-ID: <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>



On 08/11/16 12:41, Sascha Steinbiss wrote:
> Dear OpenSSL developer team,
> 
> following up on the discussion quoted below on the openssl-users ML I
> would like to ask your opinions on adding a OCSP_resp_get1_id() function:
> 
> int OCSP_resp_get1_id(const OCSP_BASICRESP *bs,
>                       ASN1_OCTET_STRING **pid,
>                       X509_NAME **pname);
> 
> to allow API users to obtain non-const values from responses to pass on
> to downstream functions. Please also see my commit
> https://github.com/satta/openssl/commit/4392b12a0caa8f8e7df0bb6e1c94de7f744407ba
> implementing this. Looking forward to some comments -- if you are OK
> with it I would be happy to file a pull request. My CLA has been signed
> and emailed to OpenSSL Foundation's legal team.

Just go ahead a file a pull request anyway...that's the best way of
getting comments. If changes are needed you can update the PR as required.

> 
> Unfortunately I could not find any existing tests for the get0
> counterpart in the OpenSSL source. Did I miss something? That's the
> reason why I haven't included tests yet, having read the contributor's
> guide.

Hmmm, there doesn't seem to be anything. You could probably add
something to test_tlsext_status_type() to test/sslapitest.c.

Matt



> 
> Thanks and kind regards
> Sascha
> 
> 
> -------- Forwarded Message --------
> Subject: 	Re: [openssl-users] Duplicating const X509_NAME
> Date: 	Mon, 7 Nov 2016 12:54:03 -0600
> From: 	Benjamin Kaduk <bkaduk at akamai.com>
> Reply-To: 	openssl-users at openssl.org
> To: 	openssl-users at openssl.org
> 
> 
> 
> On 11/07/2016 05:42 AM, Sascha Steinbiss wrote:
>> Hi all,
>>
>> I was wondering how to properly make a clone of a const X509_NAME in
>> OpenSSL 1.1?
>>
>> In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id()
>> and would like to pass it to X509_find_by_subject() which takes a
>> X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a
>> local copy -- which looked like the obvious approach -- but that also
>> only takes a non-const parameter.
>>
>> Any ideas? With
>>
> 
> Hmm, seems like there may be a need for get1-style accessors, then.
> Supposedly missing accessors will get backported from master to the 1.1
> branch (though making it in time for 1.1.0c later this week could be
> tough).  It might be worth filing a pull request with such things.
> 
> -Ben
> 
> 
> 

From tshort at akamai.com  Tue Nov  8 13:49:56 2016
From: tshort at akamai.com (Short, Todd)
Date: Tue, 8 Nov 2016 13:49:56 +0000
Subject: [openssl-dev] Backporting opaque struct getter/setter functions
In-Reply-To: <1704751.zUCgUuyqMb@pintsize.usersys.redhat.com>
References: <CAMp7mVtcf2C65bsWxJnyASJPSBU4XRD1FMHcUtrJ1eiAVwUSoA@mail.gmail.com>
 <9b46ca6b-1391-2c17-0c74-cef062300158@gmail.com>
 <6B9E64A2-E9E6-4EBF-8C69-31E099A009FF@akamai.com>
 <1704751.zUCgUuyqMb@pintsize.usersys.redhat.com>
Message-ID: <DB6C3FFC-124D-4EA0-82DB-8D99B0E6727C@akamai.com>

IANAL, but:

1. Some people see GPL or even LGPL and run away screaming.
1a. Using this means that the using the OpenSSL library requires accepting the LGPL.
1b. Some interpretations of the LGPL permit use when the code is in a dynamically-linked library. Since this is a header file, any code within is compiled into the program in question (not dynamically linked),  as this header contains inline functions, not just function declarations. Anything that uses it cannot be considered a ?work that uses the library?, since there is no way for a user to substitute their own version of this header file into a previously compiled program.
2. Under the assumption that some of the code is likely copied from OpenSSL 1.1.0 (because it not necessarily possible to create an identical OpenSSL function from said definition of it), it means that a license change occurred to OpenSSL code, and that is a violation of the OpenSSL license: https://github.com/openssl/openssl/blob/master/LICENSE <https://github.com/openssl/openssl/blob/master/LICENSE> specifically provisions #1 and #6.

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

> On Nov 8, 2016, at 7:04 AM, Hubert Kario <hkario at redhat.com> wrote:
> 
> On Monday, 7 November 2016 21:26:16 CET Short, Todd wrote:
>> The file below is LPGL 2.1, and may not be compatible with various projects.
>> Can it be changed to use the OpenSSL license or equivalent?
> 
> how LGPL may not be compatible with any project?
> 
>> --
>> -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 Nov 3, 2016, at 4:31 PM, Douglas E Engert
>> <deengert at gmail.com<mailto:deengert at gmail.com>> wrote:
>> 
>> 
>> 
>> On 11/3/2016 3:11 PM, Benjamin Kaduk wrote:
>> To revitalize an old thread (quoted below but summarized here), some
>> applications may desire source-code compatibility between the 1.0.2 API and
>> the 1.1.0 API.  It seems like the sense of the team is that such accessor
>> functions (or macros) should not be committed into the official 1.0.2 tree,
>> but that the community could maintain an external compatibility shim.  Is
>> that correct?
>> 
>> Does anyone already have such a compatibility header, or thoughts about
>> where it should/could reside?
>> 
>> OpenSC has such a header file to address most of the OpenSSL functions used
>> withing OpenSC.
>> 
>> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSC_OpenS
>> C_blob_master_src_libopensc_sc-2Dossl-2Dcompat.h&d=DgMDaQ&c=96ZbZZcaMF4w0F4j
>> pN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyz
>> FJ-b7mHMoeJeaJ6OXIq3Os&s=nIUo0yfKtaVnPewNDTpig52n6Mbim01ii8UnkmQwYLY&e=>
>> 
>> 
>> 
>> 
>> We have been noticing that a lot of accessor implementations can be
>> backported as static inline functions to a compatibility header or headers
>> with no further modification.  (But not all, as, e.g., HMAC_CTX has changed
>> to hold pointers instead of embedded structs.)
>> 
>> -Ben
>> 
>> On 01/11/2016 01:20 PM, Matt Caswell wrote:
>> 
>> On 11/01/16 18:29, Viktor Dukhovni wrote:
>> 
>> 
>> On Jan 11, 2016, at 5:23 AM, Tomas Mraz
>> <tmraz at redhat.com><mailto:tmraz at redhat.com> wrote:
>> 
>> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote:
>> 
>> 
>> The point of using accessor FUNCTIONS is that the code doesn't break
>> if the structure size or offsets of fields in the underlying
>> structures change across binaries.
>> 
>> Where that mainly has an impact is updating the crypto/ssl libs
>> underneath existing binaries is more likely to just work.
>> 
>> #defines in the headers do not help at all here.
>> 
>> 
>> 
>> The point is in achieving reverse API compatibility between 1.1 and
>> 1.0.2. No binary compatibility is expected between those branches.
>> 
>> I think that having the API compatibility would be really useful thing
>> easing porting application code to 1.1 branch.
>> 
>> 
>> Yes, although in practice may users of 1.0.x will have previous releases
>> that don't have the accessors, so the issue is difficult to address
>> retroactively in OpenSSL.  In Postfix, I add the macros myself:
>> 
>> #if OPENSSL_VERSION_NUMBER < 0x10100000L
>> #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509))
>> #endif
>> 
>> Which means that interestingly enough adding these to 1.0.x would break
>> my code and similar code elsewhere.
>> 
>> So on the whole forward-compatibility macros don't fully address the
>> problem, and may do as much harm as good.
>> 
>> I think that applications porting to 1.1.0 can and should implement
>> their own macros against a stable 1.0.x API that we don't change
>> at the last minute.  Providing your own forward-compatible glue
>> is easy enough...
>> 
>> 
>> 
>> Perhaps someone from the community could contribute a (separately
>> maintained) compatibility layer to provide the relevant macros?
>> 
>> Matt
>> _______________________________________________
>> openssl-dev mailing list
>> To unsubscribe:
>> https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.pro
>> ofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dde
>> v&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAw
>> mtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=PzZDcf-p6tMpMoz0dw0z21
>> yscvoMGdBrpf08ZD7UAq8&e=>
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> 
>> Douglas E. Engert  <DEEngert at gmail.com><mailto:DEEngert at gmail.com>
>> 
>> 
>> 
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
> --
> Regards,
> Hubert Kario
> Senior 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 --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161108/ed7a2880/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161108/ed7a2880/attachment.sig>

From satta at debian.org  Tue Nov  8 14:07:24 2016
From: satta at debian.org (Sascha Steinbiss)
Date: Tue, 8 Nov 2016 15:07:24 +0100
Subject: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const
 X509_NAME
In-Reply-To: <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>
References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
 <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>
 <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>
Message-ID: <f6b3a66b-7739-3448-4d34-36cdf97fceaf@debian.org>

Hi Matt,

thanks for your quick reply.

>> Please also see my commit
>> https://github.com/satta/openssl/commit/4392b12a0caa8f8e7df0bb6e1c94de7f744407ba
>> implementing this. Looking forward to some comments -- if you are OK
>> with it I would be happy to file a pull request. My CLA has been signed
>> and emailed to OpenSSL Foundation's legal team.
> 
> Just go ahead a file a pull request anyway...that's the best way of
> getting comments. If changes are needed you can update the PR as required.

Sure, will do.

>> Unfortunately I could not find any existing tests for the get0
>> counterpart in the OpenSSL source. Did I miss something? That's the
>> reason why I haven't included tests yet, having read the contributor's
>> guide.
> 
> Hmmm, there doesn't seem to be anything. You could probably add
> something to test_tlsext_status_type() to test/sslapitest.c.

I just took a look but it looks like the dummy response in that file is
in the wrong format to be decoded to a proper OCSP_RESPONSE.
Unfortunately it's less than trivial -- at least for me -- to come up
with a good test case providing me with the required test data to run
the new method on it. I'd be happy to add tests if someone could provide
some pointers...

Thanks
Sascha

>> -------- Forwarded Message --------
>> Subject: 	Re: [openssl-users] Duplicating const X509_NAME
>> Date: 	Mon, 7 Nov 2016 12:54:03 -0600
>> From: 	Benjamin Kaduk <bkaduk at akamai.com>
>> Reply-To: 	openssl-users at openssl.org
>> To: 	openssl-users at openssl.org
>>
>>
>>
>> On 11/07/2016 05:42 AM, Sascha Steinbiss wrote:
>>> Hi all,
>>>
>>> I was wondering how to properly make a clone of a const X509_NAME in
>>> OpenSSL 1.1?
>>>
>>> In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id()
>>> and would like to pass it to X509_find_by_subject() which takes a
>>> X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a
>>> local copy -- which looked like the obvious approach -- but that also
>>> only takes a non-const parameter.
>>>
>>> Any ideas? With
>>>
>>
>> Hmm, seems like there may be a need for get1-style accessors, then.
>> Supposedly missing accessors will get backported from master to the 1.1
>> branch (though making it in time for 1.1.0c later this week could be
>> tough).  It might be worth filing a pull request with such things.
>>
>> -Ben
>>
>>
>>

From rsalz at akamai.com  Tue Nov  8 14:43:02 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 8 Nov 2016 14:43:02 +0000
Subject: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const
 X509_NAME
In-Reply-To: <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>
References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
 <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>
 <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>
Message-ID: <60000a9834bb484c8beb39806a7b2907@usma1ex-dag1mb1.msg.corp.akamai.com>


> Just go ahead a file a pull request anyway...that's the best way of getting
> comments. If changes are needed you can update the PR as required.

Like, for example, documenting this new function. :)

From tmraz at redhat.com  Tue Nov  8 14:43:28 2016
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 08 Nov 2016 15:43:28 +0100
Subject: [openssl-dev] Missing access to ex_nscert data
Message-ID: <1478616208.27682.8.camel@redhat.com>

Hi,

I'm trying to port OpenVPN to OpenSSL-1.1.0 API.

Unless I overlooked something the new OpenSSL-1.1.0 does not allow
access to the ex_nscert data of the X509 object. Would it be possible
to add such function to the API?

Regards,
-- 
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 rsalz at akamai.com  Tue Nov  8 14:50:55 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 8 Nov 2016 14:50:55 +0000
Subject: [openssl-dev] Missing access to ex_nscert data
In-Reply-To: <1478616208.27682.8.camel@redhat.com>
References: <1478616208.27682.8.camel@redhat.com>
Message-ID: <ab133796946049109e759a70155bc110@usma1ex-dag1mb1.msg.corp.akamai.com>


> Unless I overlooked something the new OpenSSL-1.1.0 does not allow access
> to the ex_nscert data of the X509 object. Would it be possible to add such
> function to the API?

Yes.  Missing accessors are bugfixes and can go into a 1.1.0 update.

Please open an issue or even better a PR.

From rt at openssl.org  Mon Nov  7 19:46:53 2016
From: rt at openssl.org (Michel via RT)
Date: Mon, 07 Nov 2016 19:46:53 +0000
Subject: [openssl-dev] [openssl.org #4504] Openssl cms encrypt bug.
In-Reply-To: <000001d2392f$aa71da40$ff558ec0$@sales@free.fr>
References: <RT-Ticket-4504@openssl.org>
 <CAE2+cY2_bVyymeQxJ81XK7Z8oCrP0kutMAzh9p=BWYD5PQF74A@mail.gmail.com>
 <rt-4.0.19-23551-1462489511-1906.4504-6-0@openssl.org>
 <CAE2+cY3TqotYtD4N_fqK3wBhtbKVg0UVsZ+NjnLfqsUHLovMAw@mail.gmail.com>
 <rt-4.0.19-8715-1478515191-1212.4504-6-0@openssl.org>
 <000001d2392f$aa71da40$ff558ec0$@sales@free.fr>
Message-ID: <rt-4.0.19-8288-1478548013-1121.4504-6-0@openssl.org>

Hi Andrew, 

I seem to recall that depending of the OpenSSL version, there was issue with
CFB1 mode.

Michel.
 
-----Message d'origine-----
De?: openssl-dev [mailto:openssl-dev-bounces at openssl.org] De la part de
?????? ????????? via RT
Envoy??: lundi 7 novembre 2016 11:40
Cc?: openssl-dev at openssl.org
Objet?: Re: [openssl-dev] [openssl.org #4504] Openssl cms encrypt bug.

Hi, Stephen.

One more bug was found with enc option.


I want encrypt and decrypt any text with cipher "-des-ede3-cfb1". I used
"curl -h" to generete text.

curl -h | openssl enc -des-ede3-cfb1 -pass pass:test | openssl enc -d
-des-ede3-cfb1 -pass pass:test

Looks like openssl encrypts text with error or openssl can't decrypt text
correctly.

Thanks,
Andrew




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4504
Please log in as guest with password guest if prompted


From satta at debian.org  Tue Nov  8 14:58:56 2016
From: satta at debian.org (Sascha Steinbiss)
Date: Tue, 8 Nov 2016 15:58:56 +0100
Subject: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const
 X509_NAME
In-Reply-To: <60000a9834bb484c8beb39806a7b2907@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
 <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>
 <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>
 <60000a9834bb484c8beb39806a7b2907@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <9f5d9aa8-7b6b-4d4b-d548-ca7320ae03c8@debian.org>

Hi Rich,

>> Just go ahead a file a pull request anyway...that's the best way of getting
>> comments. If changes are needed you can update the PR as required.
> 
> Like, for example, documenting this new function. :)

Sure, I did mention it alongside its get0 counterpart in
doc/man3/OCSP_resp_find_status.pod [1] -- do I need to add anything
anywhere else?
I built the man pages and man3/OCSP_resp_get1_id.3 exists.

Cheers
Sascha


[1]
https://github.com/openssl/openssl/pull/1876/files#diff-26634cf0cd2b8165b80c141c483d6659

From rsalz at akamai.com  Tue Nov  8 17:40:17 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 8 Nov 2016 17:40:17 +0000
Subject: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const
 X509_NAME
In-Reply-To: <9f5d9aa8-7b6b-4d4b-d548-ca7320ae03c8@debian.org>
References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com>
 <ee8fdd31-dd25-10bb-9ca2-fe281e0aa503@debian.org>
 <cae68402-3895-64b9-de7c-0d7f63bbc6b9@openssl.org>
 <60000a9834bb484c8beb39806a7b2907@usma1ex-dag1mb1.msg.corp.akamai.com>
 <9f5d9aa8-7b6b-4d4b-d548-ca7320ae03c8@debian.org>
Message-ID: <96bf8ea7a31d4a6397c7a9741b563eec@usma1ex-dag1mb1.msg.corp.akamai.com>

No, thanks, that looks good!

From openssl at openssl.org  Thu Nov 10 14:29:43 2016
From: openssl at openssl.org (OpenSSL)
Date: Thu, 10 Nov 2016 14:29:43 +0000
Subject: [openssl-dev] OpenSSL version 1.1.0c published
Message-ID: <20161110142943.GA31613@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.0c released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0c of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.1.0-notes.html

   OpenSSL 1.1.0c is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0c.tar.gz
      Size: 5179668
      SHA1 checksum: 920e6e7bdaccd94d7564af1097176f11900d20ca
      SHA256 checksum: fc436441a2e05752d31b4e46115eb89709a28aef96d4fe786abe92409b2fd6f5

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0c.tar.gz
    openssl sha256 openssl-1.1.0c.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYJIMiAAoJENnE0m0OYESRqeIH+QEu3e3rgFICNUG/4421l7Dy
x42NVUuRvblJCOmAKy+mbt5iHIE1Z5yXOBmDq+1PoBFOSSWPl4NvO48lAkwPnand
/65xOzcEre8JXC9dkk4COk8XRG1RCwTzTyLXa/0bO+FXCYVah9HTQHxVkDo1sXon
Xrtt5c3vF09X5Jm7MJv9XC6WLFI4ts/GQ3PXoHRHHJnw7DeHAYmdKD9f9XGKiPX6
U3yYnFJw2a4EbXE8hc0MFLNZBJlMzhW2eMdwVC5GDtk/u/uvvM86XPi5/ZsuGZIy
V4WSU4DNm/mqRFPVJL0/ANSrcYkDJEq7umarxspv6zb7QMmgl1dNa1ZxkbSwB3Y=
=nU4P
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Nov 10 14:31:28 2016
From: openssl at openssl.org (OpenSSL)
Date: Thu, 10 Nov 2016 14:31:28 +0000
Subject: [openssl-dev] OpenSSL Security Advisory
Message-ID: <20161110143128.GA31777@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [10 Nov 2016]
========================================

ChaCha20/Poly1305 heap-buffer-overflow (CVE-2016-7054)
======================================================

Severity: High

TLS connections using *-CHACHA20-POLY1305 ciphersuites are susceptible to a DoS
attack by corrupting larger payloads. This can result in an OpenSSL crash. This
issue is not considered to be exploitable beyond a DoS.

OpenSSL 1.1.0 users should upgrade to 1.1.0c

This issue does not affect OpenSSL versions prior to 1.1.0

This issue was reported to OpenSSL on 25th September 2016 by Robert
?wi?cki (Google Security Team), and was found using honggfuzz. The fix
was developed by Richard Levitte of the OpenSSL development team.

CMS Null dereference (CVE-2016-7053)
====================================

Severity: Moderate

Applications parsing invalid CMS structures can crash with a NULL pointer
dereference. This is caused by a bug in the handling of the ASN.1 CHOICE type
in OpenSSL 1.1.0 which can result in a NULL value being passed to the structure
callback if an attempt is made to free certain invalid encodings. Only CHOICE
structures using a callback which do not handle NULL value are affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0c

This issue does not affect OpenSSL versions prior to 1.1.0

This issue was reported to OpenSSL on 12th October 2016 by Tyler Nighswander of
ForAllSecure. The fix was developed by Stephen Henson of the OpenSSL
development team.

Montgomery multiplication may produce incorrect results (CVE-2016-7055)
=======================================================================

Severity: Low

There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits. Analysis suggests that attacks against RSA, DSA
and DH private keys are impossible. This is because the subroutine in
question is not used in operations with the private key itself and an input
of the attacker's direct choice. Otherwise the bug can manifest itself as
transient authentication and key negotiation failures or reproducible
erroneous outcome of public-key operations with specially crafted input.
Among EC algorithms only Brainpool P-512 curves are affected and one
presumably can attack ECDH key negotiation. Impact was not analyzed in
detail, because pre-requisites for attack are considered unlikely. Namely
multiple clients have to choose the curve in question and the server has to
share the private key among them, neither of which is default behaviour.
Even then only clients that chose the curve will be affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0c

This issue does not affect OpenSSL versions prior to 1.0.2. Due to the low
severity of this defect we are not issuing a new 1.0.2 release at this time.
We recommend that 1.0.2 users wait for the next 1.0.2 release for the fix to
become available. The fix is also available in the OpenSSL git repository in
commit 57c4b9f6a2.

This issue was publicly reported as transient failures and was not
initially recognized as a security issue. Thanks to Richard Morgan for
providing reproducible case. The fix was developed by Andy Polyakov of
the OpenSSL development team.

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
version 1.0.1 will cease on 31st December 2016. No security updates for that
version will be provided after that date. Users of 1.0.1 are advised to
upgrade.

Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions are no longer receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20161110.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/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYJH8JAAoJENnE0m0OYESRaZwH/1S6sjqemFtHXVk77xMMbUmY
kKGJoo5/7wJQWdw9LMPoxjXDyW0fWTKI+Ly2qfP8ZwVizONndN1HCDdWPSbT9EvN
1OG6gr0BQBmlcENCBrSuGwojAtQuMd47q3IAR3ZSx5yvYby4Lg9tXk1FjvnQ600O
Z19r1lvc6efeO1fXPBqIUUPJ4y2XN7P1DDlE5UWxacN5Xn+a6cqrieuj0g1aoZ0h
rw4fEI7o3EEufYTtodos61xLqZWq8quaMuerWEq0HfEOyMGGyDkmnQkXdU0X7o4g
U17vgzM7CvN7+weBz8hVHd0RARAl21vBjYV/G1kruBxD+cYjdavzGGAf/Z1o15w=
=MmoX
-----END PGP SIGNATURE-----

From bkaduk at akamai.com  Thu Nov 10 17:52:56 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 10 Nov 2016 11:52:56 -0600
Subject: [openssl-dev] Tag for 1.1.0c?
Message-ID: <bde12a40-9751-e848-3bc3-ed8a20d96d67@akamai.com>

I'm failing to find a tag for 1.1.0c either on git.openssl.org or on github.

Am I missing something?

Thanks,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161110/4135b320/attachment.html>

From matt at openssl.org  Thu Nov 10 17:56:00 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 10 Nov 2016 17:56:00 +0000
Subject: [openssl-dev] Tag for 1.1.0c?
In-Reply-To: <bde12a40-9751-e848-3bc3-ed8a20d96d67@akamai.com>
References: <bde12a40-9751-e848-3bc3-ed8a20d96d67@akamai.com>
Message-ID: <69ec8b5c-2028-e42e-3487-39937017efcd@openssl.org>



On 10/11/16 17:52, Benjamin Kaduk wrote:
> I'm failing to find a tag for 1.1.0c either on git.openssl.org or on github.
> 
> Am I missing something?

Oops. My mistake. I forgot to push it.

Matt


From waywardgeek at gmail.com  Fri Nov 11 16:11:44 2016
From: waywardgeek at gmail.com (Bill Cox)
Date: Fri, 11 Nov 2016 08:11:44 -0800
Subject: [openssl-dev] Future of custom extension API?
Message-ID: <CAOLP8p5j7qLmMe=rLdp68HzZsaGTD3yNOKhGK3t1a072eQJkMQ@mail.gmail.com>

Hi, folks.  I am a big fan of the concept of the custom extension API, but
it needs a bit of work.  If it were a bit more usable, I think we could
move a lot of simple extensions into this framework, simplifying OpenSSL.
In particular, I feel that managing complexity in OpenSSL is the single
biggest challenge for security.

The current custom extension API has a few issues that make it very
difficult to use:

- There is no way to save data in the session state
- Custom extensions are not negotiated on resumption (how do we know what
we negotiated originally?)
- It is not possible to know anything about other extensions that may or
may not have been negotiated

Because we do not have a way to remember what was originally negotiated,
the custom extension API is generally not usable for extensions that need
to either be remembered across resumption, or renegotiated.  As a minimal
patch, changing 1 so that custom extensions are negotiated on resumption
makes the API much more usable.  However, if we need to modify this API,
should we expand on it while we are at it?

I would be interested in helping to expand the API so that we could save
session state, specify what to do on resumption, and learn about other
extensions.  Since we already add custom extensions after native
extensions, it seems like it would be easy to allow the custom extension
API to at least know which native extensions are present.  If we add custom
extensions in order of their extension number, we could also know about
those.  Adding state to the session sounds pretty scary, at least with the
1.0 code I worked with, but there are various cases where it might be
needed.  For examle, Nick Harper's proposal for TLS 1.3 0-RTT Token Binding
requires that the server remember the key parameters negotiated on the
1-RTT handshake.  Even if I get my proposed 1-line change to enable custom
extensions on resumption, it looks like we'll still have to bake-in token
binding as a custom extension for TLS 1.3, unless we upgrade the API.

What are the chances that the OpenSSL devs would be interested in upgrading
this API?

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

From rsalz at akamai.com  Mon Nov 14 15:00:04 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 14 Nov 2016 15:00:04 +0000
Subject: [openssl-dev] Future of custom extension API?
In-Reply-To: <CAOLP8p5j7qLmMe=rLdp68HzZsaGTD3yNOKhGK3t1a072eQJkMQ@mail.gmail.com>
References: <CAOLP8p5j7qLmMe=rLdp68HzZsaGTD3yNOKhGK3t1a072eQJkMQ@mail.gmail.com>
Message-ID: <6302638ac16f4ff182d191df573b1f93@usma1ex-dag1mb1.msg.corp.akamai.com>

> What are the chances that the OpenSSL devs would be interested in upgrading this API?

Pretty good.

We?re looking at adding a new API for 1.1.1 that is like the one in boring -- it gives full acess to the hello message.  The 1.1.0 API is frozen.  But what can we do for the next release, while still keeping API compatibility?  That is, the existing API can't go away, but maybe the "better" one can be added?

From waywardgeek at gmail.com  Mon Nov 14 15:57:45 2016
From: waywardgeek at gmail.com (Bill Cox)
Date: Mon, 14 Nov 2016 07:57:45 -0800
Subject: [openssl-dev] Future of custom extension API?
In-Reply-To: <6302638ac16f4ff182d191df573b1f93@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAOLP8p5j7qLmMe=rLdp68HzZsaGTD3yNOKhGK3t1a072eQJkMQ@mail.gmail.com>
 <6302638ac16f4ff182d191df573b1f93@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAOLP8p4FSPrWQ3a9m7UPg6Tq0qPzX_webV9O_6OA+MdBjwUvcA@mail.gmail.com>

On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich <rsalz at akamai.com> wrote:

> > What are the chances that the OpenSSL devs would be interested in
> upgrading this API?
>
> Pretty good.
>
> We?re looking at adding a new API for 1.1.1 that is like the one in boring
> -- it gives full acess to the hello message.  The 1.1.0 API is frozen.  But
> what can we do for the next release, while still keeping API
> compatibility?  That is, the existing API can't go away, but maybe the
> "better" one can be added?
>

Sounds good to me.  David Benjamin had an idea I may be mis-interpreting,
but instead of allowing custom extensions to save state directly to the
streamed session blob, custom extensions that request it could have the
response from the other side auto-saved for them.  That way, on a resume,
if the server accepts the resume, the server-side custom extension would
see the original data from the client, and if the resume is rejected, it
would see the new extension data from the client.  I think the server is
supposed to compare them and fall back to a full handshake if they are
different, but David could confirm these details.

Similarly, client-side would see the original server response on a resume,
and the new one if falling back to full handshake.  In this scheme, the
server does not need to send custom extensions on resume, SFAIK.

That, plus an API to examine the hello message or something like that seems
like it might do the trick,

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

From davidben at google.com  Mon Nov 14 22:12:01 2016
From: davidben at google.com (David Benjamin)
Date: Mon, 14 Nov 2016 22:12:01 +0000
Subject: [openssl-dev] Future of custom extension API?
In-Reply-To: <CAOLP8p4FSPrWQ3a9m7UPg6Tq0qPzX_webV9O_6OA+MdBjwUvcA@mail.gmail.com>
References: <CAOLP8p5j7qLmMe=rLdp68HzZsaGTD3yNOKhGK3t1a072eQJkMQ@mail.gmail.com>
 <6302638ac16f4ff182d191df573b1f93@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAOLP8p4FSPrWQ3a9m7UPg6Tq0qPzX_webV9O_6OA+MdBjwUvcA@mail.gmail.com>
Message-ID: <CAF8qwaCCL7etGtiQuyAHT+x=o7cpsA5i9VEENnwwjQPo6cVsXA@mail.gmail.com>

On Tue, Nov 15, 2016 at 12:58 AM Bill Cox <waywardgeek at gmail.com> wrote:

> On Mon, Nov 14, 2016 at 7:00 AM, Salz, Rich <rsalz at akamai.com> wrote:
>
> > What are the chances that the OpenSSL devs would be interested in
> upgrading this API?
>
> Pretty good.
>
> We?re looking at adding a new API for 1.1.1 that is like the one in boring
> -- it gives full acess to the hello message.  The 1.1.0 API is frozen.  But
> what can we do for the next release, while still keeping API
> compatibility?  That is, the existing API can't go away, but maybe the
> "better" one can be added?
>
>
> Sounds good to me.  David Benjamin had an idea I may be mis-interpreting,
> but instead of allowing custom extensions to save state directly to the
> streamed session blob, custom extensions that request it could have the
> response from the other side auto-saved for them.  That way, on a resume,
> if the server accepts the resume, the server-side custom extension would
> see the original data from the client, and if the resume is rejected, it
> would see the new extension data from the client.  I think the server is
> supposed to compare them and fall back to a full handshake if they are
> different, but David could confirm these details.
>
> Similarly, client-side would see the original server response on a resume,
> and the new one if falling back to full handshake.  In this scheme, the
> server does not need to send custom extensions on resume, SFAIK.
>
> That, plus an API to examine the hello message or something like that
> seems like it might do the trick,
>

Slight clarification: my proposal wasn't to save the extension from the
peer, but to save the server's extension. 0-RTT rules are what they are
because the server's response must be predicted, and you decline 0-RTT on a
prediction miss.

It implicitly predicts what the server did last time, so the only operation
you need to support is "did the server pick the same thing as last time"
which, for most extensions which follow the client offer / server pick
pattern, like ALPN or tokbind, is the same as saying "is the server
extension byte-for-byte identical?"

That said, after discussing this with you, I realized there's a hole in my
theory. Suppose we defined ALPN2 which is like ALPN but, rather than the
server echoing the protocol, the server gave you an index into the client
list. Then saving the server extension isn't sufficient and context from
the client extension is needed.

So, depending on what exactly you want this custom extension to support,
you may want a more complex API surface. Though the saved server extension
one should be suitable for all but really weird stuff. (1.3 pre_shared_key
uses an index because echoing the ticket would be messy, but pre_shared_key
is already very non-generically integrated with 0-RTT since it's session
resumption.)

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

From dwmw2 at infradead.org  Tue Nov 15 00:24:17 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 15 Nov 2016 00:24:17 -0000
Subject: [openssl-dev] [RFC 1/2] engine: add new flag based method for
 loading engine keys
In-Reply-To: <1479139281.2630.11.camel@HansenPartnership.com>
References: <1479139186.2630.9.camel@HansenPartnership.com>
 <1479139281.2630.11.camel@HansenPartnership.com>
Message-ID: <13fbc22efacc1826f81594dccea1df76.squirrel@twosheds.infradead.org>


> The assumption in all the current engine code is that key_id can be
> passed as something like a file name.  There are some new users that
> actually want to pass a BIO, so add a new load_key method for engines
> that takes a flag value.  The first defined flag is
> ENGINE_LOAD_KEY_FLAG_BIO which means that the key_id is actually a bio
> pointer.

I like that this also fixes the UI callback horridness discussed at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/b8d39711:/openssl.c#l423

I like it even more that I can completely remove all mention of the TPM
and the special case to load the engine, and just rely on OpenSSL to Do
The Right Thing when I feed it a PEM file containing -----BEGIN TSS KEY
BLOB-----, just like GnuTLS does.

-- 
dwmw2


From James.Bottomley at HansenPartnership.com  Wed Nov 16 15:46:16 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 16 Nov 2016 10:46:16 -0500
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based
 RSA keys in openssl
Message-ID: <1479311176.3525.6.camel@HansenPartnership.com>

[David Woodhouse told me that openssl-dev is a closed list, so the
original messages got trashed.  This is a resend with apologies to
David and Peter]

One of the principle problems of using TPM based keys is that there's
no easy way of integrating them with standard file based keys.  This
proposal adds a generic method for handling file based engine keys that
can be loaded as PEM files.  Integration into the PEM loader requires a
BIO based engine API callback which the first patch adds.  The second
patch checks to see if the key can be loaded by any of the present
engines.  Note that this requires that any engine which is to be used
must be present and initialised via openssl.cnf.

I'll also post to this list the patch to openssl_tpm_engine that makes
use if this infrastructure so the integration of the whole can be seen.
 It should also be noted that gnutls has had this functionality since
2012.

The patch was done against 1.0.2h for easier testing and you can try it
and the openssl_tpm_engine out (if you run openSUSE) here:

https://build.opensuse.org/project/show/home:jejb1:Tumbleweed

James

---

James Bottomley (2):
  engine: add new flag based method for loading engine keys
  pem: load engine keys

 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
 crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
 crypto/pem/pem_pkey.c    |  5 +++++
 4 files changed, 70 insertions(+)


From James.Bottomley at HansenPartnership.com  Wed Nov 16 15:47:55 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 16 Nov 2016 10:47:55 -0500
Subject: [openssl-dev] [RFC 1/2] engine: add new flag based method for
	loading engine keys
In-Reply-To: <1479139186.2630.9.camel@HansenPartnership.com>
References: <1479139186.2630.9.camel@HansenPartnership.com>
Message-ID: <1479311275.3525.8.camel@HansenPartnership.com>

The assumption in all the current engine code is that key_id can be
passed as something like a file name.  There are some new users that
actually want to pass a BIO, so add a new load_key method for engines
that takes a flag value.  The first defined flag is
ENGINE_LOAD_KEY_FLAG_BIO which means that the key_id is actually a bio
pointer.

Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
---
 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
 crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
 3 files changed, 65 insertions(+)

diff --git a/crypto/engine/eng_int.h b/crypto/engine/eng_int.h
index 46f163b..b65cc41 100644
--- a/crypto/engine/eng_int.h
+++ b/crypto/engine/eng_int.h
@@ -197,6 +197,7 @@ struct engine_st {
     ENGINE_CTRL_FUNC_PTR ctrl;
     ENGINE_LOAD_KEY_PTR load_privkey;
     ENGINE_LOAD_KEY_PTR load_pubkey;
+    ENGINE_LOAD_KEY_FLAGS_PTR load_key_flags;
     ENGINE_SSL_CLIENT_CERT_PTR load_ssl_client_cert;
     const ENGINE_CMD_DEFN *cmd_defns;
     int flags;
diff --git a/crypto/engine/eng_pkey.c b/crypto/engine/eng_pkey.c
index 23580d9..124426f 100644
--- a/crypto/engine/eng_pkey.c
+++ b/crypto/engine/eng_pkey.c
@@ -64,6 +64,13 @@ int ENGINE_set_load_privkey_function(ENGINE *e,
     return 1;
 }
 
+int ENGINE_set_load_key_flags_function(ENGINE *e,
+				       ENGINE_LOAD_KEY_FLAGS_PTR load_f)
+{
+    e->load_key_flags = load_f;
+    return 1;
+}
+
 int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f)
 {
     e->load_pubkey = loadpub_f;
@@ -88,6 +95,11 @@ ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e)
     return e->load_pubkey;
 }
 
+ENGINE_LOAD_KEY_FLAGS_PTR ENGINE_get_load_key_flags_function(const ENGINE *e)
+{
+    return e->load_key_flags;
+}
+
 ENGINE_SSL_CLIENT_CERT_PTR ENGINE_get_ssl_client_cert_function(const ENGINE
                                                                *e)
 {
@@ -184,3 +196,29 @@ int ENGINE_load_ssl_client_cert(ENGINE *e, SSL *s,
     return e->load_ssl_client_cert(e, s, ca_dn, pcert, ppkey, pother,
                                    ui_method, callback_data);
 }
+
+int ENGINE_find_engine_load_key(ENGINE **e, EVP_PKEY **pkey, const char *key_id,
+                                pem_password_cb *cb, void *cb_data,
+                                unsigned int flags)
+{
+    ENGINE *ep;
+    int ret = 0;
+
+    for (ep = ENGINE_get_first(); ep != NULL; ep = ENGINE_get_next(ep)) {
+        if (!ep->load_key_flags)
+            continue;
+        if (ep->load_key_flags(ep, pkey, key_id, cb, cb_data, flags) == 1) {
+            ret = 1;
+            break;
+        }
+	if (flags & ENGINE_LOAD_KEY_FLAG_BIO)
+            (void)BIO_reset((BIO *)key_id);
+	ERR_clear_error();
+    }
+    if (e)
+        *e = ep;
+    else if (ep)
+        ENGINE_free(ep);
+
+    return ret;
+}
diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h
index bd7b591..49f6a55 100644
--- a/crypto/engine/engine.h
+++ b/crypto/engine/engine.h
@@ -97,6 +97,7 @@
 # include <openssl/symhacks.h>
 
 # include <openssl/x509.h>
+# include <openssl/pem.h>
 
 #ifdef  __cplusplus
 extern "C" {
@@ -338,6 +339,19 @@ typedef int (*ENGINE_CTRL_FUNC_PTR) (ENGINE *, int, long, void *,
 typedef EVP_PKEY *(*ENGINE_LOAD_KEY_PTR)(ENGINE *, const char *,
                                          UI_METHOD *ui_method,
                                          void *callback_data);
+
+/*
+ * This flag signals that the const char *key_id (3rd argument) actually
+ * points to a SSL BIO structure
+ */
+#define ENGINE_LOAD_KEY_FLAG_BIO	0x01
+
+/* Replacement load_key with flags and return code */
+typedef int (*ENGINE_LOAD_KEY_FLAGS_PTR)(ENGINE *, EVP_PKEY **,
+					 const char *,
+					 pem_password_cb *pwd_callback,
+					 void *callback_data,
+					 unsigned int flags);
 typedef int (*ENGINE_SSL_CLIENT_CERT_PTR) (ENGINE *, SSL *ssl,
                                            STACK_OF(X509_NAME) *ca_dn,
                                            X509 **pcert, EVP_PKEY **pkey,
@@ -565,6 +579,8 @@ int ENGINE_set_finish_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR finish_f);
 int ENGINE_set_ctrl_function(ENGINE *e, ENGINE_CTRL_FUNC_PTR ctrl_f);
 int ENGINE_set_load_privkey_function(ENGINE *e,
                                      ENGINE_LOAD_KEY_PTR loadpriv_f);
+int ENGINE_set_load_key_flags_function(ENGINE *e,
+				       ENGINE_LOAD_KEY_FLAGS_PTR loadpriv_f);
 int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f);
 int ENGINE_set_load_ssl_client_cert_function(ENGINE *e,
                                              ENGINE_SSL_CLIENT_CERT_PTR
@@ -611,6 +627,7 @@ ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(const ENGINE *e);
 ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(const ENGINE *e);
 ENGINE_LOAD_KEY_PTR ENGINE_get_load_privkey_function(const ENGINE *e);
 ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e);
+ENGINE_LOAD_KEY_FLAGS_PTR ENGINE_get_load_key_flags_function(const ENGINE *e);
 ENGINE_SSL_CLIENT_CERT_PTR ENGINE_get_ssl_client_cert_function(const ENGINE
                                                                *e);
 ENGINE_CIPHERS_PTR ENGINE_get_ciphers(const ENGINE *e);
@@ -671,6 +688,15 @@ int ENGINE_load_ssl_client_cert(ENGINE *e, SSL *s,
                                 UI_METHOD *ui_method, void *callback_data);
 
 /*
+ * Given a key_id, this method iterates over all present engines to
+ * see if any can handle it.  It's functionality depends on the engine
+ * implementing e->load_key_flags.
+ */
+int ENGINE_find_engine_load_key(ENGINE **e, EVP_PKEY **pkey, const char *key_id,
+                                pem_password_cb *cb, void *cb_data,
+                                unsigned int flags);
+
+/*
  * This returns a pointer for the current ENGINE structure that is (by
  * default) performing any RSA operations. The value returned is an
  * incremented reference, so it should be free'd (ENGINE_finish) before it is

From James.Bottomley at HansenPartnership.com  Wed Nov 16 15:48:13 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 16 Nov 2016 10:48:13 -0500
Subject: [openssl-dev] [RFC 2/2] pem: load engine keys
In-Reply-To: <1479139186.2630.9.camel@HansenPartnership.com>
References: <1479139186.2630.9.camel@HansenPartnership.com>
Message-ID: <1479311293.3525.9.camel@HansenPartnership.com>

Before trying to process the PEM file, hand it to each of the
loaded engines to see if they can load it.  This uses the new
bio based callback, so the engine must be loaded and implement this
callback to be considered.

Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
---
 crypto/pem/pem_pkey.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
index 04d6319..8d44d45 100644
--- a/crypto/pem/pem_pkey.c
+++ b/crypto/pem/pem_pkey.c
@@ -85,6 +85,11 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x, pem_password_cb *cb,
     int slen;
     EVP_PKEY *ret = NULL;
 
+    if (ENGINE_find_engine_load_key(NULL, &ret, (const char *)bp, cb, u,
+				    ENGINE_LOAD_KEY_FLAG_BIO) == 1) {
+        return ret;
+    }
+
     if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY, bp, cb, u))
         return NULL;
     p = data;

From James.Bottomley at HansenPartnership.com  Wed Nov 16 15:48:33 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 16 Nov 2016 10:48:33 -0500
Subject: [openssl-dev] [PATCH] openssl tpm engine: add new openssl bio
 method for seamless loading of tpm keys
Message-ID: <1479311313.3525.10.camel@HansenPartnership.com>

Permits this engine to be used as part of the openssl pem
routines for loading TPM based keys.  To use this, the
tpm engine must be preloaded via the openssl.cnf file

Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>

diff --git a/e_tpm.c b/e_tpm.c
index 3e20f8e..9cb1d6c 100644
--- a/e_tpm.c
+++ b/e_tpm.c
@@ -43,13 +43,19 @@
 #ifndef OPENSSL_NO_HW
 #ifndef OPENSSL_NO_HW_TPM
 
+struct tpm_ui {
+    UI_METHOD *ui_method;
+    pem_password_cb *pem_cb;
+};
+
 /* engine specific functions */
 static int tpm_engine_destroy(ENGINE *);
 static int tpm_engine_init(ENGINE *);
 static int tpm_engine_finish(ENGINE *);
 static int tpm_engine_ctrl(ENGINE *, int, long, void *, void (*)());
 static EVP_PKEY *tpm_engine_load_key(ENGINE *, const char *, UI_METHOD *, void *);
-static char *tpm_engine_get_auth(UI_METHOD *, char *, int, char *, void *);
+static int tpm_engine_load_key_flags(ENGINE *, EVP_PKEY **, const char *, pem_password_cb *, void *, unsigned int);
+static char *tpm_engine_get_auth(struct tpm_ui *, char *, int, char *, void *);
 
 #ifndef OPENSSL_NO_RSA
 /* rsa functions */
@@ -212,6 +218,9 @@ static int bind_helper(ENGINE * e)
 	    !ENGINE_set_ctrl_function(e, tpm_engine_ctrl) ||
 	    !ENGINE_set_load_pubkey_function(e, tpm_engine_load_key) ||
 	    !ENGINE_set_load_privkey_function(e, tpm_engine_load_key) ||
+#ifdef ENGINE_LOAD_KEY_FLAG_BIO
+            !ENGINE_set_load_key_flags_function(e, tpm_engine_load_key_flags) ||
+#endif
 	    !ENGINE_set_cmd_defns(e, tpm_cmd_defns))
 		return 0;
 
@@ -244,7 +253,7 @@ void ENGINE_load_tpm(void)
 	ERR_clear_error();
 }
 
-int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+int tpm_load_srk(struct tpm_ui *ui, void *cb_data)
 {
 	TSS_RESULT result;
 	UINT32 authusage;
@@ -451,8 +460,9 @@ err:
 	return 0;
 }
 
-static char *tpm_engine_get_auth(UI_METHOD *ui_method, char *auth, int maxlen,
-				 char *input_string, void *cb_data)
+static char *tpm_engine_get_auth_ui(UI_METHOD *ui_method, char *auth,
+				    int maxlen, char *input_string,
+				    void *cb_data)
 {
 	UI *ui;
 
@@ -479,6 +489,30 @@ static char *tpm_engine_get_auth(UI_METHOD *ui_method, char *auth, int maxlen,
 	return auth;
 }
 
+static char *tpm_engine_get_auth_pem(pem_password_cb *pem_cb, char *auth,
+				    int maxlen, char *input_string,
+				    void *cb_data)
+{
+	EVP_set_pw_prompt(input_string);
+	if (!pem_cb)
+		pem_cb = PEM_def_callback;
+	pem_cb(auth, maxlen, 0, cb_data);
+	EVP_set_pw_prompt(NULL);
+
+	return auth;
+}
+
+static char *tpm_engine_get_auth(struct tpm_ui *ui, char *auth,
+                                 int maxlen, char *input_string, void *cb_data)
+{
+	if (ui->ui_method)
+		return tpm_engine_get_auth_ui(ui->ui_method, auth, maxlen,
+					      input_string, cb_data);
+	else
+		return tpm_engine_get_auth_pem(ui->pem_cb, auth, maxlen,
+					       input_string, cb_data);
+}
+
 static int tpm_engine_finish(ENGINE * e)
 {
 	DBG("%s", __FUNCTION__);
@@ -575,8 +609,19 @@ int fill_out_rsa_object(RSA *rsa, TSS_HKEY hKey)
 	return 1;
 }
 
-static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
-				     UI_METHOD *ui, void *cb_data)
+static inline int tpm_flag_is_bio(unsigned int flags)
+{
+#ifdef ENGINE_LOAD_KEY_FLAG_BIO
+	return flags & ENGINE_LOAD_KEY_FLAG_BIO;
+#else
+	return 0;
+#endif
+}
+
+static int tpm_engine_load_key_core(ENGINE *e, EVP_PKEY **ppkey,
+					  const char *key_id,
+                                          struct tpm_ui *ui,
+                                          void *cb_data, unsigned int flags)
 {
 	ASN1_OCTET_STRING *blobstr;
 	TSS_HKEY hKey;
@@ -591,37 +636,55 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 
 	if (!key_id) {
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_PASSED_NULL_PARAMETER);
-		return NULL;
-	}
-
-	if (!tpm_load_srk(ui, cb_data)) {
-		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_SRK_LOAD_FAILED);
-		return NULL;
+		return 0;
 	}
 
-	if ((bf = BIO_new_file(key_id, "r")) == NULL) {
-		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
-		       TPM_R_FILE_NOT_FOUND);
-		return NULL;
+	if (tpm_flag_is_bio(flags)) {
+		bf = (BIO *)key_id;
+	} else {
+		if ((bf = BIO_new_file(key_id, "r")) == NULL) {
+			TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
+			       TPM_R_FILE_NOT_FOUND);
+			return 0;
+		}
 	}
 
 	blobstr = PEM_ASN1_read_bio((void *)d2i_ASN1_OCTET_STRING,
 				    "TSS KEY BLOB", bf, NULL, NULL, NULL);
+
+
+	if (!tpm_flag_is_bio(flags))
+		BIO_free(bf);
+
+	/* if no actual key, we're just seeing if we can parse the file */
+	if (!ppkey) {
+		if (blobstr) {
+			ASN1_OCTET_STRING_free(blobstr);
+			return 1;
+		}
+		return 0;
+	}
+
+	/* else we're actually trying to load the key and a wrong
+	 * file format is an error */
 	if (!blobstr) {
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
 		       TPM_R_FILE_READ_FAILED);
-		BIO_free(bf);
-		return NULL;
+		return 0;
+	}
+
+	if (!tpm_load_srk(ui, cb_data)) {
+		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_SRK_LOAD_FAILED);
+		return 0;
 	}
 
-	BIO_free(bf);
 	DBG("Loading blob of size: %d", blobstr->length);
 	if ((result = Tspi_Context_LoadKeyByBlob(hContext, hSRK,
 						   blobstr->length,
 						   blobstr->data, &hKey))) {
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
 		       TPM_R_REQUEST_FAILED);
-		return NULL;
+		return 0;
 	}
 	ASN1_OCTET_STRING_free(blobstr);
 
@@ -631,7 +694,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
 		       TPM_R_REQUEST_FAILED);
-		return NULL;
+		return 0;
 	}
 
 	if (authusage) {
@@ -641,7 +704,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		if ((auth = calloc(1, 128)) == NULL) {
 			Tspi_Context_CloseObject(hContext, hKey);
 			TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_MALLOC_FAILURE);
-			return NULL;
+			return 0;
 		}
 
 		if (!tpm_engine_get_auth(ui, (char *)auth, 128,
@@ -650,7 +713,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 			Tspi_Context_CloseObject(hContext, hKey);
 			free(auth);
 			TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_REQUEST_FAILED);
-			return NULL;
+			return 0;
 		}
 
 		if ((result = Tspi_Context_CreateObject(hContext,
@@ -688,7 +751,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 	if ((pkey = EVP_PKEY_new()) == NULL) {
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_MALLOC_FAILURE);
-		return NULL;
+		return 0;
 	}
 	pkey->type = EVP_PKEY_RSA;
 
@@ -696,7 +759,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		EVP_PKEY_free(pkey);
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_MALLOC_FAILURE);
-		return NULL;
+		return 0;
 	}
 	rsa->meth = &tpm_rsa;
 	/* call our local init function here */
@@ -708,13 +771,44 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		RSA_free(rsa);
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_REQUEST_FAILED);
-		return NULL;
+		return 0;
 	}
 
 	EVP_PKEY_assign_RSA(pkey, rsa);
 
-	return pkey;
+	*ppkey = pkey;
+	return 1;
 }
+ 
+static int tpm_engine_load_key_flags(ENGINE *e, EVP_PKEY **ppkey,
+				     const char *key_id,
+				     pem_password_cb *pem_cb, void *cb,
+				     unsigned int flags)
+{
+	struct tpm_ui tui = {
+		.ui_method = NULL,
+		.pem_cb = pem_cb,
+	};
+
+	return tpm_engine_load_key_core(e, ppkey, key_id, &tui, cb, flags);
+}
+
+static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
+				     UI_METHOD *ui, void *cb)
+{
+	struct tpm_ui tui = {
+		.ui_method = ui,
+		.pem_cb = NULL,
+	};
+	EVP_PKEY *pkey;
+	int ret;
+
+	ret = tpm_engine_load_key_core(e, &pkey, key_id, &tui, cb, 0);
+	if (ret == 1)
+		return pkey;
+	return NULL;
+}
+
 
 static int tpm_create_srk_policy(void *secret)
 {

From uri at ll.mit.edu  Wed Nov 16 15:56:05 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 16 Nov 2016 15:56:05 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479311176.3525.6.camel@HansenPartnership.com>
References: <1479311176.3525.6.camel@HansenPartnership.com>
Message-ID: <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>

My apologies ? I don?t fully understand ?file based engine keys?. I thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or smartcard, etc), or in a file. If a key is in a file ? it?s not an ?engine key?.

What am I missing, and what?s your use case(s)?
? 
Regards,
Uri


On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" <openssl-dev-bounces at openssl.org on behalf of James.Bottomley at HansenPartnership.com> wrote:

    [David Woodhouse told me that openssl-dev is a closed list, so the
    original messages got trashed.  This is a resend with apologies to
    David and Peter]
    
    One of the principle problems of using TPM based keys is that there's
    no easy way of integrating them with standard file based keys.  This
    proposal adds a generic method for handling file based engine keys that
    can be loaded as PEM files.  Integration into the PEM loader requires a
    BIO based engine API callback which the first patch adds.  The second
    patch checks to see if the key can be loaded by any of the present
    engines.  Note that this requires that any engine which is to be used
    must be present and initialised via openssl.cnf.
    
    I'll also post to this list the patch to openssl_tpm_engine that makes
    use if this infrastructure so the integration of the whole can be seen.
     It should also be noted that gnutls has had this functionality since
    2012.
    
    The patch was done against 1.0.2h for easier testing and you can try it
    and the openssl_tpm_engine out (if you run openSUSE) here:
    
    https://build.opensuse.org/project/show/home:jejb1:Tumbleweed
    
    James
    
    ---
    
    James Bottomley (2):
      engine: add new flag based method for loading engine keys
      pem: load engine keys
    
     crypto/engine/eng_int.h  |  1 +
     crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
     crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
     crypto/pem/pem_pkey.c    |  5 +++++
     4 files changed, 70 insertions(+)
    
    -- 
    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/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161116/39f1ddb1/attachment-0001.bin>

From levitte at openssl.org  Wed Nov 16 18:07:03 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 16 Nov 2016 19:07:03 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
References: <1479311176.3525.6.camel@HansenPartnership.com>
 <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
Message-ID: <20161116.190703.2026777923936653632.levitte@openssl.org>

If I understand correctly, the intention is to avoid having to use
ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
to the openssl commands, and to avoid having to remember some cryptic
key identity to give with '-key'.  Instead of all that, just give the
name of a .pem file with '-key' and if that file contains some kind of
magic information that the engine can understand, it will dig out a
reference to the hw protected key.

Many years ago, I was thinking of something along the same lines, but
with a .pem file that would just have a few headers, holding the name
of the intended engine and the key identity, something like this:

    -----BEGIN PRIVATE KEY-----
    X-key-id: flarflarflar
    X-key-engine: foo
    -----END PRIVATE KEY-----

The intent was that the PEM code would be massaged to recognise these
headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
with those data and that would be it.

James, did I catch your intention about right?  I think that's
essentially what e_tpm.c does for loading keys, right?

Cheers,
Richard ( gotta love to see someone use "flarflarflar" as a key id ;-) )

In message <60F14E07-D0DC-486F-AFF7-C74F5929B947 at ll.mit.edu> on Wed, 16 Nov 2016 15:56:05 +0000, "Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> said:

uri> My apologies ? I don?t fully understand ?file based engine keys?. I thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or smartcard, etc), or in a file. If a key is in a file ? it?s not an ?engine key?.
uri> 
uri> What am I missing, and what?s your use case(s)?
uri> ? 
uri> Regards,
uri> Uri
uri> 
uri> 
uri> On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" <openssl-dev-bounces at openssl.org on behalf of James.Bottomley at HansenPartnership.com> wrote:
uri> 
uri>     [David Woodhouse told me that openssl-dev is a closed list, so the
uri>     original messages got trashed.  This is a resend with apologies to
uri>     David and Peter]
uri>     
uri>     One of the principle problems of using TPM based keys is that there's
uri>     no easy way of integrating them with standard file based keys.  This
uri>     proposal adds a generic method for handling file based engine keys that
uri>     can be loaded as PEM files.  Integration into the PEM loader requires a
uri>     BIO based engine API callback which the first patch adds.  The second
uri>     patch checks to see if the key can be loaded by any of the present
uri>     engines.  Note that this requires that any engine which is to be used
uri>     must be present and initialised via openssl.cnf.
uri>     
uri>     I'll also post to this list the patch to openssl_tpm_engine that makes
uri>     use if this infrastructure so the integration of the whole can be seen.
uri>      It should also be noted that gnutls has had this functionality since
uri>     2012.
uri>     
uri>     The patch was done against 1.0.2h for easier testing and you can try it
uri>     and the openssl_tpm_engine out (if you run openSUSE) here:
uri>     
uri>     https://build.opensuse.org/project/show/home:jejb1:Tumbleweed
uri>     
uri>     James
uri>     
uri>     ---
uri>     
uri>     James Bottomley (2):
uri>       engine: add new flag based method for loading engine keys
uri>       pem: load engine keys
uri>     
uri>      crypto/engine/eng_int.h  |  1 +
uri>      crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
uri>      crypto/engine/engine.h   | 26 ++++++++++++++++++++++++++
uri>      crypto/pem/pem_pkey.c    |  5 +++++
uri>      4 files changed, 70 insertions(+)
uri>     
uri>     -- 
uri>     openssl-dev mailing list
uri>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
uri>     

From rsalz at akamai.com  Wed Nov 16 21:03:55 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 16 Nov 2016 21:03:55 +0000
Subject: [openssl-dev] [RFC 1/2] engine: add new flag based method
	for	loading engine keys
In-Reply-To: <1479311275.3525.8.camel@HansenPartnership.com>
References: <1479139186.2630.9.camel@HansenPartnership.com>
 <1479311275.3525.8.camel@HansenPartnership.com>
Message-ID: <1b68ed6fd6db4a229c457584e7a80e5d@usma1ex-dag1mb1.msg.corp.akamai.com>

It is a heck of a lot easier for everyone if you make pull requests and not just mail big patches.  Can you do that?

From steve at openssl.org  Wed Nov 16 22:06:26 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 16 Nov 2016 22:06:26 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161116.190703.2026777923936653632.levitte@openssl.org>
References: <1479311176.3525.6.camel@HansenPartnership.com>
 <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
 <20161116.190703.2026777923936653632.levitte@openssl.org>
Message-ID: <20161116220626.GA16915@openssl.org>

On Wed, Nov 16, 2016, Richard Levitte wrote:

> If I understand correctly, the intention is to avoid having to use
> ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
> to the openssl commands, and to avoid having to remember some cryptic
> key identity to give with '-key'.  Instead of all that, just give the
> name of a .pem file with '-key' and if that file contains some kind of
> magic information that the engine can understand, it will dig out a
> reference to the hw protected key.
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
>     -----BEGIN PRIVATE KEY-----
>     X-key-id: flarflarflar
>     X-key-engine: foo
>     -----END PRIVATE KEY-----
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 

Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
PKCS#8.

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

From uri at ll.mit.edu  Wed Nov 16 22:11:18 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 16 Nov 2016 22:11:18 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161116220626.GA16915@openssl.org>
References: <1479311176.3525.6.camel@HansenPartnership.com>
 <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
 <20161116.190703.2026777923936653632.levitte@openssl.org>
 <20161116220626.GA16915@openssl.org>
Message-ID: <2C32943A-76A0-4FDE-A67E-393367F31861@ll.mit.edu>

Thank you! I think I understand. (Sounds like an ugly and hardly necessary complication to me ? not to mention that there might not be a filesystem to keep those around, but?)
? 
Regards,
Uri


On 11/16/16, 5:06 PM, "openssl-dev on behalf of Dr. Stephen Henson" <openssl-dev-bounces at openssl.org on behalf of steve at openssl.org> wrote:

    On Wed, Nov 16, 2016, Richard Levitte wrote:
    
    > If I understand correctly, the intention is to avoid having to use
    > ENGINE_load_private_key() directly or having to say '-keyform ENGINE'
    > to the openssl commands, and to avoid having to remember some cryptic
    > key identity to give with '-key'.  Instead of all that, just give the
    > name of a .pem file with '-key' and if that file contains some kind of
    > magic information that the engine can understand, it will dig out a
    > reference to the hw protected key.
    > 
    > Many years ago, I was thinking of something along the same lines, but
    > with a .pem file that would just have a few headers, holding the name
    > of the intended engine and the key identity, something like this:
    > 
    >     -----BEGIN PRIVATE KEY-----
    >     X-key-id: flarflarflar
    >     X-key-engine: foo
    >     -----END PRIVATE KEY-----
    > 
    > The intent was that the PEM code would be massaged to recognise these
    > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
    > with those data and that would be it.
    > 
    
    Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
    or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
    PKCS#8.
    
    Steve.
    --
    Dr Stephen N. Henson. OpenSSL project core developer.
    Commercial tech support now available see: http://www.openssl.org
    -- 
    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/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161116/e7f7b62c/attachment.bin>

From steve at openssl.org  Wed Nov 16 22:18:05 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 16 Nov 2016 22:18:05 +0000
Subject: [openssl-dev] [RFC 1/2] engine: add new flag based method for
 loading engine keys
In-Reply-To: <1479311275.3525.8.camel@HansenPartnership.com>
References: <1479139186.2630.9.camel@HansenPartnership.com>
 <1479311275.3525.8.camel@HansenPartnership.com>
Message-ID: <20161116221805.GA17385@openssl.org>

On Wed, Nov 16, 2016, James Bottomley wrote:

> The assumption in all the current engine code is that key_id can be
> passed as something like a file name.

Well no it's a null terminated string whose meaning is engine specific. In
some cases it is a key ID, in others it is a more complex string indicating
multiple parameters.

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

From openssl at roumenpetrov.info  Thu Nov 17 07:33:11 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Thu, 17 Nov 2016 09:33:11 +0200
Subject: [openssl-dev] [RFC 1/2] engine: add new flag based method for
 loading engine keys
In-Reply-To: <13fbc22efacc1826f81594dccea1df76.squirrel@twosheds.infradead.org>
References: <1479139186.2630.9.camel@HansenPartnership.com>
 <1479139281.2630.11.camel@HansenPartnership.com>
 <13fbc22efacc1826f81594dccea1df76.squirrel@twosheds.infradead.org>
Message-ID: <582D5D37.8010305@roumenpetrov.info>

David Woodhouse wrote:
>> The assumption in all the current engine code is that key_id can be
>> passed as something like a file name.
This is mostly documentation issue.
Usually OpenSSL man pages use filename for <KEY>, but actually it is 
just a string and engine is responsible how to process

>>   There are some new users that
>> actually want to pass a BIO, so add a new load_key method for engines
>> that takes a flag value.
Engine could use some URN formats for <KEY>. For instance if <KEY> 
starts with file:/ engile could try to load from filesystem.

>> The first defined flag is
>> ENGINE_LOAD_KEY_FLAG_BIO which means that the key_id is actually a bio
>> pointer.
I'm not sure that is good idea to pass pointers between loadable 
modules. It could be used if there is no alternative. In this case URN 
format for  <KEY> could inform engine how to load key.

[SNIP]

Regadrs,
Roumen Petrov

From dwmw2 at infradead.org  Sat Nov 19 04:43:38 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 18 Nov 2016 20:43:38 -0800
Subject: [openssl-dev] [RFC 1/2] engine: add new flag based method for
 loading engine keys
In-Reply-To: <582D5D37.8010305@roumenpetrov.info>
References: <1479139186.2630.9.camel@HansenPartnership.com>
 <1479139281.2630.11.camel@HansenPartnership.com>
 <13fbc22efacc1826f81594dccea1df76.squirrel@twosheds.infradead.org>
 <582D5D37.8010305@roumenpetrov.info>
Message-ID: <1479530618.4382.6.camel@infradead.org>

On Thu, 2016-11-17 at 09:33 +0200, Roumen Petrov wrote:
> David Woodhouse wrote:
> > > The assumption in all the current engine code is that key_id can be
> > > passed as something like a file name.
> 
> This is mostly documentation issue.
> Usually OpenSSL man pages use filename for <KEY>, but actually it is?
> just a string and engine is responsible how to process

Right. In engine_pkcs11 it's a RFC7512 PKCS#11 URI and not a filename.

> > > ? There are some new users that
> > > actually want to pass a BIO, so add a new load_key method for
> > > engines
> > > that takes a flag value.
> 
> Engine could use some URN formats for <KEY>. For instance if <KEY>?
> starts with file:/ engile could try to load from filesystem.

Note that GnuTLS has a URN format for keys stored in the TPM. See
output of 'tpmtool --list' for example. The TPM engine should probably
accept those.

But this doesn't help with the case where we *have* the actual
(wrapped) key data in memory already ? unless you pass in a string
which is a base64-encoded form of that, which is kind of horrid.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161118/078a149b/attachment.bin>

From dwmw2 at infradead.org  Mon Nov 21 13:42:29 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 21 Nov 2016 13:42:29 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161116.190703.2026777923936653632.levitte@openssl.org>
References: <1479311176.3525.6.camel@HansenPartnership.com>
 <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
 <20161116.190703.2026777923936653632.levitte@openssl.org>
Message-ID: <1479735749.8937.5.camel@infradead.org>

On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
> ??? -----BEGIN PRIVATE KEY-----
> ??? X-key-id: flarflarflar
> ??? X-key-engine: foo
> ??? -----END PRIVATE KEY-----
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?? I think that's
> essentially what e_tpm.c does for loading keys, right?

Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
and had the "tpm" engine automatically loaded on demand. It needs to be
 something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv?).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ?.

-- 
dwmw2

? http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161121/9028e2b0/attachment.bin>

From uri at ll.mit.edu  Mon Nov 21 13:50:43 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 21 Nov 2016 13:50:43 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
Message-ID: <20161121135052.18280523.78584.102746@ll.mit.edu>

Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :).

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: David Woodhouse
Sent: Monday, November 21, 2016 08:43
To: Richard Levitte; openssl-dev at openssl.org
Reply To: openssl-dev at openssl.org
Cc: James Bottomley
Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
> ??? -----BEGIN PRIVATE KEY-----
> ??? X-key-id: flarflarflar
> ??? X-key-engine: foo
> ??? -----END PRIVATE KEY-----
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 
> James, did I catch your intention about right?? I think that's
> essentially what e_tpm.c does for loading keys, right?
?
Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
and had the "tpm" engine automatically loaded on demand. It needs to be
something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv?).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ?.

-- 
dwmw2

? http://david.woodhou.se/draft-woodhouse-cert-best-practice.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/20161121/e24c16f9/attachment-0001.bin>

From nmav at redhat.com  Mon Nov 21 14:09:21 2016
From: nmav at redhat.com (Nikos Mavrogiannopoulos)
Date: Mon, 21 Nov 2016 15:09:21 +0100
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479735749.8937.5.camel@infradead.org>
References: <1479311176.3525.6.camel@HansenPartnership.com>
 <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
 <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
Message-ID: <1479737361.2790.17.camel@redhat.com>

On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote:

> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
> added that a few years back (it used to just dump the binary blob
> instead). Both the TPM ENGINE and GnuTLS will load those files, as
> noted at http://www.infradead.org/openconnect/tpm.html
> The problem is that applications have to jump through special hoops
> to
> recognise the files and invoke the engine (and there's a special API
> in
> GnuTLS too). It would be good if the appropriate engine could be
> invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations
> when
> presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)

Note that for TPM wrapped keys, there was no new API introduced for
gnutls. The intention is to access such keys using a special URI [0].
However, since tpm2.0 is a completely different beast, I no longer
believe on direct TPM support, without a PKCS#11 wrapper.

[0].?https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

regards,
Nikos


From James.Bottomley at HansenPartnership.com  Mon Nov 21 16:05:47 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Mon, 21 Nov 2016 08:05:47 -0800
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479735749.8937.5.camel@infradead.org>
References: <1479311176.3525.6.camel@HansenPartnership.com>
 <60F14E07-D0DC-486F-AFF7-C74F5929B947@ll.mit.edu>
 <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
Message-ID: <1479744347.2309.21.camel@HansenPartnership.com>

On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote:
> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> > 
> > Many years ago, I was thinking of something along the same lines, 
> > but with a .pem file that would just have a few headers, holding 
> > the name of the intended engine and the key identity, something
> > like this:
> > 
> >     -----BEGIN PRIVATE KEY-----
> >     X-key-id: flarflarflar
> >     X-key-engine: foo
> >     -----END PRIVATE KEY-----
> > 
> > The intent was that the PEM code would be massaged to recognise 
> > these headers and would then use ENGINE_by_id() /
> > ENGINE_load_private_key() with those data and that would be it.
> > 
> > James, did I catch your intention about right?  I think that's
> > essentially what e_tpm.c does for loading keys, right?

Yes, that's right.  When any SSL program sees a TPM wrapped key, it
should just do the right thing if it has the engine capability without
needing the user to add any options to the command line.

> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
> added that a few years back (it used to just dump the binary blob
> instead). Both the TPM ENGINE and GnuTLS will load those files, as
> noted at http://www.infradead.org/openconnect/tpm.html
> 
> The problem is that applications have to jump through special hoops 
> to recognise the files and invoke the engine (and there's a special 
> API in GnuTLS too). It would be good if the appropriate engine could 
> be invoked *automatically*, so the crypto library just does the right
> thing without all the applications even having to *know* about it.
> (Just like GnuTLS will automatically Just Work in many situations 
> when presented with a PKCS#11 URI instead a filename, as OpenSSL also
> should, but doesn't yet.)
> 
> However, the contents of the PEM file should *not* be OpenSSL
> -specific and have engine names; I objected to James's original 
> incarnation of this, which had something like
>  -----BEGIN tpm ENGINE PRIVATE KEY-----
> and had the "tpm" engine automatically loaded on demand. It needs to 
> be  something generic. Which means engines need to indicate *which* 
> PEM headers they can grok. And maybe the solution to this will tie in
> with the general fixes we need for "normal" key files, so that
> applications can Just Work with all of those too (qv?).

Right, I forgot to add in the blurb that I'm looking for a mechanism
that all SSL implementations could follow, so it can't be tied to
anything specific in openSSL (like the engine name).  I modelled it on
gnutls because that has the same "just works(tm)" characteristic that I
was looking for.

> Once the dust settles on TPMv2.0 we should probably put together an I
> -D for the TPM-wrapped blob PEM files. And I should definitely add
> something about them to ?.

Once we agree, I'll be happy to write up something.  We can use the pem
header concept to extend this format if it becomes necessary.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161121/c6bef02a/attachment.bin>

From levitte at openssl.org  Mon Nov 21 22:14:09 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 21 Nov 2016 23:14:09 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161121135052.18280523.78584.102746@ll.mit.edu>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
Message-ID: <20161121.231409.1291950661164184609.levitte@openssl.org>

I'm leaning in that direction as well.

Speaking of URIs, you might be interested in some work I did last
week, which would do good to get a bit of external scrutiny.

https://github.com/openssl/openssl/pull/1961 (for URI decoding)
https://github.com/openssl/openssl/pull/1962 (a STORE module that
essentially uses a URI and tries to fetch certs, keys, crls, ... from
it)

Please have a look.

Cheers,
Richard

In message <20161121135052.18280523.78584.102746 at ll.mit.edu> on Mon, 21 Nov 2016 13:50:43 +0000, "Blumenthal, Uri - 0553 - MITLL" <uri at ll.mit.edu> said:

uri> Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :).
uri> 
uri> Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
uri> ? Original Message ?
uri> From: David Woodhouse
uri> Sent: Monday, November 21, 2016 08:43
uri> To: Richard Levitte; openssl-dev at openssl.org
uri> Reply To: openssl-dev at openssl.org
uri> Cc: James Bottomley
uri> Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl
uri> 
uri> On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
uri> > 
uri> > Many years ago, I was thinking of something along the same lines, but
uri> > with a .pem file that would just have a few headers, holding the name
uri> > of the intended engine and the key identity, something like this:
uri> > 
uri> > ??? -----BEGIN PRIVATE KEY-----
uri> > ??? X-key-id: flarflarflar
uri> > ??? X-key-engine: foo
uri> > ??? -----END PRIVATE KEY-----
uri> > 
uri> > The intent was that the PEM code would be massaged to recognise these
uri> > headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
uri> > with those data and that would be it.
uri> > 
uri> > James, did I catch your intention about right?? I think that's
uri> > essentially what e_tpm.c does for loading keys, right?
uri> ?
uri> Right. The TPM engine currently uses ----BEGIN TSS KEY BLOB-----; I
uri> added that a few years back (it used to just dump the binary blob
uri> instead). Both the TPM ENGINE and GnuTLS will load those files, as
uri> noted at http://www.infradead.org/openconnect/tpm.html
uri> 
uri> The problem is that applications have to jump through special hoops to
uri> recognise the files and invoke the engine (and there's a special API in
uri> GnuTLS too). It would be good if the appropriate engine could be
uri> invoked *automatically*, so the crypto library just does the right
uri> thing without all the applications even having to *know* about it.
uri> (Just like GnuTLS will automatically Just Work in many situations when
uri> presented with a PKCS#11 URI instead a filename, as OpenSSL also
uri> should, but doesn't yet.)
uri> 
uri> However, the contents of the PEM file should *not* be OpenSSL-specific
uri> and have engine names; I objected to James's original incarnation of
uri> this, which had something like -----BEGIN tpm ENGINE PRIVATE KEY-----
uri> and had the "tpm" engine automatically loaded on demand. It needs to be
uri> something generic. Which means engines need to indicate *which* PEM
uri> headers they can grok. And maybe the solution to this will tie in with
uri> the general fixes we need for "normal" key files, so that applications
uri> can Just Work with all of those too (qv?).
uri> 
uri> Once the dust settles on TPMv2.0 we should probably put together an I-D 
uri> for the TPM-wrapped blob PEM files. And I should definitely add
uri> something about them to ?.
uri> 
uri> -- 
uri> dwmw2
uri> 
uri> ? http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

From dwmw2 at infradead.org  Tue Nov 22 11:57:42 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 11:57:42 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161121135052.18280523.78584.102746@ll.mit.edu>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
Message-ID: <1479815862.8937.22.camel@infradead.org>

On Mon, 2016-11-21 at 13:50 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> Frankly, I think this approach of specially-encoded PEM or DER files
> telling the app what key to ask from the engine is madness, compared
> to the straightforward URI approach (no pun intended :).

Right. There are two separate things that the TPM can do for keys.

There is storage in the TPM itself, and you can reference a key therein
by its UUID. In Nikos's draft, and in GnuTLS, you end up with something
like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user

To use a PEM file for that does seem like madness; I agree.

However, Nikos's draft also supports a URI of the form:
 tpmkey:file=/foo/bar/key.pem

This, I do not like. It runs entirely contrary to my assertion in
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that
applications should Just Bloody Work with whatever file they're handed,
without needing to be *told* what the file contains.

Besides, it requires files in the form described by the Portable Data
section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
(which is mostly redundant as in this case we're always talking about
key blobs), the blob length (which is entirely redundant) and then the
actual blob as an OCTET STRING. I don't know of any tool which actually
creates such files.

The -----BEGIN TSS KEY BLOB----- PEM files which are created and used
by both GnuTLS and OpenSSL TPM engine contain *just* the OCTET STRING
containing the blob itself.

I assert that if the application is given such a PEM blob (by filename,
or just text embedded in a configuration file, or whatever), then it
MUST NOT require any further information about the contents of that
blob, except perhaps a password.

I have updated my draft with a section about TPM keys:
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.4

We should probably consolidate Nikos's now-expired draft with a
documentation of the -----BEGIN TSS KEY BLOB----- PEM format,?as well
as bringing it up to date with the v2.0 specifications as appropriate.

I'd *like* to think that we can punt it to PKCS#11 at least for TPM2,
but I'm not sure. PKCS#11 doesn't make it easy to deal with the fact
that there can be multiple PINs for the various keys in the chain, and
doesn't easily cope with the fact that the key material might not be
stored in the TPM and accessible by reference; it actually has to be
*loaded*. I do not want to inflict another horror like nss-pem on the
world... :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/c5b6629d/attachment-0001.bin>

From levitte at openssl.org  Tue Nov 22 12:48:59 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 13:48:59 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479744347.2309.21.camel@HansenPartnership.com>
References: <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
 <1479744347.2309.21.camel@HansenPartnership.com>
Message-ID: <20161122.134859.1138930452149962704.levitte@openssl.org>

In message <1479744347.2309.21.camel at HansenPartnership.com> on Mon, 21 Nov 2016 08:05:47 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Mon, 2016-11-21 at 13:42 +0000, David Woodhouse wrote:
James.Bottomley> > On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
James.Bottomley> > > 
James.Bottomley> > > Many years ago, I was thinking of something along the same lines, 
James.Bottomley> > > but with a .pem file that would just have a few headers, holding 
James.Bottomley> > > the name of the intended engine and the key identity, something
James.Bottomley> > > like this:
James.Bottomley> > > 
James.Bottomley> > >     -----BEGIN PRIVATE KEY-----
James.Bottomley> > >     X-key-id: flarflarflar
James.Bottomley> > >     X-key-engine: foo
James.Bottomley> > >     -----END PRIVATE KEY-----
James.Bottomley> > > 
James.Bottomley> > > The intent was that the PEM code would be massaged to recognise 
James.Bottomley> > > these headers and would then use ENGINE_by_id() /
James.Bottomley> > > ENGINE_load_private_key() with those data and that would be it.
James.Bottomley> > > 
James.Bottomley> > > James, did I catch your intention about right?  I think that's
James.Bottomley> > > essentially what e_tpm.c does for loading keys, right?
James.Bottomley> 
James.Bottomley> Yes, that's right.  When any SSL program sees a TPM wrapped key, it
James.Bottomley> should just do the right thing if it has the engine capability without
James.Bottomley> needing the user to add any options to the command line.

Mm...  I'm not sure I agree with the method, passing a BIO for the
key_id.  I would much rather have seen a patch where OpenSSL's PEM
module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
from it, securing it somehow (since key_id is expected to be be NUL
terminated) and pass that to the engine.

James.Bottomley> > Once the dust settles on TPMv2.0 we should probably put together an I
James.Bottomley> > -D for the TPM-wrapped blob PEM files. And I should definitely add
James.Bottomley> > something about them to ?.
James.Bottomley> 
James.Bottomley> Once we agree, I'll be happy to write up something.  We can use the pem
James.Bottomley> header concept to extend this format if it becomes necessary.

My vote goes to a URI based spec rather than bastardising PEM files.
I understand this kinda throws years of developmemt out the window,
but there you have it.

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

From dwmw2 at infradead.org  Tue Nov 22 12:53:15 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 12:53:15 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.134859.1138930452149962704.levitte@openssl.org>
References: <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
 <1479744347.2309.21.camel@HansenPartnership.com>
 <20161122.134859.1138930452149962704.levitte@openssl.org>
Message-ID: <1479819195.8937.26.camel@infradead.org>

On Tue, 2016-11-22 at 13:48 +0100, Richard Levitte wrote:
> Mm...? I'm not sure I agree with the method, passing a BIO for the
> key_id.? I would much rather have seen a patch where OpenSSL's PEM
> module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
> from it, securing it somehow (since key_id is expected to be be NUL
> terminated) and pass that to the engine.

Agreed.

> My vote goes to a URI based spec rather than bastardising PEM files.
> I understand this kinda throws years of developmemt out the window,
> but there you have it.

I think we need both. We need the URI for the keys stored *in* the TPM
where we just need to reference them.?And we need (non-bastardised) PEM
files with TPM-wrapped key blobs. The latter is what the engine
supports right now (by filename only).


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/3fdd2116/attachment.bin>

From rsalz at akamai.com  Tue Nov 22 12:54:12 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Nov 2016 12:54:12 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.134859.1138930452149962704.levitte@openssl.org>
References: <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
 <1479744347.2309.21.camel@HansenPartnership.com>
 <20161122.134859.1138930452149962704.levitte@openssl.org>
Message-ID: <4239f95492fd4ec4b18dd1b8ed545902@usma1ex-dag1mb1.msg.corp.akamai.com>

> would much rather have seen a patch where OpenSSL's PEM module is
> tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing

Yes, that would be much more consistent with the existing OpenSSL code which -- like it or not -- works that way.

> My vote goes to a URI based spec rather than bastardising PEM files.

Sure, if you can figure out which URI scheme to use; there are many of them. :)

	/r$


From levitte at openssl.org  Tue Nov 22 13:06:08 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 14:06:08 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479815862.8937.22.camel@infradead.org>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
 <1479815862.8937.22.camel@infradead.org>
Message-ID: <20161122.140608.1551186145366451030.levitte@openssl.org>

In message <1479815862.8937.22.camel at infradead.org> on Tue, 22 Nov 2016 11:57:42 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Mon, 2016-11-21 at 13:50 +0000, Blumenthal, Uri - 0553 - MITLL
dwmw2> wrote:
dwmw2> > Frankly, I think this approach of specially-encoded PEM or DER files
dwmw2> > telling the app what key to ask from the engine is madness, compared
dwmw2> > to the straightforward URI approach (no pun intended :).
dwmw2> 
dwmw2> Right. There are two separate things that the TPM can do for keys.
dwmw2> 
dwmw2> There is storage in the TPM itself, and you can reference a key therein
dwmw2> by its UUID. In Nikos's draft, and in GnuTLS, you end up with something
dwmw2> like tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user
dwmw2> 
dwmw2> To use a PEM file for that does seem like madness; I agree.
dwmw2> 
dwmw2> However, Nikos's draft also supports a URI of the form:
dwmw2>  tpmkey:file=/foo/bar/key.pem
dwmw2> 
dwmw2> This, I do not like. It runs entirely contrary to my assertion in
dwmw2> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html that
dwmw2> applications should Just Bloody Work with whatever file they're handed,
dwmw2> without needing to be *told* what the file contains.

Not sure I follow...  'file=/foo/bar/key.pem' is just a path /
parameter that the 'tpmkey' handler is free to interpret in whatever
way it sees fit.  For me as a user, it's just a string.  For all I
care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
That doesn't say anything about the contents of /foo/bar/key.pem, not
more than file:/foo/bar/key.pem does, or even if there actually is a
file /foo/bar/key.pem.  Maybe I misunderstand what you're after...

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

From dwmw2 at infradead.org  Tue Nov 22 13:09:18 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 13:09:18 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <4239f95492fd4ec4b18dd1b8ed545902@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
 <1479744347.2309.21.camel@HansenPartnership.com>
 <20161122.134859.1138930452149962704.levitte@openssl.org>
 <4239f95492fd4ec4b18dd1b8ed545902@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1479820158.8937.29.camel@infradead.org>

On Tue, 2016-11-22 at 12:54 +0000, Salz, Rich wrote:
> > would much rather have seen a patch where OpenSSL's PEM module is
> > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing
> 
> Yes, that?would be much more consistent with the existing OpenSSL
> code which -- like it or not -- works that way.

Yeah. Although I'd note that the OpenSSL code only works that way for
PEM files. I really want to make it work the same way for DER files
too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
have to call different functions for PEM vs. DER files anyway.

> > My vote goes to a URI based spec rather than bastardising PEM files.
> 
> Sure, if you can figure out which URI scheme to use; there are many
> of them. :)

For TPM I am not aware of any scheme other than the one set out in
https://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-01

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/2c78c842/attachment-0001.bin>

From dwmw2 at infradead.org  Tue Nov 22 13:12:14 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 13:12:14 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.140608.1551186145366451030.levitte@openssl.org>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
 <1479815862.8937.22.camel@infradead.org>
 <20161122.140608.1551186145366451030.levitte@openssl.org>
Message-ID: <1479820334.8937.31.camel@infradead.org>

On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> 
> Not sure I follow...? 'file=/foo/bar/key.pem' is just a path /
> parameter that the 'tpmkey' handler is free to interpret in whatever
> way it sees fit.? For me as a user, it's just a string.? For all I
> care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> That doesn't say anything about the contents of /foo/bar/key.pem, not
> more than file:/foo/bar/key.pem does, or even if there actually is a
> file /foo/bar/key.pem.? Maybe I misunderstand what you're after...

Where files are involved, I do not want the application to be told:
 pkcs8:/foo/bar/key
 pkcs1:/foo/bar/key
 pkcs12:/foo/bar/key or
 tpmkey:/foo/bar/key

I only want the application to be told "/foo/bar/key"

It should work out what the contents are for *itself*. Whether they be
PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

And if the string it's given *isn't* a filename but is instead a
PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
Work too.

User pass string identifying key. Application Just Work?. dwmw2 happy.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/6e3d76f8/attachment.bin>

From levitte at openssl.org  Tue Nov 22 13:18:56 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 14:18:56 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479820158.8937.29.camel@infradead.org>
References: <20161122.134859.1138930452149962704.levitte@openssl.org>
 <4239f95492fd4ec4b18dd1b8ed545902@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479820158.8937.29.camel@infradead.org>
Message-ID: <20161122.141856.1869335431570395500.levitte@openssl.org>

In message <1479820158.8937.29.camel at infradead.org> on Tue, 22 Nov 2016 13:09:18 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 12:54 +0000, Salz, Rich wrote:
dwmw2> > > would much rather have seen a patch where OpenSSL's PEM module is
dwmw2> > > tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob from it, securing
dwmw2> > 
dwmw2> > Yes, that?would be much more consistent with the existing OpenSSL
dwmw2> > code which -- like it or not -- works that way.
dwmw2> 
dwmw2> Yeah. Although I'd note that the OpenSSL code only works that way for
dwmw2> PEM files. I really want to make it work the same way for DER files
dwmw2> too. There's an *attempt* in d2i_AutoPrivateKey() but that doesn't
dwmw2> handle encrypted PKCS#8 IIRC. Or PKCS#12. And the app still shouldn't
dwmw2> have to call different functions for PEM vs. DER files anyway.

Just let me shamelessly mention my STORE effort again ;-)
Among others, it does attempt to solve that very problem (in the
'file' scheme handler).

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

From levitte at openssl.org  Tue Nov 22 13:32:56 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 14:32:56 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479820334.8937.31.camel@infradead.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.140608.1551186145366451030.levitte@openssl.org>
 <1479820334.8937.31.camel@infradead.org>
Message-ID: <20161122.143256.1551128231641352425.levitte@openssl.org>

In message <1479820334.8937.31.camel at infradead.org> on Tue, 22 Nov 2016 13:12:14 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Not sure I follow...? 'file=/foo/bar/key.pem' is just a path /
dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever
dwmw2> > way it sees fit.? For me as a user, it's just a string.? For all I
dwmw2> > care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not
dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a
dwmw2> > file /foo/bar/key.pem.? Maybe I misunderstand what you're after...
dwmw2> 
dwmw2> Where files are involved, I do not want the application to be told:
dwmw2>  pkcs8:/foo/bar/key
dwmw2>  pkcs1:/foo/bar/key
dwmw2>  pkcs12:/foo/bar/key or
dwmw2>  tpmkey:/foo/bar/key
dwmw2> 
dwmw2> I only want the application to be told "/foo/bar/key"

Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM
type would be a way to go, wouldn't you say?  That, or add functionality
to have PEM content handlers added dynamically, one for each PEM
content type.
Just please, that "pass the BIO" hack...  sorry, I'm not a supporter.

dwmw2> It should work out what the contents are for *itself*. Whether they be
dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

Yeah, got it...  my thinking was on a tachnical level, that
'whatever.pem' would have to be handled by OpenSSL itself (or in URI
terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem'
would be handled by the 'tpmkey' scheme handler, which is a different
story to me.

I dunno about you, but to me, the URI scheme is not the same as an
indication of what contents I'll get.  But i guess that's a matter of
interpretation.

dwmw2> And if the string it's given *isn't* a filename but is instead a
dwmw2> PKCS#11 URI or a TPM URI according to Nikos's spec, that should Just
dwmw2> Work too.

You *do* indicate those with a URI scheme, though ;-)

dwmw2> User pass string identifying key. Application Just Work?. dwmw2 happy.

:-)

Cheers,
Richard ( who'd be *much* happier if his fingers didn't constantly
	  want to typ tmpkey ;-) )

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

From dwmw2 at infradead.org  Tue Nov 22 13:54:19 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 13:54:19 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.143256.1551128231641352425.levitte@openssl.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.140608.1551186145366451030.levitte@openssl.org>
 <1479820334.8937.31.camel@infradead.org>
 <20161122.143256.1551128231641352425.levitte@openssl.org>
Message-ID: <1479822859.8937.35.camel@infradead.org>

On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote:
> In message <1479820334.8937.31.camel at infradead.org> on Tue, 22 Nov 2016 13:12:14 +0000, David Woodhouse <dwmw2 at infradead.org> said:
> 
> dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote:
> dwmw2> > 
> dwmw2> > Not sure I follow...? 'file=/foo/bar/key.pem' is just a path /
> dwmw2> > parameter that the 'tpmkey' handler is free to interpret in whatever
> dwmw2> > way it sees fit.? For me as a user, it's just a string.? For all I
> dwmw2> > care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ=='
> dwmw2> > That doesn't say anything about the contents of /foo/bar/key.pem, not
> dwmw2> > more than file:/foo/bar/key.pem does, or even if there actually is a
> dwmw2> > file /foo/bar/key.pem.? Maybe I misunderstand what you're after...
> dwmw2> 
> dwmw2> Where files are involved, I do not want the application to be told:
> dwmw2>? pkcs8:/foo/bar/key
> dwmw2>? pkcs1:/foo/bar/key
> dwmw2>? pkcs12:/foo/bar/key or
> dwmw2>? tpmkey:/foo/bar/key
> dwmw2> 
> dwmw2> I only want the application to be told "/foo/bar/key"
> 
> Ah, yeah, ok, so basically have OpenSSL support the "TSS KEY BLOB" PEM
> type would be a way to go, wouldn't you say?? That, or add functionality
> to have PEM content handlers added dynamically, one for each PEM
> content type.
> Just please, that "pass the BIO" hack...? sorry, I'm not a supporter.

I think the number of "new" PEM formats is going to be vanishingly
small, and it's OK to have knowledge of them hard-coded in OpenSSL
rather than having a fully dynamic mechanism.

Doing it dynamically would be painful ? either the appropriate engine
needs to be loaded already, or we need a mapping from PEM 'BEGIN'
string to the engine name somehow.

> dwmw2> It should work out what the contents are for *itself*. Whether they be
> dwmw2> PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
> 
> Yeah, got it...? my thinking was on a tachnical level, that
> 'whatever.pem' would have to be handled by OpenSSL itself (or in URI
> terms, by the 'file' scheme handler), while 'tpmkey:file=whatever.pem'
> would be handled by the 'tpmkey' scheme handler, which is a different
> story to me.

Yes, they end up being routed to the same engine via entirely different
paths. Both need resolving, and we need not to conflate the two.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/8829833d/attachment-0001.bin>

From dwmw2 at infradead.org  Tue Nov 22 13:57:12 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 13:57:12 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.141856.1869335431570395500.levitte@openssl.org>
References: <20161122.134859.1138930452149962704.levitte@openssl.org>
 <4239f95492fd4ec4b18dd1b8ed545902@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
Message-ID: <1479823032.8937.37.camel@infradead.org>

On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
> 
> Just let me shamelessly mention my STORE effort again ;-)
> Among others, it does attempt to solve that very problem (in the
> 'file' scheme handler).

Neat. Note that I have a ready-made test suite for you in OpenConnect:
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

For every one of the key files therein, does your current
implementation work? :)

(Yeah, I need to sort out the tpm emulator in the test environment,
then add some -----BEGIN TSS KEY BLOB----- files too :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/b2f6f238/attachment.bin>

From rsalz at akamai.com  Tue Nov 22 14:42:35 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Nov 2016 14:42:35 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.143256.1551128231641352425.levitte@openssl.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.140608.1551186145366451030.levitte@openssl.org>
 <1479820334.8937.31.camel@infradead.org>
 <20161122.143256.1551128231641352425.levitte@openssl.org>
Message-ID: <da958b9e865a4268b95fd3e0b07742ff@usma1ex-dag1mb1.msg.corp.akamai.com>

> dwmw2> It should work out what the contents are for *itself*. Whether
> dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.

I disagree with this approach, but that's just my opinion.  I am worried about "keep trying something until it works" because you'll get strange errors you can't decode, 'only allow N tries' devices will lock you out, and the order in which you try things could result in needless long delays.

But don't let that stop you.

From levitte at openssl.org  Tue Nov 22 15:07:01 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 16:07:01 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <da958b9e865a4268b95fd3e0b07742ff@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1479820334.8937.31.camel@infradead.org>
 <20161122.143256.1551128231641352425.levitte@openssl.org>
 <da958b9e865a4268b95fd3e0b07742ff@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161122.160701.212825371819707426.levitte@openssl.org>

In message <da958b9e865a4268b95fd3e0b07742ff at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 14:42:35 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
rsalz> 
rsalz> I disagree with this approach, but that's just my opinion.  I am worried about "keep trying something until it works" because you'll get strange errors you can't decode, 'only allow N tries' devices will lock you out, and the order in which you try things could result in needless long delays.
rsalz> 
rsalz> But don't let that stop you.

I *think* the guessing part is just about the step of loading the file
content and transparently understanding what type of content it is.
That's basically looking at a bunch of bytes and recognising it for
what it is.  When that's done, the trial and error phase is over, and
for stuff that libcrypto has support for, libcrypto will be able to
act, deterministically.

>From the application point of view, this would be just one call, but
we are talking OpenSSL internals now, aren't we?

David, correct me if I got you wrong.

Cheers,
Richard

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

From levitte at openssl.org  Tue Nov 22 15:14:15 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 16:14:15 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479823032.8937.37.camel@infradead.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
Message-ID: <20161122.161415.1555282309472446656.levitte@openssl.org>

In message <1479823032.8937.37.camel at infradead.org> on Tue, 22 Nov 2016 13:57:12 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Just let me shamelessly mention my STORE effort again ;-)
dwmw2> > Among others, it does attempt to solve that very problem (in the
dwmw2> > 'file' scheme handler).
dwmw2> 
dwmw2> Neat. Note that I have a ready-made test suite for you in OpenConnect:
dwmw2> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
dwmw2> 
dwmw2> For every one of the key files therein, does your current
dwmw2> implementation work? :)
dwmw2> 
dwmw2> (Yeah, I need to sort out the tpm emulator in the test environment,
dwmw2> then add some -----BEGIN TSS KEY BLOB----- files too :)

All I can see is PEM files...  For any PEM content that OpenSSL
supports, the STORE 'file' scheme loader does as well.  That's just a
one liner, quite precisely this one:

https://github.com/openssl/openssl/pull/1962/files#diff-34958ca30387ac75fa5011f98c18b3baR69

The more interesting part is when it tries to load files it guesses
are raw DER.  It's currently only trying a few chosen content types,
I'm happy to add more as time goes.  However, I suspect that nothing
in your test suite will trigger that part.

TSS KEY BLOBs is a different thing.  That needs added PEM support, and
the STORE 'file' scheme loader will not have to be changed at all.

Cheers,
Richard

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

From levitte at openssl.org  Tue Nov 22 15:32:54 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 16:32:54 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479815862.8937.22.camel@infradead.org>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
 <1479815862.8937.22.camel@infradead.org>
Message-ID: <20161122.163254.492222610589754528.levitte@openssl.org>

In message <1479815862.8937.22.camel at infradead.org> on Tue, 22 Nov 2016 11:57:42 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> Besides, it requires files in the form described by the Portable Data
dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
dwmw2> (which is mostly redundant as in this case we're always talking about
dwmw2> key blobs), the blob length (which is entirely redundant) and then the
dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually
dwmw2> creates such files.

I'm just having a look at the spec (page 151 in
http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
and am a bit confused by the TssBlobType type.  Which is it in
practice, an ENUMERATED or an INTEGER?

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

From James.Bottomley at HansenPartnership.com  Tue Nov 22 15:44:10 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 22 Nov 2016 07:44:10 -0800
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.163254.492222610589754528.levitte@openssl.org>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
 <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
Message-ID: <1479829450.2376.10.camel@HansenPartnership.com>

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.camel at infradead.org> on Tue, 22 Nov
> 2016 11:57:42 +0000, David Woodhouse <dwmw2 at infradead.org> said:
> 
> dwmw2> Besides, it requires files in the form described by the
> Portable Data
> dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob
> type
> dwmw2> (which is mostly redundant as in this case we're always
> talking about
> dwmw2> key blobs), the blob length (which is entirely redundant) and
> then the
> dwmw2> actual blob as an OCTET STRING. I don't know of any tool which
> actually
> dwmw2> creates such files.
> 
> I'm just having a look at the spec (page 151 in
> http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
> a_A-final.pdf), and am a bit confused by the TssBlobType type.  Which 
> is it in practice, an ENUMERATED or an INTEGER?

It's actually here:

http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf

It's around page 101, section 10.3 the TPM_KEY12 structure.  That tells
you what to encrypt and how to construct the encrypted part of the
blob.  It refers to other structures, so you end up doing a bit of a
pointer chase through the document.

James



From dwmw2 at infradead.org  Tue Nov 22 15:44:57 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 15:44:57 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.160701.212825371819707426.levitte@openssl.org>
References: <1479820334.8937.31.camel@infradead.org>
 <20161122.143256.1551128231641352425.levitte@openssl.org>
 <da958b9e865a4268b95fd3e0b07742ff@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.160701.212825371819707426.levitte@openssl.org>
Message-ID: <1479829497.8937.39.camel@infradead.org>

On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote:
> In message <da958b9e865a4268b95fd3e0b07742ff at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 14:42:35 +0000, "Salz, Rich" <rsalz at akamai.com> said:
> 
> rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether
> rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else.
> rsalz> 
> rsalz> I disagree with this approach, but that's just my opinion.? I am worried about "keep trying something until it works" because you'll get strange errors you can't decode, 'only allow N tries' devices will lock you out, and the order in which you try things could result in needless long delays.
> rsalz> 
> rsalz> But don't let that stop you.
> 
> I *think* the guessing part is just about the step of loading the file
> content and transparently understanding what type of content it is.
> That's basically looking at a bunch of bytes and recognising it for
> what it is.? When that's done, the trial and error phase is over, and
> for stuff that libcrypto has support for, libcrypto will be able to
> act, deterministically.
> 
> From the application point of view, this would be just one call, but
> we are talking OpenSSL internals now, aren't we?
> 
> David, correct me if I got you wrong.

You have it entirely correct. Rich has a valid concern for the general
case, but it doesn't apply *here* because we're just talking about
interpreting files. No hardware token is going to get upset and lock
you out, just because you actually look inside the file and work out
what type it is, then treat it as that ? instead of forcing the
*application* to look inside the file first, then invoke the crypto
library differently for each type of file (or URI), as shown at 
http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c#l827

Basically, for every line in that load_certificate()?function and the
subfunctions it calls, I hate you :)

When it comes to talking to real hardware, Rich is absolutely right.
You don't just keep trying there. So if you look at the 'Locating
objects in PKCS#11' section of my best practice draft? you'll see that
you're only supposed to log into a given token if you *know* that's the
one you need ? either because you're looking for a key and you've
already found the corresponding certificate in that token without
having to log in, or because the PKCS#11 URI actually *specified* the
token unambiguously. But that's a separate issue.

-- 
dwmw2

? http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/6b18e92f/attachment.bin>

From dwmw2 at infradead.org  Tue Nov 22 15:49:34 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 15:49:34 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.161415.1555282309472446656.levitte@openssl.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
Message-ID: <1479829774.8937.41.camel@infradead.org>

On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote:
> The more interesting part is when it tries to load files it guesses
> are raw DER.? It's currently only trying a few chosen content types,
> I'm happy to add more as time goes.? However, I suspect that nothing
> in your test suite will trigger that part.

There's a selection of .der and .p12 files there too.

Adding non-ASCII passwords and running in different locales (and
stress-testing both the old and the new PKCS#12 BMPstring bugs) is
still on my TODO list.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/e5d6fd3c/attachment.bin>

From dwmw2 at infradead.org  Tue Nov 22 15:56:07 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 15:56:07 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.163254.492222610589754528.levitte@openssl.org>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
 <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
Message-ID: <1479830167.8937.43.camel@infradead.org>

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
> In message <1479815862.8937.22.camel at infradead.org> on Tue, 22 Nov 2016 11:57:42 +0000, David Woodhouse <dwmw2 at infradead.org> said:
> 
> dwmw2> Besides, it requires files in the form described by the Portable Data
> dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
> dwmw2> (which is mostly redundant as in this case we're always talking about
> dwmw2> key blobs), the blob length (which is entirely redundant) and then the
> dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually
> dwmw2> creates such files.
> 
> I'm just having a look at the spec (page 151 in
> http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
> and am a bit confused by the TssBlobType type.? Which is it in
> practice, an ENUMERATED or an INTEGER?

In practice, it doesn't get used at all. The object encoded with
-----BEGIN TSS KEY BLOB----- and used by both the OpenSSL TPM ENGINE
and by GnuTLS is not the TssBlob object that you're looking at.

It is *only* the OCTET STRING of the blob itself. Everything else is
redundant anyway.

$ openssl asn1parse -i -in tpmkey.pem -inform pem
????0:d=0??hl=4 l= 559 prim: OCTET STRING??????[HEX
DUMP]:010100000015000000060000000001000200030000000C0000080000000002000
000000000000000000100D6791E892D6B93830F026C6C66B365A0B61B3CBB5B36EA1A13
C67111D49711719E665B5EBAAB5F9CB04D7CC87C78DE56700CD6A8F9B94C92DF029983F
2DA8883841090CEAACD53453516843FEF6689AC5E7D8102B85141B86B2F0E8C99124A70
90C5FB35A902D672E56D2BC2654317DCF578692B8CC441E08E3CCEF8CE86219822250CA
3A23A70EF69B3A092B3DFA70F049B712B885B8EA576C9F3F4E54107DB8F8D678CCF376D
9299BB47013318999FA8099180815D99F90646588508AACF7527E7A6D38C6C53B78C9BA
6F693069F2906B82E5500D5209489E48C29A4B487564AC64CED3FC61D88EF0C27C0E5EE
5AFEB861E3B104F8FCABDBE07DBE4FE42D2B0000010091175251D67BE97DB4A4F48EF5D
515E9ED64287BF2DFCCCDD6E6791AADC7E6752F2A2DCD3CBC29AB8660947B78C1F15C30
26369AC4A6B5434996CDB3CA659A2A2F48BE26B7E3C5AEBD75A6B6BCB376650138DCAD0
00E46BD94139A9DD596355C0469463E0E7D68C9997724EC7CFACDDC8EFA3C81045F5076
284BA2CA0B935DCFC28793D1BC9E8D2F4F141788B92DA93D3B370C8A24AFF59DEAAC81F
5A96C2299CBA74AA651E0AF92122B4F7524D08027DA71EDB191B115722AEB7F97817346
4484778FF88BC56815420791D7F9FB1ADD781D979A85D69F31970F228A6A12C6FD4FC3C
AF7A9F8F933818D436C5552D7B60A1E48CDEC7E38FC452A359C6E1609EC

$ openconnect -c cert.pem -k tpmkey.pem auth.startssl.com -v
POST https://auth.startssl.com/
Attempting to connect to server 104.192.110.244:443
Connected to 104.192.110.244:443
Using certificate file cert.pem
Using private key file tpmkey.pem
TPM sign function called for 35 bytes.
Using client certificate '192.168.123.1'
TPM sign function called for 51 bytes.
SSL negotiation with auth.startssl.com
...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/68d9b741/attachment-0001.bin>

From dwmw2 at infradead.org  Tue Nov 22 16:09:26 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 16:09:26 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479829450.2376.10.camel@HansenPartnership.com>
References: <20161121135052.18280523.78584.102746@ll.mit.edu>
 <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
 <1479829450.2376.10.camel@HansenPartnership.com>
Message-ID: <1479830966.8937.45.camel@infradead.org>

On Tue, 2016-11-22 at 07:44 -0800, James Bottomley wrote:
> 
> > I'm just having a look at the spec (page 151 in
> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
> > a_A-final.pdf), and am a bit confused by the TssBlobType type.? Which 
> > is it in practice, an ENUMERATED or an INTEGER?
> 
> It's actually here:
> 
> http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
> 
> It's around page 101, section 10.3 the TPM_KEY12 structure.? That tells
> you what to encrypt and how to construct the encrypted part of the
> blob.? It refers to other structures, so you end up doing a bit of a
> pointer chase through the document.

The TPM_KEY12 structure is what's in the OCTET STRING (that I just
showed). But I believe we're looking at the ASN.1 on page 151 (?3.23
"Portable Data") of the TSS spec:

TssBlobType ::= ENUMERATED
{
	Key-Blob (1),    -- TCPA_KEY as returned from TPM
	PubKey-Blob (2), -- TCPA_PUBKEY as returned from TPM
	MigKey-Blob (3), -- TCPA_KEY as return from the TSP 
			Tspi_Key_CreateMigrationBlob
			In dedicated mode (see the command for details)
	SealedData-Blob (4),   -- TCPA_STORED_DATA as returned from TPM
	...
}

TssBlobType ::= INTEGER
TssBlob ::= SEQUENCE
{
	StructVersion INTEGER, -- Version of this structure; at the moment 1
	BlobType TssBlobType,  -- Type of Blob; see enum
	BlobLength INTEGER,    -- Length of Blob
	Blob OCTET STRING      -- Blob as returned from TPM (no ASN1 encoding)
}

To my knowledge nothing actually *implements* this TssBlob. Those PEM
files (like the one I just showed) only contain the OCTET STRING.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/9ccaff9f/attachment.bin>

From levitte at openssl.org  Tue Nov 22 16:14:13 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 17:14:13 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479829450.2376.10.camel@HansenPartnership.com>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
 <1479829450.2376.10.camel@HansenPartnership.com>
Message-ID: <20161122.171413.1442263606108805306.levitte@openssl.org>

In message <1479829450.2376.10.camel at HansenPartnership.com> on Tue, 22 Nov 2016 07:44:10 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
James.Bottomley> > In message <1479815862.8937.22.camel at infradead.org> on Tue, 22 Nov
James.Bottomley> > 2016 11:57:42 +0000, David Woodhouse <dwmw2 at infradead.org> said:
James.Bottomley> > 
James.Bottomley> > dwmw2> Besides, it requires files in the form described by the
James.Bottomley> > Portable Data
James.Bottomley> > dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob
James.Bottomley> > type
James.Bottomley> > dwmw2> (which is mostly redundant as in this case we're always
James.Bottomley> > talking about
James.Bottomley> > dwmw2> key blobs), the blob length (which is entirely redundant) and
James.Bottomley> > then the
James.Bottomley> > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which
James.Bottomley> > actually
James.Bottomley> > dwmw2> creates such files.
James.Bottomley> > 
James.Bottomley> > I'm just having a look at the spec (page 151 in
James.Bottomley> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat
James.Bottomley> > a_A-final.pdf), and am a bit confused by the TssBlobType type.  Which 
James.Bottomley> > is it in practice, an ENUMERATED or an INTEGER?
James.Bottomley> 
James.Bottomley> It's actually here:
James.Bottomley> 
James.Bottomley> http://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
James.Bottomley> 
James.Bottomley> It's around page 101, section 10.3 the TPM_KEY12 structure.  That tells
James.Bottomley> you what to encrypt and how to construct the encrypted part of the
James.Bottomley> blob.  It refers to other structures, so you end up doing a bit of a
James.Bottomley> pointer chase through the document.

I'm sorry, I have obviously had you a bit confused.  What I'm
currently interested in is decoding the content of a 'TSS KEY BLOB'
PEM file, and I assume that's a TssBlob type, yeah?

Cheers,
Richard

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

From dwmw2 at infradead.org  Tue Nov 22 16:15:36 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 16:15:36 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.171413.1442263606108805306.levitte@openssl.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
 <1479829450.2376.10.camel@HansenPartnership.com>
 <20161122.171413.1442263606108805306.levitte@openssl.org>
Message-ID: <1479831336.8937.46.camel@infradead.org>

On Tue, 2016-11-22 at 17:14 +0100, Richard Levitte wrote:
> 
> I'm sorry, I have obviously had you a bit confused.? What I'm
> currently interested in is decoding the content of a 'TSS KEY BLOB'
> PEM file, and I assume that's a TssBlob type, yeah?

No, it's not. (Sorry!)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/d355d0e1/attachment.bin>

From levitte at openssl.org  Tue Nov 22 16:21:42 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 17:21:42 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479830167.8937.43.camel@infradead.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
 <1479830167.8937.43.camel@infradead.org>
Message-ID: <20161122.172142.1234479047401597555.levitte@openssl.org>

In message <1479830167.8937.43.camel at infradead.org> on Tue, 22 Nov 2016 15:56:07 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote:
dwmw2> > In message <1479815862.8937.22.camel at infradead.org> on Tue, 22 Nov 2016 11:57:42 +0000, David Woodhouse <dwmw2 at infradead.org> said:
dwmw2> > 
dwmw2> > dwmw2> Besides, it requires files in the form described by the Portable Data
dwmw2> > dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type
dwmw2> > dwmw2> (which is mostly redundant as in this case we're always talking about
dwmw2> > dwmw2> key blobs), the blob length (which is entirely redundant) and then the
dwmw2> > dwmw2> actual blob as an OCTET STRING. I don't know of any tool which actually
dwmw2> > dwmw2> creates such files.
dwmw2> > 
dwmw2> > I'm just having a look at the spec (page 151 in
dwmw2> > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf),
dwmw2> > and am a bit confused by the TssBlobType type.? Which is it in
dwmw2> > practice, an ENUMERATED or an INTEGER?
dwmw2> 
dwmw2> In practice, it doesn't get used at all. The object encoded with
dwmw2> -----BEGIN TSS KEY BLOB----- and used by both the OpenSSL TPM ENGINE
dwmw2> and by GnuTLS is not the TssBlob object that you're looking at.
dwmw2> 
dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is
dwmw2> redundant anyway.

Oh!  Ok, that makes things much simpler (at least in a way)

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

From dwmw2 at infradead.org  Tue Nov 22 16:28:07 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 16:28:07 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.172142.1234479047401597555.levitte@openssl.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
 <1479830167.8937.43.camel@infradead.org>
 <20161122.172142.1234479047401597555.levitte@openssl.org>
Message-ID: <1479832087.8937.49.camel@infradead.org>

On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> 
> dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is
> dwmw2> redundant anyway.
> 
> Oh!? Ok, that makes things much simpler (at least in a way)

Kind of. But then again, there's an argument that it was none of your
business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to the
TPM engine and after that you really don't care about what's in it.

Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
files (no ASN.1 at all). For some reason it didn't use the TssBlob
object type, although perhaps it should.

When I started looking at it, I used the -----BEGIN TSS KEY BLOB-----
for an OCTET STRING containing *just* that the code had previously been
writing into its binary files.

If I'd been aware of the TssBlob definition at that time, I suppose I
would have used it instead of just the OCTET STRING. But I didn't.

If we write an I-D covering the TPM keys, perhaps the PEM contents
should be permitted to be *either* a raw OCTET STRING with the key
blob, OR a TssBlob object. Or maybe we should add a
----BEGIN TSS BLOB----- (without 'KEY' in it) instead?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/6471066a/attachment.bin>

From James.Bottomley at HansenPartnership.com  Tue Nov 22 16:44:08 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 22 Nov 2016 08:44:08 -0800
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479832087.8937.49.camel@infradead.org>
References: <1479815862.8937.22.camel@infradead.org>
 <20161122.163254.492222610589754528.levitte@openssl.org>
 <1479830167.8937.43.camel@infradead.org>
 <20161122.172142.1234479047401597555.levitte@openssl.org>
 <1479832087.8937.49.camel@infradead.org>
Message-ID: <1479833048.2376.21.camel@HansenPartnership.com>

On Tue, 2016-11-22 at 16:28 +0000, David Woodhouse wrote:
> On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
> > 
> > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything
> > else is
> > dwmw2> redundant anyway.
> > 
> > Oh!  Ok, that makes things much simpler (at least in a way)
> 
> Kind of. But then again, there's an argument that it was none of your
> business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to
> the
> TPM engine and after that you really don't care about what's in it.
> 
> Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
> files (no ASN.1 at all). For some reason it didn't use the TssBlob
> object type, although perhaps it should.
> 
> When I started looking at it, I used the -----BEGIN TSS KEY BLOB-----
> for an OCTET STRING containing *just* that the code had previously
> been
> writing into its binary files.
> 
> If I'd been aware of the TssBlob definition at that time, I suppose I
> would have used it instead of just the OCTET STRING. But I didn't.
> 
> If we write an I-D covering the TPM keys, perhaps the PEM contents
> should be permitted to be *either* a raw OCTET STRING with the key
> blob, OR a TssBlob object. Or maybe we should add a
> ----BEGIN TSS BLOB----- (without 'KEY' in it) instead?

Before we rathole on this: if we use the current code to just hand off
to the engine, openssl never needs to know the format of the key files
or even what they mean.  If we hard code recognising TPM keys into
openssl, we are going to have to agree (and stick to) a key format. 
 This is one of the decisions that needs making to transform the RFC
into a real patch.

I will note that gnutls does hard code recognising TPM keys so there's
precedent for doing it that way.  However, I have a marginal preference
for letting the loaded engines do it because that's the way that gives
most flexibility with regard to new engines as they come along.  This
problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2
ones, so they'll likely have a new engine to handle them and a new file
format.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/a3a3955d/attachment.bin>

From levitte at openssl.org  Tue Nov 22 17:06:10 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 18:06:10 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479833048.2376.21.camel@HansenPartnership.com>
References: <20161122.172142.1234479047401597555.levitte@openssl.org>
 <1479832087.8937.49.camel@infradead.org>
 <1479833048.2376.21.camel@HansenPartnership.com>
Message-ID: <20161122.180610.153176201036564955.levitte@openssl.org>

In message <1479833048.2376.21.camel at HansenPartnership.com> on Tue, 22 Nov 2016 08:44:08 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Tue, 2016-11-22 at 16:28 +0000, David Woodhouse wrote:
James.Bottomley> > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote:
James.Bottomley> > > 
James.Bottomley> > > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything
James.Bottomley> > > else is
James.Bottomley> > > dwmw2> redundant anyway.
James.Bottomley> > > 
James.Bottomley> > > Oh!  Ok, that makes things much simpler (at least in a way)
James.Bottomley> > 
James.Bottomley> > Kind of. But then again, there's an argument that it was none of your
James.Bottomley> > business anyway. If it says "BEGIN TSS KEY BLOB" you hand it off to
James.Bottomley> > the
James.Bottomley> > TPM engine and after that you really don't care about what's in it.
James.Bottomley> > 
James.Bottomley> > Once upon a time, the TPM engine wrote those TPM_KEY blobs to binary
James.Bottomley> > files (no ASN.1 at all). For some reason it didn't use the TssBlob
James.Bottomley> > object type, although perhaps it should.
James.Bottomley> > 
James.Bottomley> > When I started looking at it, I used the -----BEGIN TSS KEY BLOB-----
James.Bottomley> > for an OCTET STRING containing *just* that the code had previously
James.Bottomley> > been
James.Bottomley> > writing into its binary files.
James.Bottomley> > 
James.Bottomley> > If I'd been aware of the TssBlob definition at that time, I suppose I
James.Bottomley> > would have used it instead of just the OCTET STRING. But I didn't.
James.Bottomley> > 
James.Bottomley> > If we write an I-D covering the TPM keys, perhaps the PEM contents
James.Bottomley> > should be permitted to be *either* a raw OCTET STRING with the key
James.Bottomley> > blob, OR a TssBlob object. Or maybe we should add a
James.Bottomley> > ----BEGIN TSS BLOB----- (without 'KEY' in it) instead?
James.Bottomley> 
James.Bottomley> Before we rathole on this: if we use the current code to just hand off
James.Bottomley> to the engine, openssl never needs to know the format of the key files
James.Bottomley> or even what they mean.  If we hard code recognising TPM keys into
James.Bottomley> openssl, we are going to have to agree (and stick to) a key format. 
James.Bottomley>  This is one of the decisions that needs making to transform the RFC
James.Bottomley> into a real patch.
James.Bottomley> 
James.Bottomley> I will note that gnutls does hard code recognising TPM keys so there's
James.Bottomley> precedent for doing it that way.  However, I have a marginal preference
James.Bottomley> for letting the loaded engines do it because that's the way that gives
James.Bottomley> most flexibility with regard to new engines as they come along.  This
James.Bottomley> problem isn't theoretical: TPM 2.0 keys are very different from TPM 1.2
James.Bottomley> ones, so they'll likely have a new engine to handle them and a new file
James.Bottomley> format.

Actually, I agree with this, and that goes along with how our PEM
routines work (specifically, PEM_X509_INFO_read_bio()), it just
treats the data as an octet string and hands it down to a d2i routine
of choice, with a pointer to where to place the result.

It's not very hard to imagine adding the possibility for external
handlers for specific PEM content types, which could be handed an
octet string and a pointer to a X509_INFO (which is the structure used
to collect the data in), or something like that (I can also imagine
having one separate handler for each type of data that can be
returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
and so on and so forth).  That would make it possible for an engine to
declare its own handler during the binding call, along with all other
information it feeds back to libcrypto.

Cheers,
Richard

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

From rsalz at akamai.com  Tue Nov 22 17:40:54 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Nov 2016 17:40:54 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.161415.1555282309472446656.levitte@openssl.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
Message-ID: <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>

> The more interesting part is when it tries to load files it guesses are raw DER.

And this part worries me.  I do not think a "security library" should be guessing.


From levitte at openssl.org  Tue Nov 22 17:46:39 2016
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 22 Nov 2016 18:46:39 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161122.184639.797476776722171891.levitte@openssl.org>

In message <489af892b16b43ee9a7009ffe52db794 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 17:40:54 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> > The more interesting part is when it tries to load files it guesses are raw DER.
rsalz> 
rsalz> And this part worries me.  I do not think a "security library" should be guessing.

It does this by trying to interpret the blob against known ASN.1
definitions, and will only succeed when there's a complete match.  I'm
not terribly worried...

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

From doctor at doctor.nl2k.ab.ca  Tue Nov 22 14:38:11 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Tue, 22 Nov 2016 07:38:11 -0700
Subject: [openssl-dev] Openssl 1.0.2 Daily Snapshot issue
Message-ID: <20161122143811.GA60056@doctor.nl2k.ab.ca>

In the test cycle I got


Script started on Tue Nov 22 00:50:25 2016
You have mail.
root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20161122 # make test

testing...
making all in apps...
../util/shlib_wrap.sh ./destest
Doing cbcm
Doing ecb
Doing ede ecb
Doing cbc
Doing desx cbc
Doing ede cbc
Doing pcbc
Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done
Doing ofb
Doing ofb64
Doing ede_ofb64
Doing cbc_cksum
Doing quad_cksum
input word alignment test 0 1 2 3
output word alignment test 0 1 2 3
fast crypt test 
../util/shlib_wrap.sh ./ideatest
ecb idea ok
cbc idea ok
cfb64 idea ok
../util/shlib_wrap.sh ./shatest
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha1test
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha256t
Testing SHA-256 ... passed.
Testing SHA-224 ... passed.
../util/shlib_wrap.sh ./sha512t
Testing SHA-512 ... passed.
Testing SHA-384 ... passed.
../util/shlib_wrap.sh ./md4test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./md5test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./hmactest
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
../util/shlib_wrap.sh ./md2test
No MD2 support
../util/shlib_wrap.sh ./mdc2test
pad1 - ok
pad2 - ok
../util/shlib_wrap.sh ./wp_test
Testing Whirlpool ......... passed.
../util/shlib_wrap.sh ./rmdtest
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
test 8 ok
../util/shlib_wrap.sh ./rc2test
ecb RC2 ok
../util/shlib_wrap.sh ./rc4test
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test end processing ....................done
test multi-call ....................done
bulk test ok
../util/shlib_wrap.sh ./rc5test
No RC5 support
../util/shlib_wrap.sh ./bftest
testing blowfish in raw ecb mode
testing blowfish in ecb mode
testing blowfish set_key
testing blowfish in cbc mode
testing blowfish in cfb64 mode
testing blowfish in ofb64
../util/shlib_wrap.sh ./casttest
ecb cast5 ok
This test will take some time....123456789ABCDEF ok
../util/shlib_wrap.sh ./randtest
test 1 done
test 2 done
test 3 done
test 4 done
starting big number library test, could take a while...
test BN_add
test BN_sub
test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
test BN_sqr
test BN_mul
test BN_div
test BN_div_word
test BN_div_recp
test BN_mod
test BN_mod_mul
test BN_mont
test BN_mod_exp
test BN_mod_exp_mont_consttime
test BN_exp
test BN_kronecker
..................++++++
....................................................................................................
test BN_mod_sqrt
.....
.....
.....
.....
.....
.....
.....
.....
..++++++++++++
.....
...........++++++++++++
.....
.++++++++++++
.....
.........++++++++++++
.....
.......++++++++++++
.....
..++++++++++++
.....
...........................++++++++++++
.....
...............................++++++++++++
.....
test BN_GF2m_add
test BN_GF2m_mod
test BN_GF2m_mod_mul
test BN_GF2m_mod_sqr
test BN_GF2m_mod_inv
test BN_GF2m_mod_div
test BN_GF2m_mod_exp
test BN_GF2m_mod_sqrt
test BN_GF2m_mod_solve_quad
running bc

verify BN_add....................................................................................................
verify BN_sub......................................................................................................................................................
verify BN_lshift1....................................................................................................
verify BN_lshift (fixed)....................................................................................................
verify BN_lshift....................................................................................................
verify BN_rshift1....................................................................................................
verify BN_rshift....................................................................................................
verify BN_sqr......................................................................................................
verify BN_mul......................................................................................................................................................
verify BN_div............................................................................................................................................................................................................................................................................................................
verify BN_div_word........................................................................................................................................................................................................
verify BN_div_recp............................................................................................................................................................................................................................................................................................................
verify BN_mod....................................................................................................
verify BN_mod_mul............................................................................................................................................................................................................................................................................................................
verify BN_mont.....
verify BN_mod_exp.....
verify BN_mod_exp_mont_consttime.....
verify BN_exp.....
verify BN_kronecker
verify BN_mod_sqrt
verify BN_GF2m_add
verify BN_GF2m_mod
verify BN_GF2m_mod_mul
verify BN_GF2m_mod_sqr
verify BN_GF2m_mod_inv
verify BN_GF2m_mod_div
verify BN_GF2m_mod_exp
verify BN_GF2m_mod_sqrt
verify BN_GF2m_mod_solve_quad
2222 tests passed
test a^b%c implementations
../util/shlib_wrap.sh ./exptest
........................................................................................................................................................................................................
done
test elliptic curves
../util/shlib_wrap.sh ./ectest
Curve defined by Weierstrass equation
     y^2 = x^3 + a*x + b  (mod 0x17)
     a = 0x1
     b = 0x1
A cyclic subgroup:
     point at infinity
     x = 0xD, y = 0x7
     x = 0x5, y = 0x4
     x = 0x11, y = 0x3
     x = 0x11, y = 0x14
     x = 0x5, y = 0x13
     x = 0xD, y = 0x10
Generator as octet string, compressed form:
     030D
Generator as octet string, uncompressed form:
     040D07
Generator as octet string, hybrid form:
     070D07
A representation of the inverse of that generator in
Jacobian projective coordinates:
     X = 0xC, Y = 0xF, Z = 0xA

SEC2 curve secp160r1 -- Generator:
     x = 0x4A96B5688EF573284664698968C38BB913CBFC82
     y = 0x23A628553168947D59DCC912042351377AC5FB32
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-192 -- Generator:
     x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012
     y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-224 -- Generator:
     x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21
     y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-256 -- Generator:
     x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
     y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-384 -- Generator:
     x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7
     y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-521 -- Generator:
     x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
     y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok
combined multiplication ..... ok


Curve defined by Weierstrass equation
     y^2 + x*y = x^3 + a*x^2 + b  (mod 0x13)
     a = 0x3
     b = 0x1
(0x... means binary polynomial)
A cyclic subgroup:
     point at infinity
     x = 0x6, y = 0x8
     x = 0x1, y = 0xD
     x = 0x7, y = 0x2
     x = 0x0, y = 0x1
     x = 0x7, y = 0x5
     x = 0x1, y = 0xC
     x = 0x6, y = 0xE

Generator as octet string, uncompressed form:
     040608

NIST curve K-163 -- Generator:
     x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8
     y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-163 -- Generator:
     x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36
     y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-233 -- Generator:
     x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126
     y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-233 -- Generator:
     x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B
     y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-283 -- Generator:
     x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836
     y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-283 -- Generator:
     x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053
     y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-409 -- Generator:
     x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746
     y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-409 -- Generator:
     x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7
     y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-571 -- Generator:
     x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972
     y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-571 -- Generator:
     x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19
     y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok
combined multiplication ..... ok

testing internal curves: ................................................................................. ok

test ecdsa
../util/shlib_wrap.sh ./ecdsatest
some tests from X9.62:
testing prime192v1: .... ok
testing prime239v1: .... ok
testing c2tnb191v1: .... ok
testing c2tnb239v1: .... ok

testing ECDSA_sign() and ECDSA_verify() with some internal curves:
secp160k1: ........ ok
secp160r1: ........ ok
secp160r2: ........ ok
secp192k1: ........ ok
secp224k1: ........ ok
secp224r1: ........ ok
secp256k1: ........ ok
secp384r1: ........ ok
secp521r1: ........ ok
prime192v1: ........ ok
prime192v2: ........ ok
prime192v3: ........ ok
prime239v1: ........ ok
prime239v2: ........ ok
prime239v3: ........ ok
prime256v1: ........ ok
sect163k1: ........ ok
sect163r1: ........ ok
sect163r2: ........ ok
sect193r1: ........ ok
sect193r2: ........ ok
sect233k1: ........ ok
sect233r1: ........ ok
sect239k1: ........ ok
sect283k1: ........ ok
sect283r1: ........ ok
sect409k1: ........ ok
sect409r1: ........ ok
sect571k1: ........ ok
sect571r1: ........ ok
c2pnb163v1: ........ ok
c2pnb163v2: ........ ok
c2pnb163v3: ........ ok
c2pnb176v1: ........ ok
c2tnb191v1: ........ ok
c2tnb191v2: ........ ok
c2tnb191v3: ........ ok
c2pnb208w1: ........ ok
c2tnb239v1: ........ ok
c2tnb239v2: ........ ok
c2tnb239v3: ........ ok
c2pnb272w1: ........ ok
c2pnb304w1: ........ ok
c2tnb359v1: ........ ok
c2pnb368w1: ........ ok
c2tnb431r1: ........ ok
wap-wsg-idm-ecid-wtls3: ........ ok
wap-wsg-idm-ecid-wtls5: ........ ok
wap-wsg-idm-ecid-wtls7: ........ ok
wap-wsg-idm-ecid-wtls9: ........ ok
wap-wsg-idm-ecid-wtls10: ........ ok
wap-wsg-idm-ecid-wtls11: ........ ok
wap-wsg-idm-ecid-wtls12: ........ ok
brainpoolP160r1: ........ ok
brainpoolP160t1: ........ ok
brainpoolP192r1: ........ ok
brainpoolP192t1: ........ ok
brainpoolP224r1: ........ ok
brainpoolP224t1: ........ ok
brainpoolP256r1: ........ ok
brainpoolP256t1: ........ ok
brainpoolP320r1: ........ ok
brainpoolP320t1: ........ ok
brainpoolP384r1: ........ ok
brainpoolP384t1: ........ ok
brainpoolP512r1: ........ ok
brainpoolP512t1: ........ ok

ECDSA test passed
test ecdh
../util/shlib_wrap.sh ./ecdhtest
Testing key generation with NIST Prime-Curve P-192 .... ok
Testing key generation with NIST Prime-Curve P-224 .... ok
Testing key generation with NIST Prime-Curve P-256 .... ok
Testing key generation with NIST Prime-Curve P-384 .... ok
Testing key generation with NIST Prime-Curve P-521 .... ok
Testing key generation with NIST Binary-Curve K-163 .... ok
Testing key generation with NIST Binary-Curve B-163 .... ok
Testing key generation with NIST Binary-Curve K-233 .... ok
Testing key generation with NIST Binary-Curve B-233 .... ok
Testing key generation with NIST Binary-Curve K-283 .... ok
Testing key generation with NIST Binary-Curve B-283 .... ok
Testing key generation with NIST Binary-Curve K-409 .... ok
Testing key generation with NIST Binary-Curve B-409 .... ok
Testing key generation with NIST Binary-Curve K-571 .... ok
Testing key generation with NIST Binary-Curve B-571 .... ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok
cat
base64
aes-128-cbc
aes-128-cbc base64
aes-128-ecb
aes-128-ecb base64
aes-192-cbc
aes-192-cbc base64
aes-192-ecb
aes-192-ecb base64
aes-256-cbc
aes-256-cbc base64
aes-256-ecb
aes-256-ecb base64
base64
base64 base64
bf
bf base64
bf-cbc
bf-cbc base64
bf-cfb
bf-cfb base64
bf-ecb
bf-ecb base64
bf-ofb
bf-ofb base64
camellia-128-cbc
camellia-128-cbc base64
camellia-128-ecb
camellia-128-ecb base64
camellia-192-cbc
camellia-192-cbc base64
camellia-192-ecb
camellia-192-ecb base64
camellia-256-cbc
camellia-256-cbc base64
camellia-256-ecb
camellia-256-ecb base64
cast
cast base64
cast-cbc
cast-cbc base64
cast5-cbc
cast5-cbc base64
cast5-cfb
cast5-cfb base64
cast5-ecb
cast5-ecb base64
cast5-ofb
cast5-ofb base64
des
des base64
des-cbc
des-cbc base64
des-cfb
des-cfb base64
des-ecb
des-ecb base64
des-ede
des-ede base64
des-ede-cbc
des-ede-cbc base64
des-ede-cfb
des-ede-cfb base64
des-ede-ofb
des-ede-ofb base64
des-ede3
des-ede3 base64
des-ede3-cbc
des-ede3-cbc base64
des-ede3-cfb
des-ede3-cfb base64
des-ede3-ofb
des-ede3-ofb base64
des-ofb
des-ofb base64
des3
des3 base64
desx
desx base64
idea
idea base64
idea-cbc
idea-cbc base64
idea-cfb
idea-cfb base64
idea-ecb
idea-ecb base64
idea-ofb
idea-ofb base64
rc2
rc2 base64
rc2-40-cbc
rc2-40-cbc base64
rc2-64-cbc
rc2-64-cbc base64
rc2-cbc
rc2-cbc base64
rc2-cfb
rc2-cfb base64
rc2-ecb
rc2-ecb base64
rc2-ofb
rc2-ofb base64
rc4
rc4 base64
rc4-40
rc4-40 base64
seed
seed base64
seed-cbc
seed-cbc base64
seed-cfb
seed-cfb base64
seed-ecb
seed-ecb base64
seed-ofb
seed-ofb base64
zlib
zlib base64
echo test normal x509v1 certificate
test normal x509v1 certificate
sh ./tx509 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
Parsing test certificates
OK
echo test first x509v3 certificate
test first x509v3 certificate
sh ./tx509 v3-cert1.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
Parsing test certificates
OK
echo test second x509v3 certificate
test second x509v3 certificate
sh ./tx509 v3-cert2.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
Parsing test certificates
OK
rsa
testing rsa conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
../util/shlib_wrap.sh ./rsa_test
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
testing crl conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing session-id conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
Generate and verify a certificate request
generating certificate request
rsa
There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
Generating a 1024 bit RSA private key
........................++++++
.......++++++
writing new private key to 'testkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Queensland]:
Locality Name (eg, city) []:Brisbane
Organization Name (eg, company) []:CryptSoft Pty Ltd
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Eric Young
Email Address []:eay at mincom.oz.au
verify OK
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions (2)
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 1 depth lookup:certificate has expired
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test CA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
error 10 at 1 depth lookup:certificate has expired
C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = CA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
Generate a set of DH parameters
../util/shlib_wrap.sh ./dhtest
..+....++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*++*

p    =91B75B70B621D86F
g    =5
pri 1=5A9184375C1B91E7
pub 1=7AC61EE9B09422D
pri 2=72B904F12D3A5FFE
pub 2=57DF9E63AB054996
key1 =4DDC66826D6317F3
key2 =4DDC66826D6317F3
RFC5114 parameter test 1 OK
RFC5114 parameter test 2 OK
RFC5114 parameter test 3 OK
RFC5114 parameter test 4 OK
Generate a set of DSA parameters
../util/shlib_wrap.sh ./dsatest
test generation of DSA parameters
.++++++++++++++++++++++++++++++++++++++++++++++++++*
...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++*
seed
D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3 
counter=105 h=2
P:   
    00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
    69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
    78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
    32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
    ee:31:c8:02:91
Q:   
    00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
    f4:8e:da:ce:91:5f
G:   
    62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
    00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
    2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
    92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
    e6:d7:88:02
../util/shlib_wrap.sh ./dsatest -app2_1
test generation of DSA parameters
.++++++++++++++++++++++++++++++++++++++++++++++++++*
...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++*
seed
D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3 
counter=105 h=2
P:   
    00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
    69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
    78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
    32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
    ee:31:c8:02:91
Q:   
    00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
    f4:8e:da:ce:91:5f
G:   
    62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
    00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
    2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
    92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
    e6:d7:88:02
Generate and certify a test certificate

make a certificate request using 'req'
rsa
Generating a 2048 bit RSA private key
.+++
..................+++
writing new private key to 'keyCA.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Dodgy CA

convert the certificate request into a self signed certificate using 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Dodgy CA
Getting Private key

convert a certificate into a certificate request using 'x509'
Getting request Private Key
Generating certificate request
verify OK
verify OK
certCA.ss: OK

make a user certificate request using 'req'
Generating a 2048 bit RSA private key
............+++
................................................+++
writing new private key to 'keyU.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2

sign user certificate request with the just created CA via 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
Getting CA Private Key
certU.ss: OK

Certificate details
subject= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
issuer= /C=AU/O=Dodgy Brothers/CN=Dodgy CA
notBefore=Nov 22 07:50:52 2016 GMT
notAfter=Dec 22 07:50:52 2016 GMT

make a proxy certificate request using 'req'
Generating a 1024 bit RSA private key
......++++++
........++++++
writing new private key to 'keyP1.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2
Common Name (eg, YOUR name) []:Proxy 1

sign proxy certificate request with the just created user certificate via 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
Getting CA Private Key
certP1.ss: C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1
error 40 at 0 depth lookup:proxy certificates not allowed, please set the appropriate flag

Certificate details
subject= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
issuer= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
notBefore=Nov 22 07:50:52 2016 GMT
notAfter=Dec 22 07:50:52 2016 GMT

make another proxy certificate request using 'req'
Generating a 1024 bit RSA private key
......................++++++
....................................................................++++++
writing new private key to 'keyP2.ss'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2
Common Name (eg, YOUR name) []:Proxy 1
Common Name (eg, YOUR name) []:Proxy 2

sign second proxy certificate request with the first proxy certificate via 'x509'
Signature ok
subject=/C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
Getting CA Private Key
certP2.ss: C = AU, O = Dodgy Brothers, CN = Brother 1, CN = Brother 2, CN = Proxy 1, CN = Proxy 2
error 40 at 0 depth lookup:proxy certificates not allowed, please set the appropriate flag

Certificate details
subject= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
issuer= /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
notBefore=Nov 22 07:50:52 2016 GMT
notAfter=Dec 22 07:50:52 2016 GMT

The generated CA certificate is certCA.ss
The generated CA private key is keyCA.ss
The generated user certificate is certU.ss
The generated user private key is keyU.ss
The first generated proxy certificate is certP1.ss
The first generated proxy private key is keyP1.ss
The second generated proxy certificate is certP2.ss
The second generated proxy private key is keyP2.ss
rsa
Generate and certify a test certificate via the 'ca' program
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 2048 bit RSA private key
.......................+++
......................................+++
writing new private key to './demoCA/private/./cakey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Dodgy CA
Using configuration from CAss.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            81:91:1e:7a:f7:f2:5d:30
        Validity
            Not Before: Nov 22 07:50:52 2016 GMT
            Not After : Nov 22 07:50:52 2019 GMT
        Subject:
            countryName               = AU
            organizationName          = Dodgy Brothers
            commonName                = Dodgy CA
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                CE:57:2B:C4:C1:F5:32:BC:C2:AB:E5:01:B8:5E:F3:F9:BB:26:9C:44
            X509v3 Authority Key Identifier: 
                keyid:CE:57:2B:C4:C1:F5:32:BC:C2:AB:E5:01:B8:5E:F3:F9:BB:26:9C:44
                DirName:/C=AU/O=Dodgy Brothers/CN=Dodgy CA
                serial:81:91:1E:7A:F7:F2:5D:30

            X509v3 Basic Constraints: 
                CA:TRUE, pathlen:1
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
            X509v3 Issuer Alternative Name: 
                <EMPTY>

Certificate is to be certified until Nov 22 07:50:52 2019 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated
Generating a 2048 bit RSA private key
..................................+++
......................................................................................+++
writing new private key to 'newkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
Organization Name (eg, company) []:Dodgy Brothers
Common Name (eg, YOUR name) []:Brother 1
Common Name (eg, YOUR name) []:Brother 2
Request is in newreq.pem, private key is in newkey.pem
Using configuration from ../apps/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            81:91:1e:7a:f7:f2:5d:31
        Validity
            Not Before: Nov 22 07:50:53 2016 GMT
            Not After : Nov 22 07:50:53 2017 GMT
        Subject:
            countryName               = AU
            organizationName          = Dodgy Brothers
            commonName                = Brother 1
            commonName                = Brother 2
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                5A:0E:32:B5:D3:52:F4:01:FE:6B:7A:D0:1F:17:F0:84:01:40:BB:67
            X509v3 Authority Key Identifier: 
                keyid:CE:57:2B:C4:C1:F5:32:BC:C2:AB:E5:01:B8:5E:F3:F9:BB:26:9C:44

Certificate is to be certified until Nov 22 07:50:53 2017 GMT (365 days)
Sign the certificate? [y/n]:

1 out of 1 certificate requests certified, commit? [y/n]Write out database with 1 new entries
Data Base Updated
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            81:91:1e:7a:f7:f2:5d:31
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=AU, O=Dodgy Brothers, CN=Dodgy CA
        Validity
            Not Before: Nov 22 07:50:53 2016 GMT
            Not After : Nov 22 07:50:53 2017 GMT
        Subject: C=AU, O=Dodgy Brothers, CN=Brother 1, CN=Brother 2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e3:57:75:e0:8f:30:8f:33:d0:94:f0:6e:43:45:
                    d0:38:a1:be:1c:e7:88:28:d0:d5:39:0c:17:1e:9a:
                    c5:1e:46:4e:2e:c0:33:4d:89:a3:39:f6:b2:4e:cd:
                    35:a2:ac:6c:e0:00:33:99:2f:3a:45:b4:5d:fe:ac:
                    52:25:9d:55:8b:c8:0d:8f:a9:06:16:3e:24:7d:70:
                    b8:0c:23:ad:b0:72:8c:99:10:e5:b1:b5:1a:5f:e6:
                    0f:5b:8b:aa:94:79:55:0f:ef:8a:aa:26:81:e7:0b:
                    d8:b2:f0:60:42:12:81:74:31:03:f6:b4:c9:16:0a:
                    5d:4c:49:61:13:0c:b5:21:94:46:a2:d7:54:29:cb:
                    7f:cb:f4:98:11:2e:18:76:69:1d:7b:0d:28:03:e9:
                    d7:dd:3b:59:48:97:68:b2:0f:99:74:5e:8e:c4:8b:
                    6a:ee:01:eb:0c:22:0d:39:69:6c:a7:8b:fd:7c:6c:
                    d1:df:f2:71:10:e0:4c:bc:ba:fd:30:98:c3:cf:73:
                    4f:63:5e:b5:f9:64:67:01:d0:37:fa:b2:f0:e2:fa:
                    28:4c:b5:6d:8a:35:d6:27:72:42:60:b2:cf:44:2a:
                    4d:ea:3d:97:af:44:7d:1f:01:99:46:f1:3d:4b:95:
                    4e:88:d7:09:db:bb:cc:81:7f:51:0f:33:f3:c8:d7:
                    de:e1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                5A:0E:32:B5:D3:52:F4:01:FE:6B:7A:D0:1F:17:F0:84:01:40:BB:67
            X509v3 Authority Key Identifier: 
                keyid:CE:57:2B:C4:C1:F5:32:BC:C2:AB:E5:01:B8:5E:F3:F9:BB:26:9C:44

    Signature Algorithm: sha256WithRSAEncryption
         cc:a5:a5:ff:45:30:8d:4f:ed:a8:0c:af:76:e9:c5:11:fc:f6:
         40:f1:aa:af:19:bd:05:f2:12:97:86:90:09:9d:66:8e:11:76:
         2e:71:51:29:3e:0b:8c:06:fc:7b:26:58:ad:7e:bc:53:fa:40:
         ec:8b:4c:50:7a:ba:2c:02:14:c7:86:41:c6:1e:bb:09:e3:fa:
         e2:7d:ec:27:0f:0d:07:b1:f6:14:75:de:e0:c2:28:c1:73:3d:
         cf:05:08:d7:ab:29:fb:b5:a6:26:02:94:6a:4a:81:82:17:e4:
         53:fe:90:dd:3b:72:cd:d1:04:86:b4:ef:51:93:91:ac:b8:1c:
         b6:6a:ff:31:af:3b:5f:02:e0:9d:f9:50:51:e9:17:ff:7a:10:
         5d:bd:88:8a:42:40:71:04:87:7e:07:fb:9d:82:9d:55:0e:5f:
         88:ea:02:74:a9:1e:ac:0f:99:b5:66:f4:4c:b7:75:4c:05:98:
         06:b9:6e:cf:b9:8f:52:c0:25:f6:25:6e:b4:93:ee:9a:da:7a:
         8d:7a:37:8a:ee:10:a3:13:9d:b4:44:3e:d3:43:4e:97:91:ed:
         73:46:2f:ed:73:ee:35:32:17:00:78:fc:6b:25:64:84:b9:32:
         82:96:38:4b:04:c4:ed:60:2a:26:b5:26:d1:63:8e:c5:99:55:
         b3:9a:0a:29
-----BEGIN CERTIFICATE-----
MIIDhTCCAm2gAwIBAgIJAIGRHnr38l0xMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkFVMRcwFQYDVQQKDA5Eb2RneSBCcm90aGVyczERMA8GA1UEAwwIRG9kZ3kg
Q0EwHhcNMTYxMTIyMDc1MDUzWhcNMTcxMTIyMDc1MDUzWjBOMQswCQYDVQQGEwJB
VTEXMBUGA1UECgwORG9kZ3kgQnJvdGhlcnMxEjAQBgNVBAMMCUJyb3RoZXIgMTES
MBAGA1UEAwwJQnJvdGhlciAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA41d14I8wjzPQlPBuQ0XQOKG+HOeIKNDVOQwXHprFHkZOLsAzTYmjOfayTs01
oqxs4AAzmS86RbRd/qxSJZ1Vi8gNj6kGFj4kfXC4DCOtsHKMmRDlsbUaX+YPW4uq
lHlVD++KqiaB5wvYsvBgQhKBdDED9rTJFgpdTElhEwy1IZRGotdUKct/y/SYES4Y
dmkdew0oA+nX3TtZSJdosg+ZdF6OxItq7gHrDCINOWlsp4v9fGzR3/JxEOBMvLr9
MJjDz3NPY161+WRnAdA3+rLw4vooTLVtijXWJ3JCYLLPRCpN6j2Xr0R9HwGZRvE9
S5VOiNcJ27vMgX9RDzPzyNfe4QIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG
+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU
Wg4ytdNS9AH+a3rQHxfwhAFAu2cwHwYDVR0jBBgwFoAUzlcrxMH1MrzCq+UBuF7z
+bsmnEQwDQYJKoZIhvcNAQELBQADggEBAMylpf9FMI1P7agMr3bpxRH89kDxqq8Z
vQXyEpeGkAmdZo4Rdi5xUSk+C4wG/HsmWK1+vFP6QOyLTFB6uiwCFMeGQcYeuwnj
+uJ97CcPDQex9hR13uDCKMFzPc8FCNerKfu1piYClGpKgYIX5FP+kN07cs3RBIa0
71GTkay4HLZq/zGvO18C4J35UFHpF/96EF29iIpCQHEEh34H+52CnVUOX4jqAnSp
HqwPmbVm9Ey3dUwFmAa5bs+5j1LAJfYlbrST7praeo16N4ruEKMTnbREPtNDTpeR
7XNGL+1z7jUyFwB4/GslZIS5MoKWOEsExO1gKia1JtFjjsWZVbOaCik=
-----END CERTIFICATE-----
Signed certificate is in newcert.pem
newcert.pem: OK
Manipulate the ENGINE structures
../util/shlib_wrap.sh ./enginetest

enginetest beginning

listing available engine types
end of list
listing available engine types
engine 0, id = "test_id0", name = "First test item"
end of list
listing available engine types
end of list
listing available engine types
engine 0, id = "test_id2", name = "Third test item"
engine 1, id = "test_id1", name = "Second test item"
end of list
listing available engine types
engine 0, id = "test_id2", name = "Third test item"
end of list
listing available engine types
engine 0, id = "test_id2", name = "Third test item"
engine 1, id = "test_id3", name = "Fourth test item"
end of list
Add that should fail did.
Remove that should fail did.
listing available engine types
engine 0, id = "test_id3", name = "Fourth test item"
end of list
listing available engine types
end of list
listing available engine types
end of list
Successfully added and removed to an empty list!
About to beef up the engine-type list
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
About to empty the engine-type list
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Tests completed happily
../util/shlib_wrap.sh ./evp_test evptests.txt
Testing digest SHA1
Plaintext
0000 61 62 63
Digest
0000 a9 99 3e 36 47 06 81 6a ba 3e 25 71 78 50 c2 6c
0010 9c d0 d8 9d

Testing digest MD5
Plaintext
Digest
0000 d4 1d 8c d9 8f 00 b2 04 e9 80 09 98 ec f8 42 7e

Testing digest MD5
Plaintext
0000 61
Digest
0000 0c c1 75 b9 c0 f1 b6 a8 31 c3 99 e2 69 77 26 61

Testing digest MD5
Plaintext
0000 61 62 63
Digest
0000 90 01 50 98 3c d2 4f b0 d6 96 3f 7d 28 e1 7f 72

Testing digest MD5
Plaintext
0000 6d 65 73 73 61 67 65 20 64 69 67 65 73 74
Digest
0000 f9 6b 69 7d 7c b7 93 8d 52 5a 2f 31 aa f1 61 d0

Testing digest MD5
Plaintext
0000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
0010 71 72 73 74 75 76 77 78 79 7a
Digest
0000 c3 fc d3 d7 61 92 e4 00 7d fb 49 6c ca 67 e1 3b

Testing digest MD5
Plaintext
0000 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50
0010 51 52 53 54 55 56 57 58 59 5a 61 62 63 64 65 66
0020 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
0030 77 78 79 7a 30 31 32 33 34 35 36 37 38 39
Digest
0000 d1 74 ab 98 d2 77 d9 f5 a5 61 1c 2c 9f 41 9d 9f

Testing digest MD5
Plaintext
0000 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36
0010 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32
0020 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38
0030 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34
0040 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30
Digest
0000 57 ed f4 a2 2b e3 c9 55 ac 49 da 2e 21 07 b6 7a

Testing cipher AES-128-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a

Testing cipher AES-192-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 dd a9 7c a4 86 4c df e0 6e af 70 a0 ec 0d 71 91

Testing cipher AES-256-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 8e a2 b7 ca 51 67 45 bf ea fc 49 90 4b 49 60 89

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3a d7 7b b4 0d 7a 36 60 a8 9e ca f3 24 66 ef 97

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 f5 d3 d5 85 03 b9 69 9d e7 85 89 5a 96 fd ba af

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 43 b1 cd 7f 59 8e ce 23 88 1b 00 e3 ed 03 06 88

Testing cipher AES-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 7b 0c 78 5e 27 e8 ad 3f 82 23 20 71 04 72 5d d4

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 bd 33 4f 1d 6e 45 f2 5f f7 12 a2 14 57 1f a5 cc

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 97 41 04 84 6d 0a d3 ad 77 34 ec b3 ec ee 4e ef

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 ef 7a fd 22 70 e2 e6 0a dc e0 ba 2f ac e6 44 4e

Testing cipher AES-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 9a 4b 41 ba 73 8d 6c 72 fb 16 69 16 03 c1 8e 0e

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 f3 ee d1 bd b5 d2 a0 3c 06 4b 5a 7e 3d b1 81 f8

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 59 1c cb 10 d4 10 ed 26 dc 5b a7 4a 31 36 28 70

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 b6 ed 21 b9 9c a6 f4 f9 f1 53 e7 b1 be af ed 1d

Testing cipher AES-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 23 30 4b 7a 39 f9 f3 ff 06 7d 8d 8f 9e 24 ec c7

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 76 49 ab ac 81 19 b2 46 ce e9 8e 9b 12 e9 19 7d

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 76 49 ab ac 81 19 b2 46 ce e9 8e 9b 12 e9 19 7d
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 50 86 cb 9b 50 72 19 ee 95 db 11 3a 91 76 78 b2

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 86 cb 9b 50 72 19 ee 95 db 11 3a 91 76 78 b2
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 73 be d6 b8 e3 c1 74 3b 71 16 e6 9e 22 22 95 16

Testing cipher AES-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 73 be d6 b8 e3 c1 74 3b 71 16 e6 9e 22 22 95 16
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 3f f1 ca a1 68 1f ac 09 12 0e ca 30 75 86 e1 a7

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 4f 02 1d b2 43 bc 63 3d 71 78 18 3a 9f a0 71 e8

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 4f 02 1d b2 43 bc 63 3d 71 78 18 3a 9f a0 71 e8
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 b4 d9 ad a9 ad 7d ed f4 e5 e7 38 76 3f 69 14 5a

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 b4 d9 ad a9 ad 7d ed f4 e5 e7 38 76 3f 69 14 5a
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 57 1b 24 20 12 fb 7a e0 7f a9 ba ac 3d f1 02 e0

Testing cipher AES-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 57 1b 24 20 12 fb 7a e0 7f a9 ba ac 3d f1 02 e0
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 08 b0 e2 79 88 59 88 81 d9 20 a9 e6 4f 56 15 cd

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 f5 8c 4c 04 d6 e5 f1 ba 77 9e ab fb 5f 7b fb d6

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 f5 8c 4c 04 d6 e5 f1 ba 77 9e ab fb 5f 7b fb d6
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 9c fc 4e 96 7e db 80 8d 67 9f 77 7b c6 70 2c 7d

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 9c fc 4e 96 7e db 80 8d 67 9f 77 7b c6 70 2c 7d
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 39 f2 33 69 a9 d9 ba cf a5 30 e2 63 04 23 14 61

Testing cipher AES-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 39 f2 33 69 a9 d9 ba cf a5 30 e2 63 04 23 14 61
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 b2 eb 05 e2 c3 9b e9 fc da 6c 19 07 8c 6a 9d 1b

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df

Testing cipher AES-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 4b 05 35 7c 5d 1c 0e ea c4 c6 6f 9f f7 f2 e6

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 c8 a6 45 37 a0 b3 a9 3f cd e3 cd ad 9f 1c e5 8b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df

Testing cipher AES-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 26 75 1f 67 a3 cb b1 40 b1 80 8c f1 87 a4 f4 df
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 4b 05 35 7c 5d 1c 0e ea c4 c6 6f 9f f7 f2 e6

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9

Testing cipher AES-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 5f 9f 9c a9 83 4f a0 42 ae 8f ba 58 4b 09 ff

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 67 ce 7f 7f 81 17 36 21 96 1a 2b 70 17 1d 3d 7a
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9

Testing cipher AES-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 2e 1e 8a 1d d5 9b 88 b1 c8 e6 0f ed 1e fa c4 c9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 c0 5f 9f 9c a9 83 4f a0 42 ae 8f ba 58 4b 09 ff

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9

Testing cipher AES-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 75 a3 85 74 1a b9 ce f8 20 31 62 3d 55 b1 e4 71

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 39 ff ed 14 3b 28 b1 c8 32 11 3c 63 31 e5 40 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9

Testing cipher AES-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 df 10 13 24 15 e5 4b 92 a1 3e d0 a8 26 7a e2 f9
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 75 a3 85 74 1a b9 ce f8 20 31 62 3d 55 b1 e4 71

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 77 89 50 8d 16 91 8f 03 f5 3c 52 da c5 4e d8 25

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 97 40 05 1e 9c 5f ec f6 43 44 f7 a8 22 60 ed cc

Testing cipher AES-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 30 4c 65 28 f6 59 c7 78 66 a5 10 d9 c1 d6 ae 5e

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 3b 3f d9 2e b7 2d ad 20 33 34 49 f8 e8 3c fb 4a

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 77 89 50 8d 16 91 8f 03 f5 3c 52 da c5 4e d8 25

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 97 40 05 1e 9c 5f ec f6 43 44 f7 a8 22 60 ed cc

Testing cipher AES-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 30 4c 65 28 f6 59 c7 78 66 a5 10 d9 c1 d6 ae 5e

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 fc c2 8b 8d 4c 63 83 7c 09 e8 17 00 c1 10 04 01

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 8d 9a 9a ea c0 f6 59 6f 55 9c 6d 4d af 59 a5 f2

Testing cipher AES-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 6d 9f 20 08 57 ca 6c 3e 9c ac 52 4b d9 ac c9 2a

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cd c8 0d 6f dd f1 8c ab 34 c2 59 09 c9 9a 41 74

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 fc c2 8b 8d 4c 63 83 7c 09 e8 17 00 c1 10 04 01

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 8d 9a 9a ea c0 f6 59 6f 55 9c 6d 4d af 59 a5 f2

Testing cipher AES-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 6d 9f 20 08 57 ca 6c 3e 9c ac 52 4b d9 ac c9 2a

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 4f eb dc 67 40 d2 0b 3a c8 8f 6a d8 2a 4f b0 8d

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 71 ab 47 a0 86 e8 6e ed f3 9d 1c 5b ba 97 c4 08

Testing cipher AES-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 01 26 14 1d 67 f3 7b e8 53 8f 5a 8b e7 40 e4 84

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 dc 7e 84 bf da 79 16 4b 7e cd 84 86 98 5d 38 60

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 4f eb dc 67 40 d2 0b 3a c8 8f 6a d8 2a 4f b0 8d

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 71 ab 47 a0 86 e8 6e ed f3 9d 1c 5b ba 97 c4 08

Testing cipher AES-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 01 26 14 1d 67 f3 7b e8 53 8f 5a 8b e7 40 e4 84

Testing cipher AES-128-CTR(encrypt)
Key
0000 ae 68 52 f8 12 10 67 cc 4b f7 a5 76 55 77 f3 9e
IV
0000 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01
Plaintext
0000 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
Ciphertext
0000 e4 09 5d 4f b7 a7 b3 79 2d 61 75 a3 26 13 11 b8

Testing cipher AES-128-CTR(encrypt)
Key
0000 7e 24 06 78 17 fa e0 d7 43 d6 ce 1f 32 53 91 63
IV
0000 00 6c b6 db c0 54 3b 59 da 48 d9 0b 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Ciphertext
0000 51 04 a1 06 16 8a 72 d9 79 0d 41 ee 8e da d3 88
0010 eb 2e 1e fc 46 da 57 c8 fc e6 30 df 91 41 be 28

Testing cipher AES-128-CTR(encrypt)
Key
0000 76 91 be 03 5e 50 20 a8 ac 6e 61 85 29 f9 a0 dc
IV
0000 00 e0 01 7b 27 77 7f 3f 4a 17 86 f0 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23
Ciphertext
0000 c1 cf 48 a8 9f 2f fd d9 cf 46 52 e9 ef db 72 d7
0010 45 40 a4 2b de 6d 78 36 d5 9a 5c ea ae f3 10 53
0020 25 b2 07 2f

Testing cipher AES-192-CTR(encrypt)
Key
0000 16 af 5b 14 5f c9 f5 79 c1 75 f9 3e 3b fb 0e ed
0010 86 3d 06 cc fd b7 85 15
IV
0000 00 00 00 48 36 73 3c 14 7d 6d 93 cb 00 00 00 01
Plaintext
0000 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
Ciphertext
0000 4b 55 38 4f e2 59 c9 c8 4e 79 35 a0 03 cb e9 28

Testing cipher AES-192-CTR(encrypt)
Key
0000 7c 5c b2 40 1b 3d c3 3c 19 e7 34 08 19 e0 f6 9c
0010 67 8c 3d b8 e6 f6 a9 1a
IV
0000 00 96 b0 3b 02 0c 6e ad c2 cb 50 0d 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Ciphertext
0000 45 32 43 fc 60 9b 23 32 7e df aa fa 71 31 cd 9f
0010 84 90 70 1c 5a d4 a7 9c fc 1f e0 ff 42 f4 fb 00

Testing cipher AES-192-CTR(encrypt)
Key
0000 02 bf 39 1e e8 ec b1 59 b9 59 61 7b 09 65 27 9b
0010 f5 9b 60 a7 86 d3 e0 fe
IV
0000 00 07 bd fd 5c bd 60 27 8d cc 09 12 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23
Ciphertext
0000 96 89 3f c5 5e 5c 72 2f 54 0b 7d d1 dd f7 e7 58
0010 d2 88 bc 95 c6 91 65 88 45 36 c8 11 66 2f 21 88
0020 ab ee 09 35

Testing cipher AES-256-CTR(encrypt)
Key
0000 77 6b ef f2 85 1d b0 6f 4c 8a 05 42 c8 69 6f 6c
0010 6a 81 af 1e ec 96 b4 d3 7f c1 d6 89 e6 c1 c1 04
IV
0000 00 00 00 60 db 56 72 c9 7a a8 f0 b2 00 00 00 01
Plaintext
0000 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
Ciphertext
0000 14 5a d0 1d bf 82 4e c7 56 08 63 dc 71 e3 e0 c0

Testing cipher AES-256-CTR(encrypt)
Key
0000 f6 d6 6d 6b d5 2d 59 bb 07 96 36 58 79 ef f8 86
0010 c6 6d d5 1a 5b 6a 99 74 4b 50 59 0c 87 a2 38 84
IV
0000 00 fa ac 24 c1 58 5e f1 5a 43 d8 75 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Ciphertext
0000 f0 5e 23 1b 38 94 61 2c 49 ee 00 0b 80 4e b2 a9
0010 b8 30 6b 50 8f 83 9d 6a 55 30 83 1d 93 44 af 1c

Testing cipher AES-256-CTR(encrypt)
Key
0000 ff 7a 61 7c e6 91 48 e4 f1 72 6e 2f 43 58 1d e2
0010 aa 62 d9 f8 05 53 2e df f1 ee d6 87 fb 54 15 3d
IV
0000 00 1c c5 b7 51 a5 1d 70 a1 c1 11 48 00 00 00 01
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23
Ciphertext
0000 eb 6c 52 82 1d 0b bb f7 ce 75 94 46 2a ca 4f aa
0010 b4 07 df 86 65 69 fd 07 f4 8c c0 b5 83 d6 07 1f
0020 1e c0 e6 b8

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00
Ciphertext
0000 8c a6 4d e9 c1 b1 23 a7

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 ff ff ff ff ff ff ff ff
Plaintext
0000 ff ff ff ff ff ff ff ff
Ciphertext
0000 73 59 b2 16 3e 4e dc 58

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 30 00 00 00 00 00 00 00
Plaintext
0000 10 00 00 00 00 00 00 01
Ciphertext
0000 95 8e 6e 62 7a 05 55 7b

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 11 11 11 11 11 11 11 11
Plaintext
0000 11 11 11 11 11 11 11 11
Ciphertext
0000 f4 03 79 ab 9e 0e c5 33

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef
Plaintext
0000 11 11 11 11 11 11 11 11
Ciphertext
0000 17 66 8d fc 72 92 53 2d

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 11 11 11 11 11 11 11 11
Plaintext
0000 01 23 45 67 89 ab cd ef
Ciphertext
0000 8a 5a e1 f8 1a b8 f2 dd

Testing cipher DES-ECB(encrypt/decrypt)
Key
0000 fe dc ba 98 76 54 32 10
Plaintext
0000 01 23 45 67 89 ab cd ef
Ciphertext
0000 ed 39 d9 50 fa 74 bc c4

Testing cipher DESX-CBC(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef f1 e0 d3 c2 b5 a4 97 86
0010 fe dc ba 98 76 54 32 10
IV
0000 fe dc ba 98 76 54 32 10
Plaintext
0000 37 36 35 34 33 32 31 20 4e 6f 77 20 69 73 20 74
0010 68 65 20 74 69 6d 65 20 66 6f 72 20 00 00 00 00
Ciphertext
0000 84 6b 29 14 85 1e 9a 29 54 73 2f 8a a0 a6 11 c1
0010 15 cd c2 d7 95 1b 10 53 a6 3c 5e 03 b2 1a a3 c4

Testing cipher DES-EDE3-CBC(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef f1 e0 d3 c2 b5 a4 97 86
0010 fe dc ba 98 76 54 32 10
IV
0000 fe dc ba 98 76 54 32 10
Plaintext
0000 37 36 35 34 33 32 31 20 4e 6f 77 20 69 73 20 74
0010 68 65 20 74 69 6d 65 20 66 6f 72 20 00 00 00 00
Ciphertext
0000 3f e3 01 c9 62 ac 01 d0 22 13 76 3c 1c bd 4c dc
0010 79 96 57 c0 64 ec f5 d4 1c 67 38 12 cf de 96 75

Testing cipher RC4(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
Plaintext
0000 01 23 45 67 89 ab cd ef
Ciphertext
0000 75 b7 87 80 99 e0 c5 96

Testing cipher RC4(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
Plaintext
0000 00 00 00 00 00 00 00 00
Ciphertext
0000 74 94 c2 e7 10 4b 08 79

Testing cipher RC4(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00
Ciphertext
0000 de 18 89 41 a3 37 5d 3a

Testing cipher RC4(encrypt/decrypt)
Key
0000 ef 01 23 45 ef 01 23 45 ef 01 23 45 ef 01 23 45
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00
Ciphertext
0000 d6 a1 41 a7 ec 3c 38 df bd 61 5a 11 62 e1 c7 ba
0010 36 b6 78 58

Testing cipher RC4(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
Plaintext
0000 12 34 56 78 9a bc de f0 12 34 56 78 9a bc de f0
0010 12 34 56 78 9a bc de f0 12 34 56 78
Ciphertext
0000 66 a0 94 9f 8a f7 d6 89 1f 7f 83 2b a8 33 c0 0c
0010 89 2e be 30 14 3c e2 87 40 01 1e cf

Testing cipher RC4(encrypt/decrypt)
Key
0000 ef 01 23 45 ef 01 23 45 ef 01 23 45 ef 01 23 45
Plaintext
0000 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 d6 a1 41 a7 ec 3c 38 df bd 61

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Plaintext
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext
0000 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
0010 00 11 22 33 44 55 66 77
Plaintext
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext
0000 b4 99 34 01 b3 e9 96 f8 4e e5 ce e7 d7 9b 09 b9

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
0010 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Plaintext
0000 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10
Ciphertext
0000 9a cc 23 7d ff 16 d7 6c 20 ef 7c 91 9e 3a 75 09

Testing cipher CAMELLIA-128-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 77 cf 41 20 67 af 82 70 61 35 29 14 99 19 54 6f

Testing cipher CAMELLIA-192-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 b2 2f 3c 36 b7 2d 31 32 9e ee 8a dd c2 90 6c 68

Testing cipher CAMELLIA-256-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 2e df 1f 34 18 d5 3b 88 84 1f c8 98 5f b1 ec f2

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 43 2f c5 dc d6 28 11 5b 7c 38 8d 77 0b 27 0c 96

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 0b e1 f1 40 23 78 2a 22 e8 38 4c 5a bb 7f ab 2b

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 a0 a1 ab cd 18 93 ab 6f e0 fe 5b 65 df 5f 86 36

Testing cipher CAMELLIA-128-ECB(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 e6 19 25 e0 d5 df aa 9b b2 9f 81 5b 30 76 e5 1a

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cc cc 6c 4e 13 8b 45 84 85 14 d4 8d 0d 34 39 d3

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 57 13 c6 2c 14 b2 ec 0f 83 93 b6 af d6 f5 78 5a

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 b4 0e d2 b6 0e b5 4d 09 d0 30 cf 51 1f ee f3 66

Testing cipher CAMELLIA-192-ECB(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 90 9d bd 95 79 90 96 74 8c b2 73 57 e7 3e 1d 26

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 be fd 21 9b 11 2f a0 00 98 91 9c d1 01 c9 cc fa

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 c9 1d 3a 8f 1a ea 08 a9 38 6c f4 b6 6c 01 69 ea

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 a6 23 d7 11 dc 5f 25 a5 1b b8 a8 0d 56 39 7d 28

Testing cipher CAMELLIA-256-ECB(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 79 60 10 9f b6 dc 42 94 7f cf e5 9e a3 c5 eb 6b

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 16 07 cf 49 4b 36 bb f0 0d ae b0 b5 03 c8 31 ab

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 16 07 cf 49 4b 36 bb f0 0d ae b0 b5 03 c8 31 ab
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 a2 f2 cf 67 16 29 ef 78 40 c5 a5 df b5 07 48 87

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a2 f2 cf 67 16 29 ef 78 40 c5 a5 df b5 07 48 87
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 0f 06 16 50 08 cf 8b 8b 5a 63 58 63 62 54 3e 54

Testing cipher CAMELLIA-128-CBC(encrypt/decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 36 a8 4c da fd 5f 9a 85 ad a0 f0 a9 93 d6 d5 77
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 74 c6 42 68 cd b8 b8 fa f5 b3 4e 8a f3 73 29 80

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 2a 48 30 ab 5a c4 a1 a2 40 59 55 fd 21 95 cf 93

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 2a 48 30 ab 5a c4 a1 a2 40 59 55 fd 21 95 cf 93
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 5d 5a 86 9b d1 4c e5 42 64 f8 92 a6 dd 2e c3 d5

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 5d 5a 86 9b d1 4c e5 42 64 f8 92 a6 dd 2e c3 d5
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 37 d3 59 c3 34 98 36 d8 84 e3 10 ad df 68 c4 49

Testing cipher CAMELLIA-192-CBC(encrypt/decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 37 d3 59 c3 34 98 36 d8 84 e3 10 ad df 68 c4 49
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 01 fa aa 93 0b 4a b9 91 6e 96 68 e1 42 8c 6b 08

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 e6 cf a3 5f c0 2b 13 4a 4d 2c 0b 67 37 ac 3e da

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e6 cf a3 5f c0 2b 13 4a 4d 2c 0b 67 37 ac 3e da
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 36 cb eb 73 bd 50 4b 40 70 b1 b7 de 2b 21 eb 50

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 36 cb eb 73 bd 50 4b 40 70 b1 b7 de 2b 21 eb 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 e3 1a 60 55 29 7d 96 ca 33 30 cd f1 b1 86 0a 83

Testing cipher CAMELLIA-256-CBC(encrypt/decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e3 1a 60 55 29 7d 96 ca 33 30 cd f1 b1 86 0a 83
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 5d 56 3f 6d 1c cc f2 36 05 1c 0c 5c 1c 58 f2 8f

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96

Testing cipher CAMELLIA-128-CFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 74 2a 25 f0 54 23 40 c7 ba ef 24 ca 84 82 bb 09

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a5 3d 28 bb 82 df 74 11 03 ea 4f 92 1a 44 88 0b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96

Testing cipher CAMELLIA-128-CFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 9c 21 57 a6 64 62 6d 1d ef 9e a4 20 fd e6 9b 96
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 74 2a 25 f0 54 23 40 c7 ba ef 24 ca 84 82 bb 09

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01

Testing cipher CAMELLIA-192-CFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d5 b5 37 8a 3a be d5 58 03 f2 55 65 d8 90 7b 84

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 86 f8 49 16 27 90 6d 78 0c 7a 6d 46 ea 33 1f 98
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01

Testing cipher CAMELLIA-192-CFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 69 51 1c ce 59 4c f7 10 cb 98 bb 63 d7 22 1f 01
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d5 b5 37 8a 3a be d5 58 03 f2 55 65 d8 90 7b 84

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4

Testing cipher CAMELLIA-256-CFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 59 53 ad ce 14 db 8c 7f 39 f1 bd 39 f3 59 bf fa

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 89 be db 4c cd d8 64 ea 11 ba 4c be 84 9b 5e 2b
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4

Testing cipher CAMELLIA-256-CFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 55 5f c3 f3 4b dd 2d 54 c6 2d 9e 3b f3 38 c1 c4
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 59 53 ad ce 14 db 8c 7f 39 f1 bd 39 f3 59 bf fa

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 25 62 3d b5 69 ca 51 e0 14 82 64 99 77 e2 8d 84

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 c7 76 63 4a 60 72 9d c6 57 d1 2b 9f ca 80 1e 98

Testing cipher CAMELLIA-128-OFB(encrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d7 76 37 9b e0 e5 08 25 e6 81 da 1a 4c 98 0e 8e

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 14 f7 64 61 87 81 7e b5 86 59 91 46 b8 2b d7 19

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 50 fe 67 cc 99 6d 32 b6 da 09 37 e9 9b af ec 60
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 25 62 3d b5 69 ca 51 e0 14 82 64 99 77 e2 8d 84

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 d9 a4 da da 08 92 23 9f 6b 8b 3d 76 80 e1 56 74
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 c7 76 63 4a 60 72 9d c6 57 d1 2b 9f ca 80 1e 98

Testing cipher CAMELLIA-128-OFB(decrypt)
Key
0000 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
IV
0000 a7 88 19 58 3f 03 08 e7 a6 bf 36 b1 38 6a bf 23
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 d7 76 37 9b e0 e5 08 25 e6 81 da 1a 4c 98 0e 8e

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 8e ce b7 d0 35 0d 72 c7 f7 85 62 ae bd f9 93 39

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 bd d6 2d bb b9 70 08 46 c5 3b 50 7f 54 46 96 f0

Testing cipher CAMELLIA-192-OFB(encrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 e2 80 14 e0 46 b8 02 f3 85 c4 c2 e1 3e ad 4a 72

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 c8 32 bb 97 80 67 7d aa 82 d9 b6 86 0d cd 56 5e

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 a6 09 b3 8d f3 b1 13 3d dd ff 27 18 ba 09 56 5e
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 8e ce b7 d0 35 0d 72 c7 f7 85 62 ae bd f9 93 39

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 bd d6 2d bb b9 70 08 46 c5 3b 50 7f 54 46 96 f0

Testing cipher CAMELLIA-192-OFB(decrypt)
Key
0000 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5
0010 62 f8 ea d2 52 2c 6b 7b
IV
0000 bd 52 86 ac 63 aa bd 7e b0 67 ac 54 b5 53 f7 1d
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 e2 80 14 e0 46 b8 02 f3 85 c4 c2 e1 3e ad 4a 72

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 12 7a d9 7e 8e 39 94 e4 82 00 27 d7 ba 10 93 68

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 6b ff 62 65 a6 a6 b7 a5 35 bc 65 a8 0b 17 21 4e

Testing cipher CAMELLIA-256-OFB(encrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 0a 4a 04 04 e2 6a a7 8a 27 cb 27 1e 8b f3 cf 20

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
Ciphertext
0000 cf 61 07 bb 0c ea 7d 7f b1 bd 31 f5 e7 b0 6c 93

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 b7 bf 3a 5d f4 39 89 dd 97 f0 fa 97 eb ce 2f 4a
Plaintext
0000 ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51
Ciphertext
0000 12 7a d9 7e 8e 39 94 e4 82 00 27 d7 ba 10 93 68

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 e1 c6 56 30 5e d1 a7 a6 56 38 05 74 6f e0 3e dc
Plaintext
0000 30 c8 1c 46 a3 5c e4 11 e5 fb c1 19 1a 0a 52 ef
Ciphertext
0000 6b ff 62 65 a6 a6 b7 a5 35 bc 65 a8 0b 17 21 4e

Testing cipher CAMELLIA-256-OFB(decrypt)
Key
0000 60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
0000 41 63 5b e6 25 b4 8a fc 16 66 dd 42 a0 9d 96 e7
Plaintext
0000 f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
0000 0a 4a 04 04 e2 6a a7 8a 27 cb 27 1e 8b f3 cf 20

Testing cipher SEED-ECB(decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Ciphertext
0000 5e ba c6 e0 05 4e 16 68 19 af f1 cc 6d 34 6c db

Testing cipher SEED-ECB(decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 c1 1f 22 f2 01 40 50 50 84 48 35 97 e4 37 0f 43

Testing cipher SEED-ECB(decrypt)
Key
0000 47 06 48 08 51 e6 1b e8 5d 74 bf b3 fd 95 61 85
Plaintext
0000 83 a2 f8 a2 88 64 1f b9 a4 e9 a5 cc 2f 13 1c 7d
Ciphertext
0000 ee 54 d1 3e bc ae 70 6d 22 6b c3 14 2c d4 0d 4a

Testing cipher SEED-ECB(decrypt)
Key
0000 28 db c3 bc 49 ff d8 7d cf a5 09 b1 1d 42 2b e7
Plaintext
0000 b4 1e 6b e2 eb a8 4a 14 8e 2e ed 84 59 3c 5e c7
Ciphertext
0000 9b 9b 7b fc d1 81 3c b9 5d 0b 36 18 f4 0f 51 22

Testing cipher SEED-ECB(encrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Ciphertext
0000 5e ba c6 e0 05 4e 16 68 19 af f1 cc 6d 34 6c db

Testing cipher SEED-ECB(encrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 c1 1f 22 f2 01 40 50 50 84 48 35 97 e4 37 0f 43

Testing cipher SEED-ECB(encrypt)
Key
0000 47 06 48 08 51 e6 1b e8 5d 74 bf b3 fd 95 61 85
Plaintext
0000 83 a2 f8 a2 88 64 1f b9 a4 e9 a5 cc 2f 13 1c 7d
Ciphertext
0000 ee 54 d1 3e bc ae 70 6d 22 6b c3 14 2c d4 0d 4a

Testing cipher SEED-ECB(encrypt)
Key
0000 28 db c3 bc 49 ff d8 7d cf a5 09 b1 1d 42 2b e7
Plaintext
0000 b4 1e 6b e2 eb a8 4a 14 8e 2e ed 84 59 3c 5e c7
Ciphertext
0000 9b 9b 7b fc d1 81 3c b9 5d 0b 36 18 f4 0f 51 22

Testing cipher id-aes256-CCM(encrypt/decrypt)
Key
0000 1b de 32 51 d4 1a 8b 5e a0 13 c1 95 ae 12 8b 21
0010 8b 3e 03 06 37 63 57 07 7e f1 c1 c7 85 48 b9 2e
IV
0000 5b 8e 40 74 6f 6b 98 e0 0f 1d 13 ff 41
Plaintext
0000 53 bd 72 a9 70 89 e3 12 42 2b f7 2e 24 23 77 b3
0010 c6 ee 3e 20 75 38 9b 99 9c 4e f7 f2 8b d2 b8 0a
Ciphertext
0000 9a 5f cc cd b4 cf 04 e7 29 3d 27 75 cc 76 a4 88
0010 f0 42 38 2d 94 9b 43 b7 d6 bb 2b 98 64 78 67 26
AAD
0000 c1 7a 32 51 4e b6 10 3f 32 49 e0 76 d4 c8 71 dc
0010 97 e0 4b 28 66 99 e5 44 91 dc 18 f6 d7 34 d4 c0
Tag
0000 20 24 93 1d 73 bc a4 80 c2 4a 24 ec e6 b6 c2 bf

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
Ciphertext
Tag
0000 58 e2 fc ce fa 7e 30 61 36 7f 1d 57 a4 e7 45 5a

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 03 88 da ce 60 b6 a3 92 f3 28 c2 b9 71 b2 fe 78
Tag
0000 ab 6e 47 d4 2c ec 13 bd f5 3a 67 b2 12 57 bd df

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 ca fe ba be fa ce db ad de ca f8 88
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39 1a af d2 55
Ciphertext
0000 42 83 1e c2 21 77 74 24 4b 72 21 b7 84 d0 d4 9c
0010 e3 aa 21 2f 2c 02 a4 e0 35 c1 7e 23 29 ac a1 2e
0020 21 d5 14 b2 54 66 93 1c 7d 8f 6a 5a ac 84 aa 05
0030 1b a3 0b 39 6a 0a ac 97 3d 58 e0 91 47 3f 59 85
Tag
0000 4d 5c 2a f3 27 cd 64 a6 2c f3 5a bd 2b a6 fa b4

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 ca fe ba be fa ce db ad de ca f8 88
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 42 83 1e c2 21 77 74 24 4b 72 21 b7 84 d0 d4 9c
0010 e3 aa 21 2f 2c 02 a4 e0 35 c1 7e 23 29 ac a1 2e
0020 21 d5 14 b2 54 66 93 1c 7d 8f 6a 5a ac 84 aa 05
0030 1b a3 0b 39 6a 0a ac 97 3d 58 e0 91
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 5b c9 4f bc 32 21 a5 db 94 fa e9 5a e7 12 1a 47

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 ca fe ba be fa ce db ad
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 61 35 3b 4c 28 06 93 4a 77 7f f5 1f a2 2a 47 55
0010 69 9b 2a 71 4f cd c6 f8 37 66 e5 f9 7b 6c 74 23
0020 73 80 69 00 e4 9f 24 b2 2b 09 75 44 d4 89 6b 42
0030 49 89 b5 e1 eb ac 0f 07 c2 3f 45 98
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 36 12 d2 e7 9e 3b 07 85 56 1b e1 4a ac a2 fc cb

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 93 13 22 5d f8 84 06 e5 55 90 9c 5a ff 52 69 aa
0010 6a 7a 95 38 53 4f 7d a1 e4 c3 03 d2 a3 18 a7 28
0020 c3 c0 c9 51 56 80 95 39 fc f0 e2 42 9a 6b 52 54
0030 16 ae db f5 a0 de 6a 57 a6 37 b3 9b
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 8c e2 49 98 62 56 15 b6 03 a0 33 ac a1 3f b8 94
0010 be 91 12 a5 c3 a2 11 a8 ba 26 2a 3c ca 7e 2c a7
0020 01 e4 a9 a4 fb a4 3c 90 cc dc b2 81 d4 8c 7c 6f
0030 d6 28 75 d2 ac a4 17 03 4c 34 ae e5
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 61 9c c5 ae ff fe 0b fa 46 2a f4 3c 16 99 d0 50

Testing cipher id-aes192-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
Ciphertext
Tag
0000 cd 33 b2 8a c7 73 f7 4b a0 0e d1 f3 12 57 24 35

Testing cipher id-aes192-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 98 e7 24 7c 07 f0 fe 41 1c 26 7e 43 84 b0 f6 00
Tag
0000 2f f5 8d 80 03 39 27 ab 8e f4 d4 58 75 14 f0 fb

Testing cipher id-aes192-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c
IV
0000 ca fe ba be fa ce db ad de ca f8 88
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39 1a af d2 55
Ciphertext
0000 39 80 ca 0b 3c 00 e8 41 eb 06 fa c4 87 2a 27 57
0010 85 9e 1c ea a6 ef d9 84 62 85 93 b4 0c a1 e1 9c
0020 7d 77 3d 00 c1 44 c5 25 ac 61 9d 18 c8 4a 3f 47
0030 18 e2 44 8b 2f e3 24 d9 cc da 27 10 ac ad e2 56
Tag
0000 99 24 a7 c8 58 73 36 bf b1 18 02 4d b8 67 4a 14

Testing cipher id-aes192-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c
IV
0000 ca fe ba be fa ce db ad de ca f8 88
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 39 80 ca 0b 3c 00 e8 41 eb 06 fa c4 87 2a 27 57
0010 85 9e 1c ea a6 ef d9 84 62 85 93 b4 0c a1 e1 9c
0020 7d 77 3d 00 c1 44 c5 25 ac 61 9d 18 c8 4a 3f 47
0030 18 e2 44 8b 2f e3 24 d9 cc da 27 10
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 25 19 49 8e 80 f1 47 8f 37 ba 55 bd 6d 27 61 8c

Testing cipher id-aes192-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c
IV
0000 ca fe ba be fa ce db ad
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 0f 10 f5 99 ae 14 a1 54 ed 24 b3 6e 25 32 4d b8
0010 c5 66 63 2e f2 bb b3 4f 83 47 28 0f c4 50 70 57
0020 fd dc 29 df 9a 47 1f 75 c6 65 41 d4 d4 da d1 c9
0030 e9 3a 19 a5 8e 8b 47 3f a0 f0 62 f7
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 65 dc c5 7f cf 62 3a 24 09 4f cc a4 0d 35 33 f8

Testing cipher id-aes192-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c
IV
0000 93 13 22 5d f8 84 06 e5 55 90 9c 5a ff 52 69 aa
0010 6a 7a 95 38 53 4f 7d a1 e4 c3 03 d2 a3 18 a7 28
0020 c3 c0 c9 51 56 80 95 39 fc f0 e2 42 9a 6b 52 54
0030 16 ae db f5 a0 de 6a 57 a6 37 b3 9b
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 d2 7e 88 68 1c e3 24 3c 48 30 16 5a 8f dc f9 ff
0010 1d e9 a1 d8 e6 b4 47 ef 6e f7 b7 98 28 66 6e 45
0020 81 e7 90 12 af 34 dd d9 e2 f0 37 58 9b 29 2d b3
0030 e6 7c 03 67 45 fa 22 e7 e9 b7 37 3b
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 dc f5 66 ff 29 1c 25 bb b8 56 8f c3 d3 76 a6 d9

Testing cipher id-aes256-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
Ciphertext
Tag
0000 53 0f 8a fb c7 45 36 b9 a9 63 b4 f1 c4 cb 73 8b

Testing cipher id-aes256-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 ce a7 40 3d 4d 60 6b 6e 07 4e c5 d3 ba f3 9d 18
Tag
0000 d0 d1 c8 a7 99 99 6b f0 26 5b 98 b5 d4 8a b9 19

Testing cipher id-aes256-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 ca fe ba be fa ce db ad de ca f8 88
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39 1a af d2 55
Ciphertext
0000 52 2d c1 f0 99 56 7d 07 f4 7f 37 a3 2a 84 42 7d
0010 64 3a 8c dc bf e5 c0 c9 75 98 a2 bd 25 55 d1 aa
0020 8c b0 8e 48 59 0d bb 3d a7 b0 8b 10 56 82 88 38
0030 c5 f6 1e 63 93 ba 7a 0a bc c9 f6 62 89 80 15 ad
Tag
0000 b0 94 da c5 d9 34 71 bd ec 1a 50 22 70 e3 cc 6c

Testing cipher id-aes256-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 ca fe ba be fa ce db ad de ca f8 88
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 52 2d c1 f0 99 56 7d 07 f4 7f 37 a3 2a 84 42 7d
0010 64 3a 8c dc bf e5 c0 c9 75 98 a2 bd 25 55 d1 aa
0020 8c b0 8e 48 59 0d bb 3d a7 b0 8b 10 56 82 88 38
0030 c5 f6 1e 63 93 ba 7a 0a bc c9 f6 62
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 76 fc 6e ce 0f 4e 17 68 cd df 88 53 bb 2d 55 1b

Testing cipher id-aes256-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 ca fe ba be fa ce db ad
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 c3 76 2d f1 ca 78 7d 32 ae 47 c1 3b f1 98 44 cb
0010 af 1a e1 4d 0b 97 6a fa c5 2f f7 d7 9b ba 9d e0
0020 fe b5 82 d3 39 34 a4 f0 95 4c c2 36 3b c7 3f 78
0030 62 ac 43 0e 64 ab e4 99 f4 7c 9b 1f
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 3a 33 7d bf 46 a7 92 c4 5e 45 49 13 fe 2e a8 f2

Testing cipher id-aes256-GCM(encrypt/decrypt)
Key
0000 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
0010 fe ff e9 92 86 65 73 1c 6d 6a 8f 94 67 30 83 08
IV
0000 93 13 22 5d f8 84 06 e5 55 90 9c 5a ff 52 69 aa
0010 6a 7a 95 38 53 4f 7d a1 e4 c3 03 d2 a3 18 a7 28
0020 c3 c0 c9 51 56 80 95 39 fc f0 e2 42 9a 6b 52 54
0030 16 ae db f5 a0 de 6a 57 a6 37 b3 9b
Plaintext
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39
Ciphertext
0000 5a 8d ef 2f 0c 9e 53 f1 f7 5d 78 53 65 9e 2a 20
0010 ee b2 b2 2a af de 64 19 a0 58 ab 4f 6f 74 6b f4
0020 0f c0 c3 b7 80 f2 44 45 2d a3 eb f1 c5 d8 2c de
0030 a2 41 89 97 20 0e f8 2e 44 ae 7e 3f
AAD
0000 fe ed fa ce de ad be ef fe ed fa ce de ad be ef
0010 ab ad da d2
Tag
0000 a4 4a 82 66 ee 1c 8e b0 c8 b5 d4 cf 5a e9 f1 9a

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
Ciphertext
AAD
0000 d9 31 32 25 f8 84 06 e5 a5 59 09 c5 af f5 26 9a
0010 86 a7 a9 53 15 34 f7 da 2e 4c 30 3d 8a 31 8a 72
0020 1c 3c 0c 95 95 68 09 53 2f cf 0e 24 49 a6 b5 25
0030 b1 6a ed f5 aa 0d e6 57 ba 63 7b 39 1a af d2 55
0040 52 2d c1 f0 99 56 7d 07 f4 7f 37 a3 2a 84 42 7d
0050 64 3a 8c dc bf e5 c0 c9 75 98 a2 bd 25 55 d1 aa
0060 8c b0 8e 48 59 0d bb 3d a7 b0 8b 10 56 82 88 38
0070 c5 f6 1e 63 93 ba 7a 0a bc c9 f6 62 89 80 15 ad
Tag
0000 5f ea 79 3a 2d 6f 97 4d 37 e6 8e 0c b8 ff 94 92

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 03 88 da ce 60 b6 a3 92 f3 28 c2 b9 71 b2 fe 78
0010 f7 95 aa ab 49 4b 59 23 f7 fd 89 ff 94 8b c1 e0
0020 20 02 11 21 4e 73 94 da 20 89 b6 ac d0 93 ab e0
Tag
0000 9d d0 a3 76 b0 8e 40 eb 00 c3 5f 29 f9 ea 61 a4

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 03 88 da ce 60 b6 a3 92 f3 28 c2 b9 71 b2 fe 78
0010 f7 95 aa ab 49 4b 59 23 f7 fd 89 ff 94 8b c1 e0
0020 20 02 11 21 4e 73 94 da 20 89 b6 ac d0 93 ab e0
0030 c9 4d a2 19 11 8e 29 7d 7b 7e bc bc c9 c3 88 f2
0040 8a de 7d 85 a8 ee 35 61 6f 71 24 a9 d5 27 02 91
Tag
0000 98 88 5a 3a 22 bd 47 42 fe 7b 72 17 21 93 b1 63

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 03 88 da ce 60 b6 a3 92 f3 28 c2 b9 71 b2 fe 78
0010 f7 95 aa ab 49 4b 59 23 f7 fd 89 ff 94 8b c1 e0
0020 20 02 11 21 4e 73 94 da 20 89 b6 ac d0 93 ab e0
0030 c9 4d a2 19 11 8e 29 7d 7b 7e bc bc c9 c3 88 f2
0040 8a de 7d 85 a8 ee 35 61 6f 71 24 a9 d5 27 02 91
0050 95 b8 4d 1b 96 c6 90 ff 2f 2d e3 0b f2 ec 89 e0
0060 02 53 78 6e 12 65 04 f0 da b9 0c 48 a3 03 21 de
0070 33 45 e6 b0 46 1e 7c 9e 6c 6b 7a fe dd e8 3f 40
Tag
0000 ca c4 5f 60 e3 1e fd 3b 5a 43 b9 8a 22 ce 1a a1

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 56 b3 37 3c a9 ef 6e 4a 2b 64 fe 1e 9a 17 b6 14
0010 25 f1 0d 47 a7 5a 5f ce 13 ef c6 bc 78 4a f2 4f
0020 41 41 bd d4 8c f7 c7 70 88 7a fd 57 3c ca 54 18
0030 a9 ae ff cd 7c 5c ed df c6 a7 83 97 b9 a8 5b 49
0040 9d a5 58 25 72 67 ca ab 2a d0 b2 3c a4 76 a5 3c
0050 b1 7f b4 1c 4b 8b 47 5c b4 f3 f7 16 50 94 c2 29
0060 c9 e8 c4 dc 0a 2a 5f f1 90 3e 50 15 11 22 13 76
0070 a1 cd b8 36 4c 50 61 a2 0c ae 74 bc 4a cd 76 ce
0080 b0 ab c9 fd 32 17 ef 9f 8c 90 be 40 2d df 6d 86
0090 97 f4 f8 80 df f1 5b fb 7a 6b 28 24 1e c8 fe 18
00a0 3c 2d 59 e3 f9 df ff 65 3c 71 26 f0 ac b9 e6 42
00b0 11 f4 2b ae 12 af 46 2b 10 70 be f1 ab 5e 36 06
Tag
0000 56 6f 8e f6 83 07 8b fd ee ff a8 69 d7 51 a0 17

Testing cipher id-aes128-GCM(encrypt/decrypt)
Key
0000 84 3f fc f5 d2 b7 26 94 d1 9e d0 1d 01 24 94 12
IV
0000 db cc a3 2e bf 9b 80 46 17 c3 aa 9e
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
Ciphertext
0000 62 68 c6 fa 2a 80 b2 d1 37 46 7f 09 2f 65 7a c0
0010 4d 89 be 2b ea a6 23 d6 1b 5a 86 8c 8f 03 ff 95
0020 d3 dc ee 23 ad 2f 1a b3 a6 c8 0e af 4b 14 0e b0
0030 5d e3 45 7f 0f bc 11 1a 6b 43 d0 76 3a a4 22 a3
0040 01 3c f1 dc 37 fe 41 7d 1f bf c4 49 b7 5d 4c c5
AAD
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Tag
0000 3b 62 9c cf bc 11 19 b7 31 9e 1d ce 2c d6 fd 6d

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Ciphertext
0000 91 7c f6 9e bd 68 b2 ec 9b 9f e9 a3 ea dd a6 92
0010 cd 43 d2 f5 95 98 ed 85 8c 02 c2 65 2f bf 92 2e

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
0010 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
IV
0000 33 33 33 33 33 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44
0010 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44
Ciphertext
0000 c4 54 18 5e 6a 16 93 6e 39 33 40 38 ac ef 83 8b
0010 fb 18 6f ff 74 80 ad c4 28 93 82 ec d6 d3 94 f0

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
0010 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22
IV
0000 33 33 33 33 33 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44
0010 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44 44
Ciphertext
0000 af 85 33 6b 59 7a fc 1a 90 0b 2e b2 1e c9 49 d2
0010 92 df 4c 04 7e 0b 21 53 21 86 a5 97 1a 22 7a 89

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
IV
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 27 a7 47 9b ef a1 d4 76 48 9f 30 8c d4 cf a6 e2
0010 a9 6e 4b be 32 08 ff 25 28 7d d3 81 96 16 e8 9c
0020 c7 8c f7 f5 e5 43 44 5f 83 33 d8 fa 7f 56 00 00
0030 05 27 9f a5 d8 b5 e4 ad 40 e7 36 dd b4 d3 54 12
0040 32 80 63 fd 2a ab 53 e5 ea 1e 0a 9f 33 25 00 a5
0050 df 94 87 d0 7a 5c 92 cc 51 2c 88 66 c7 e8 60 ce
0060 93 fd f1 66 a2 49 12 b4 22 97 61 46 ae 20 ce 84
0070 6b b7 dc 9b a9 4a 76 7a ae f2 0c 0d 61 ad 02 65
0080 5e a9 2d c4 c4 e4 1a 89 52 c6 51 d3 31 74 be 51
0090 a1 0c 42 11 10 e6 d8 15 88 ed e8 21 03 a2 52 d8
00a0 a7 50 e8 76 8d ef ff ed 91 22 81 0a ae b9 9f 91
00b0 72 af 82 b6 04 dc 4b 8e 51 bc b0 82 35 a6 f4 34
00c0 13 32 e4 ca 60 48 2a 4b a1 a0 3b 3e 65 00 8f c5
00d0 da 76 b7 0b f1 69 0d b4 ea e2 9c 5f 1b ad d0 3c
00e0 5c cf 2a 55 d7 05 dd cd 86 d4 49 51 1c eb 7e c3
00f0 0b f1 2b 1f a3 5b 91 3f 9f 74 7a 8a fd 1b 13 0e
0100 94 bf f9 4e ff d0 1a 91 73 5c a1 72 6a cd 0b 19
0110 7c 4e 5b 03 39 36 97 e1 26 82 6f b6 bb de 8e cc
0120 1e 08 29 85 16 e2 c9 ed 03 ff 3c 1b 78 60 f6 de
0130 76 d4 ce cd 94 c8 11 98 55 ef 52 97 ca 67 e9 f3
0140 e7 ff 72 b1 e9 97 85 ca 0a 7e 77 20 c5 b3 6d c6
0150 d7 2c ac 95 74 c8 cb bc 2f 80 1e 23 e5 6f d3 44
0160 b0 7f 22 15 4b eb a0 f0 8c e8 89 1e 64 3e d9 95
0170 c9 4d 9a 69 c9 f1 b5 f4 99 02 7a 78 57 2a ee bd
0180 74 d2 0c c3 98 81 c2 13 ee 77 0b 10 10 e4 be a7
0190 18 84 69 77 ae 11 9f 7a 02 3a b5 8c ca 0a d7 52
01a0 af e6 56 bb 3c 17 25 6a 9f 6e 9b f1 9f dd 5a 38
01b0 fc 82 bb e8 72 c5 53 9e db 60 9e f4 f7 9c 20 3e
01c0 bb 14 0f 2e 58 3c b2 ad 15 b4 aa 5b 65 50 16 a8
01d0 44 92 77 db d4 77 ef 2c 8d 6c 01 7d b7 38 b1 8d
01e0 eb 4a 42 7d 19 23 ce 3f f2 62 73 57 79 a4 18 f2
01f0 0a 28 2d f9 20 14 7b ea be 42 1e e5 31 9d 05 68

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
IV
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 27 a7 47 9b ef a1 d4 76 48 9f 30 8c d4 cf a6 e2
0010 a9 6e 4b be 32 08 ff 25 28 7d d3 81 96 16 e8 9c
0020 c7 8c f7 f5 e5 43 44 5f 83 33 d8 fa 7f 56 00 00
0030 05 27 9f a5 d8 b5 e4 ad 40 e7 36 dd b4 d3 54 12
0040 32 80 63 fd 2a ab 53 e5 ea 1e 0a 9f 33 25 00 a5
0050 df 94 87 d0 7a 5c 92 cc 51 2c 88 66 c7 e8 60 ce
0060 93 fd f1 66 a2 49 12 b4 22 97 61 46 ae 20 ce 84
0070 6b b7 dc 9b a9 4a 76 7a ae f2 0c 0d 61 ad 02 65
0080 5e a9 2d c4 c4 e4 1a 89 52 c6 51 d3 31 74 be 51
0090 a1 0c 42 11 10 e6 d8 15 88 ed e8 21 03 a2 52 d8
00a0 a7 50 e8 76 8d ef ff ed 91 22 81 0a ae b9 9f 91
00b0 72 af 82 b6 04 dc 4b 8e 51 bc b0 82 35 a6 f4 34
00c0 13 32 e4 ca 60 48 2a 4b a1 a0 3b 3e 65 00 8f c5
00d0 da 76 b7 0b f1 69 0d b4 ea e2 9c 5f 1b ad d0 3c
00e0 5c cf 2a 55 d7 05 dd cd 86 d4 49 51 1c eb 7e c3
00f0 0b f1 2b 1f a3 5b 91 3f 9f 74 7a 8a fd 1b 13 0e
0100 94 bf f9 4e ff d0 1a 91 73 5c a1 72 6a cd 0b 19
0110 7c 4e 5b 03 39 36 97 e1 26 82 6f b6 bb de 8e cc
0120 1e 08 29 85 16 e2 c9 ed 03 ff 3c 1b 78 60 f6 de
0130 76 d4 ce cd 94 c8 11 98 55 ef 52 97 ca 67 e9 f3
0140 e7 ff 72 b1 e9 97 85 ca 0a 7e 77 20 c5 b3 6d c6
0150 d7 2c ac 95 74 c8 cb bc 2f 80 1e 23 e5 6f d3 44
0160 b0 7f 22 15 4b eb a0 f0 8c e8 89 1e 64 3e d9 95
0170 c9 4d 9a 69 c9 f1 b5 f4 99 02 7a 78 57 2a ee bd
0180 74 d2 0c c3 98 81 c2 13 ee 77 0b 10 10 e4 be a7
0190 18 84 69 77 ae 11 9f 7a 02 3a b5 8c ca 0a d7 52
01a0 af e6 56 bb 3c 17 25 6a 9f 6e 9b f1 9f dd 5a 38
01b0 fc 82 bb e8 72 c5 53 9e db 60 9e f4 f7 9c 20 3e
01c0 bb 14 0f 2e 58 3c b2 ad 15 b4 aa 5b 65 50 16 a8
01d0 44 92 77 db d4 77 ef 2c 8d 6c 01 7d b7 38 b1 8d
01e0 eb 4a 42 7d 19 23 ce 3f f2 62 73 57 79 a4 18 f2
01f0 0a 28 2d f9 20 14 7b ea be 42 1e e5 31 9d 05 68
Ciphertext
0000 26 4d 3c a8 51 21 94 fe c3 12 c8 c9 89 1f 27 9f
0010 ef dd 60 8d 0c 02 7b 60 48 3a 3f a8 11 d6 5e e5
0020 9d 52 d9 e4 0e c5 67 2d 81 53 2b 38 b6 b0 89 ce
0030 95 1f 0f 9c 35 59 0b 8b 97 8d 17 52 13 f3 29 bb
0040 1c 2f d3 0f 2f 7f 30 49 2a 61 a5 32 a7 9f 51 d3
0050 6f 5e 31 a7 c9 a1 2c 28 60 82 ff 7d 23 94 d1 8f
0060 78 3e 1a 8e 72 c7 22 ca aa a5 2d 8f 06 56 57 d2
0070 63 1f d2 5b fd 8e 5b aa d6 e5 27 d7 63 51 75 01
0080 c6 8c 5e dc 3c dd 55 43 5c 53 2d 71 25 c8 61 4d
0090 ee d9 ad aa 3a ca de 58 88 b8 7b ef 64 1c 4c 99
00a0 4c 80 91 b5 bc d3 87 f3 96 3f b5 bc 37 aa 92 2f
00b0 bf e3 df 4e 5b 91 5e 6e b5 14 71 7b dd 2a 74 07
00c0 9a 50 73 f5 c4 bf d4 6a df 7d 28 2e 7a 39 3a 52
00d0 57 9d 11 a0 28 da 4d 9c d9 c7 71 24 f9 64 8e e3
00e0 83 b1 ac 76 39 30 e7 16 2a 8d 37 f3 50 b2 f7 4b
00f0 84 72 cf 09 90 20 63 c6 b3 2e 8c 2d 92 90 ce fb
0100 d7 34 6d 1c 77 9a 0d f5 0e dc de 45 31 da 07 b0
0110 99 c6 38 e8 3a 75 59 44 df 2a ef 1a a3 17 52 fd
0120 32 3d cb 71 0f b4 bf bb 9d 22 b9 25 bc 35 77 e1
0130 b8 94 9e 72 9a 90 bb af ea cf 7f 78 79 e7 b1 14
0140 7e 28 ba 0b ae 94 0d b7 95 a6 1b 15 ec f4 df 8d
0150 b0 7b 82 4b b0 62 80 2c c9 8a 95 45 bb 2a ae ed
0160 77 cb 3f c6 db 15 dc d7 d8 0d 7d 5b c4 06 c4 97
0170 0a 34 78 ad a8 89 9b 32 91 98 eb 61 c1 93 fb 62
0180 75 aa 8c a3 40 34 4a 75 a8 62 ae be 92 ee e1 ce
0190 03 2f d9 50 b4 7d 77 04 a3 87 69 23 b4 ad 62 84
01a0 4b f4 a0 9c 4d be 8b 43 97 18 4b 74 71 36 0c 95
01b0 64 88 0a ed dd b9 ba a4 af 2e 75 39 4b 08 cd 32
01c0 ff 47 9c 57 a0 7d 3e ab 5d 54 de 5f 97 38 b8 d2
01d0 7f 27 a9 f0 ab 11 79 9d 7b 7f fe fb 27 04 c9 5c
01e0 6a d1 2c 39 f1 e8 67 a4 b7 b1 d7 81 8a 4b 75 3d
01f0 fd 2a 89 cc b4 5e 00 1a 03 a8 67 b1 87 f2 25 dd

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
IV
0000 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 26 4d 3c a8 51 21 94 fe c3 12 c8 c9 89 1f 27 9f
0010 ef dd 60 8d 0c 02 7b 60 48 3a 3f a8 11 d6 5e e5
0020 9d 52 d9 e4 0e c5 67 2d 81 53 2b 38 b6 b0 89 ce
0030 95 1f 0f 9c 35 59 0b 8b 97 8d 17 52 13 f3 29 bb
0040 1c 2f d3 0f 2f 7f 30 49 2a 61 a5 32 a7 9f 51 d3
0050 6f 5e 31 a7 c9 a1 2c 28 60 82 ff 7d 23 94 d1 8f
0060 78 3e 1a 8e 72 c7 22 ca aa a5 2d 8f 06 56 57 d2
0070 63 1f d2 5b fd 8e 5b aa d6 e5 27 d7 63 51 75 01
0080 c6 8c 5e dc 3c dd 55 43 5c 53 2d 71 25 c8 61 4d
0090 ee d9 ad aa 3a ca de 58 88 b8 7b ef 64 1c 4c 99
00a0 4c 80 91 b5 bc d3 87 f3 96 3f b5 bc 37 aa 92 2f
00b0 bf e3 df 4e 5b 91 5e 6e b5 14 71 7b dd 2a 74 07
00c0 9a 50 73 f5 c4 bf d4 6a df 7d 28 2e 7a 39 3a 52
00d0 57 9d 11 a0 28 da 4d 9c d9 c7 71 24 f9 64 8e e3
00e0 83 b1 ac 76 39 30 e7 16 2a 8d 37 f3 50 b2 f7 4b
00f0 84 72 cf 09 90 20 63 c6 b3 2e 8c 2d 92 90 ce fb
0100 d7 34 6d 1c 77 9a 0d f5 0e dc de 45 31 da 07 b0
0110 99 c6 38 e8 3a 75 59 44 df 2a ef 1a a3 17 52 fd
0120 32 3d cb 71 0f b4 bf bb 9d 22 b9 25 bc 35 77 e1
0130 b8 94 9e 72 9a 90 bb af ea cf 7f 78 79 e7 b1 14
0140 7e 28 ba 0b ae 94 0d b7 95 a6 1b 15 ec f4 df 8d
0150 b0 7b 82 4b b0 62 80 2c c9 8a 95 45 bb 2a ae ed
0160 77 cb 3f c6 db 15 dc d7 d8 0d 7d 5b c4 06 c4 97
0170 0a 34 78 ad a8 89 9b 32 91 98 eb 61 c1 93 fb 62
0180 75 aa 8c a3 40 34 4a 75 a8 62 ae be 92 ee e1 ce
0190 03 2f d9 50 b4 7d 77 04 a3 87 69 23 b4 ad 62 84
01a0 4b f4 a0 9c 4d be 8b 43 97 18 4b 74 71 36 0c 95
01b0 64 88 0a ed dd b9 ba a4 af 2e 75 39 4b 08 cd 32
01c0 ff 47 9c 57 a0 7d 3e ab 5d 54 de 5f 97 38 b8 d2
01d0 7f 27 a9 f0 ab 11 79 9d 7b 7f fe fb 27 04 c9 5c
01e0 6a d1 2c 39 f1 e8 67 a4 b7 b1 d7 81 8a 4b 75 3d
01f0 fd 2a 89 cc b4 5e 00 1a 03 a8 67 b1 87 f2 25 dd
Ciphertext
0000 fa 76 2a 36 80 b7 60 07 92 8e d4 a4 f4 9a 94 56
0010 03 1b 70 47 82 e6 5e 16 ce cb 54 ed 7d 01 7b 5e
0020 18 ab d6 7b 33 8e 81 07 8f 21 ed b7 86 8d 90 1e
0030 be 9c 73 1a 7c 18 b5 e6 de c1 d6 a7 2e 07 8a c9
0040 a4 26 2f 86 0b ee fa 14 f4 e8 21 01 82 72 e4 11
0050 a9 51 50 2b 6e 79 06 6e 84 25 2c 33 46 f3 aa 62
0060 34 43 51 a2 91 d4 be dc 7a 07 61 8b de a2 af 63
0070 14 5c c7 a4 b8 d4 07 06 91 ae 89 0c d6 57 33 e7
0080 94 6e 90 21 a1 df fc 4c 59 f1 59 42 5e e6 d5 0c
0090 a9 b1 35 fa 61 62 ce a1 8a 93 98 38 dc 00 0f b3
00a0 86 fa d0 86 ac ce 5a c0 7c b2 ec e7 fd 58 0b 00
00b0 cf a5 e9 85 89 63 1d c2 5e 8e 2a 3d af 2f fd ec
00c0 26 53 16 59 91 2c 9d 8f 7a 15 e5 86 5e a8 fb 58
00d0 16 d6 20 70 52 bd 71 28 cd 74 3c 12 c8 11 87 91
00e0 a4 73 68 11 93 5e b9 82 a5 32 34 9e 31 dd 40 1e
00f0 0b 66 0a 56 8c b1 a4 71 1f 55 2f 55 de d5 9f 1f
0100 15 bf 71 96 b3 ca 12 a9 1e 48 8e f5 9d 64 f3 a0
0110 2b f4 52 39 49 9a c6 17 6a e3 21 c4 a2 11 ec 54
0120 53 65 97 1c 5d 3f 4f 09 d4 eb 13 9b fd f2 07 3d
0130 33 18 0b 21 00 2b 65 cc 98 65 e7 6c b2 4c d9 2c
0140 87 4c 24 c1 83 50 39 9a 93 6a b3 63 70 79 29 5d
0150 76 c4 17 77 6b 94 ef ce 3a 0e f7 20 6b 15 11 05
0160 19 65 5c 95 6c bd 8b 24 89 40 5e e2 b0 9a 6b 6e
0170 eb e0 c5 37 90 a1 2a 89 98 37 8b 33 a5 b7 11 59
0180 62 5f 4b a4 9d 2a 2f db a5 9f bf 08 97 bc 7a ab
0190 d8 d7 07 dc 14 0a 80 f0 f3 09 f8 35 d3 da 54 ab
01a0 58 4e 50 1d fa 0e e9 77 fe c5 43 f7 41 86 a8 02
01b0 b9 a3 7a db 3e 82 91 ec a0 4d 66 52 0d 22 9e 60
01c0 40 1e 72 82 be f4 86 ae 05 9a a7 06 96 e0 e3 05
01d0 d7 77 14 0a 7a 88 3e cd cb 69 b9 ff 93 8e 8a 42
01e0 31 86 4c 69 ca 2c 20 43 be d0 07 ff 3e 60 5e 01
01f0 4b cf 51 81 38 dc 3a 25 c5 e2 36 17 1a 2d 01 d6

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
IV
0000 fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 8e 41 b7 8c 39 0b 5a f9 d7 58 bb 21 4a 67 e9 f6
0010 bf 77 27 b0 9a c6 12 40 84 c3 76 11 39 8f a4 5d
0020 aa d9 48 68 60 0e d3 91 fb 1a cd 48 57 a9 5b 46
0030 6e 62 ef 9f 4b 37 72 44 d1 c1 52 e7 b3 0d 73 1a
0040 ad 30 c7 16 d2 14 b7 07 ae d9 9e b5 b5 e5 80 b3
0050 e8 87 cf 74 97 46 56 51 d4 b6 0e 60 42 05 1d a3
0060 69 3c 3b 78 c1 44 89 54 3b e8 b6 ad 0b a6 29 56
0070 5b ba 20 23 13 ba 7b 0d 0c 94 a3 25 2b 67 6f 46
0080 cc 02 ce 0f 8a 7d 34 c0 ed 22 91 29 67 3c 1f 61
0090 ae d5 79 d0 8a 92 03 a2 5a ac 3a 77 e9 db 60 26
00a0 79 96 db 38 df 63 73 56 d9 dc d1 63 2e 36 99 39
00b0 f2 a2 9d 89 34 5c 66 e0 50 66 f1 a3 67 7a ef 18
00c0 de a4 11 3f ae b6 29 e4 67 21 a6 6d 0a 7e 78 5d
00d0 3e 29 af 25 94 eb 67 df a9 82 af fe 0a ac 05 8f
00e0 6e 15 86 42 69 b1 35 41 82 61 fc 3a fb 08 94 72
00f0 cf 68 c4 5d d7 f2 31 c6 24 9b a0 25 5e 1e 03 38
0100 33 fc 4d 00 a3 fe 02 13 2d 7b c3 87 36 14 b8 ae
0110 e3 42 73 58 1e a0 32 5c 81 f0 27 0a ff a1 36 41
0120 d0 52 d3 6f 07 57 d4 84 01 43 54 d0 2d 68 83 ca
0130 15 c2 4d 8c 39 56 b1 bd 02 7b cf 41 f1 51 fd 80
0140 23 c5 34 0e 56 06 f3 7e 90 fd b8 7c 86 fb 4f a6
0150 34 b3 71 8a 30 ba ce 06 a6 6e af 8f 63 c4 aa 3b
0160 63 78 26 a8 7f e8 cf a4 42 82 e9 2c b1 61 5a f3
0170 a2 8e 53 bc 74 c7 cb a1 a0 97 7b e9 06 5d 0c 1a
0180 5d ec 6c 54 ae 38 d3 7f 37 aa 35 28 3e 04 8e 55
0190 30 a8 5c 4e 7a 29 d7 b9 2e c0 c3 16 9c df 2a 80
01a0 5c 76 04 bc e6 00 49 b9 fb 7b 8e aa c1 0f 51 ae
01b0 23 79 4c eb a6 8b b5 81 12 e2 93 b9 b6 92 ca 72
01c0 1b 37 c6 62 f8 57 4e d4 db a6 f8 8e 17 08 81 c8
01d0 2c dd c1 03 4a 0c a7 e2 84 bf 09 62 b6 b2 62 92
01e0 d8 36 fa 9f 73 c1 ac 77 0e ef 0f 2d 3a 1e af 61
01f0 d3 e0 35 55 fd 42 4e ed d6 7e 18 a1 80 94 f8 88
Ciphertext
0000 d5 5f 68 4f 81 f4 42 6e 9f de 92 a5 ff 02 df 2a
0010 c8 96 af 63 96 28 88 a9 79 10 c1 37 9e 20 b0 a3
0020 b1 db 61 3f b7 fe 2e 07 00 43 29 ea 5c 22 bf d3
0030 3e 3d be 4c f5 8c c6 08 c2 c2 6c 19 a2 e2 fe 22
0040 f9 87 32 c2 b5 cb 84 4c c6 c0 70 2d 91 e1 d5 0f
0050 c4 38 2a 7e ba 56 35 cd 60 24 32 a2 30 6a c4 ce
0060 82 f8 d7 0c 8d 9b c1 5f 91 8f e7 1e 74 c6 22 d5
0070 cf 71 17 8b f6 e0 b9 cc 9f 2b 41 dd 8d be 44 1c
0080 41 cd 0c 73 a6 dc 47 a3 48 f6 70 2f 9d 0e 9b 1b
0090 14 31 e9 48 e2 99 b9 ec 22 72 ab 2c 5f 0c 7b e8
00a0 6a ff a5 de c8 7a 0b ee 81 d3 d5 00 07 ed aa 2b
00b0 cf cc b3 56 05 15 5f f3 6e d8 ed d4 a4 0d cd 4b
00c0 24 3a cd 11 b2 b9 87 bd bf af 91 a7 ca c2 7e 9c
00d0 5a ea 52 5e e5 3d e7 b2 d3 33 2c 86 44 40 2b 82
00e0 3e 94 a7 db 26 27 6d 2d 23 aa 07 18 0f 76 b4 fd
00f0 29 b9 c0 82 30 99 c9 d6 2c 51 98 80 ae e7 e9 69
0100 76 17 c1 49 7d 47 bf 3e 57 19 50 31 14 21 b6 b7
0110 34 d3 8b 0d b9 1e b8 53 31 b9 1e a9 f6 15 30 f5
0120 45 12 a5 a5 2a 4b ad 58 9e b6 97 81 d5 37 f2 32
0130 97 bb 45 9b da d2 94 8a 29 e1 55 0b f4 78 7e 0b
0140 e9 5b b1 73 cf 5f ab 17 da b7 a1 3a 05 2a 63 45
0150 3d 97 cc ec 1a 32 19 54 88 6b 7a 12 99 fa ae ec
0160 ae 35 c6 ea ac a7 53 b0 41 b5 e5 f0 93 bf 83 39
0170 7f d2 1d d6 b3 01 20 66 fc c0 58 cc 32 c3 b0 9d
0180 75 62 de e2 95 09 b5 83 93 92 c9 ff 05 f5 1f 31
0190 66 aa ac 4a c5 f2 38 03 8a 30 45 e6 f7 2e 48 ef
01a0 0f e8 bc 67 5e 82 c3 18 a2 68 e4 39 70 27 1b f1
01b0 19 b8 1b f6 a9 82 74 65 54 f8 4e 72 b9 f0 02 80
01c0 a3 20 a0 81 42 92 3c 23 c8 83 42 3f f9 49 82 7f
01d0 29 bb ac dc 1c cd b0 49 38 ce 60 98 c9 5b a6 b3
01e0 25 28 f4 ef 78 ee d7 78 b2 e1 22 dd fd 1c bd d1
01f0 1d 1c 0a 67 83 e0 11 fc 53 6d 63 d0 53 26 06 37

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
IV
0000 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 d5 5f 68 4f 81 f4 42 6e 9f de 92 a5 ff 02 df 2a
0010 c8 96 af 63 96 28 88 a9 79 10 c1 37 9e 20 b0 a3
0020 b1 db 61 3f b7 fe 2e 07 00 43 29 ea 5c 22 bf d3
0030 3e 3d be 4c f5 8c c6 08 c2 c2 6c 19 a2 e2 fe 22
0040 f9 87 32 c2 b5 cb 84 4c c6 c0 70 2d 91 e1 d5 0f
0050 c4 38 2a 7e ba 56 35 cd 60 24 32 a2 30 6a c4 ce
0060 82 f8 d7 0c 8d 9b c1 5f 91 8f e7 1e 74 c6 22 d5
0070 cf 71 17 8b f6 e0 b9 cc 9f 2b 41 dd 8d be 44 1c
0080 41 cd 0c 73 a6 dc 47 a3 48 f6 70 2f 9d 0e 9b 1b
0090 14 31 e9 48 e2 99 b9 ec 22 72 ab 2c 5f 0c 7b e8
00a0 6a ff a5 de c8 7a 0b ee 81 d3 d5 00 07 ed aa 2b
00b0 cf cc b3 56 05 15 5f f3 6e d8 ed d4 a4 0d cd 4b
00c0 24 3a cd 11 b2 b9 87 bd bf af 91 a7 ca c2 7e 9c
00d0 5a ea 52 5e e5 3d e7 b2 d3 33 2c 86 44 40 2b 82
00e0 3e 94 a7 db 26 27 6d 2d 23 aa 07 18 0f 76 b4 fd
00f0 29 b9 c0 82 30 99 c9 d6 2c 51 98 80 ae e7 e9 69
0100 76 17 c1 49 7d 47 bf 3e 57 19 50 31 14 21 b6 b7
0110 34 d3 8b 0d b9 1e b8 53 31 b9 1e a9 f6 15 30 f5
0120 45 12 a5 a5 2a 4b ad 58 9e b6 97 81 d5 37 f2 32
0130 97 bb 45 9b da d2 94 8a 29 e1 55 0b f4 78 7e 0b
0140 e9 5b b1 73 cf 5f ab 17 da b7 a1 3a 05 2a 63 45
0150 3d 97 cc ec 1a 32 19 54 88 6b 7a 12 99 fa ae ec
0160 ae 35 c6 ea ac a7 53 b0 41 b5 e5 f0 93 bf 83 39
0170 7f d2 1d d6 b3 01 20 66 fc c0 58 cc 32 c3 b0 9d
0180 75 62 de e2 95 09 b5 83 93 92 c9 ff 05 f5 1f 31
0190 66 aa ac 4a c5 f2 38 03 8a 30 45 e6 f7 2e 48 ef
01a0 0f e8 bc 67 5e 82 c3 18 a2 68 e4 39 70 27 1b f1
01b0 19 b8 1b f6 a9 82 74 65 54 f8 4e 72 b9 f0 02 80
01c0 a3 20 a0 81 42 92 3c 23 c8 83 42 3f f9 49 82 7f
01d0 29 bb ac dc 1c cd b0 49 38 ce 60 98 c9 5b a6 b3
01e0 25 28 f4 ef 78 ee d7 78 b2 e1 22 dd fd 1c bd d1
01f0 1d 1c 0a 67 83 e0 11 fc 53 6d 63 d0 53 26 06 37
Ciphertext
0000 72 ef c1 eb fe 1e e2 59 75 a6 eb 3a a8 58 9d da
0010 2b 26 1f 1c 85 bd ab 44 2a 9e 5b 2d d1 d7 c3 95
0020 7a 16 fc 08 e5 26 d4 b1 22 3f 1b 12 32 a1 1a f2
0030 74 c3 d7 0d ac 57 f8 3e 09 83 c4 98 f1 a6 f1 ae
0040 cb 02 1c 3e 70 08 5a 1e 52 7f 1c e4 1e e5 91 1a
0050 82 02 01 61 52 9c d8 27 73 76 2d af 54 59 de 94
0060 a0 a8 2a da e7 e1 70 3c 80 85 43 c2 9e d6 fb 32
0070 d9 e0 04 32 7c 13 55 18 0c 99 5a 07 74 14 93 a0
0080 9c 21 ba 01 a3 87 88 2d a4 f6 25 34 b8 7b b1 5d
0090 60 d1 97 20 1c 0f d3 bf 30 c1 50 0a 3e cf ec dd
00a0 66 d8 72 1f 90 bc c4 c1 7e e9 25 c6 1b 0a 03 72
00b0 7a 9c 0d 5f 5c a4 62 fb fa 0a f1 c2 51 3a 9d 9d
00c0 4b 53 45 bd 27 a5 f6 e6 53 f7 51 69 3e 6b 6a 2b
00d0 8e ad 57 d5 11 e0 0e 58 c4 5b 7b 8d 00 5a f7 92
00e0 88 f5 c7 c2 2f d4 f1 bf 7a 89 8b 03 a5 63 4c 6a
00f0 1a e3 f9 fa e5 de 4f 29 6a 28 96 b2 3e 7e d4 3e
0100 d1 4f a5 a2 80 3f 4d 28 f0 d3 ff cf 24 75 76 77
0110 ae bd b4 7b b3 88 37 87 08 94 8a 8d 41 26 ed 18
0120 39 e0 da 29 a5 37 a8 c1 98 b3 c6 6a b0 07 12 dd
0130 26 16 74 bf 45 a7 3d 67 f7 69 14 f8 30 ca 01 4b
0140 65 59 6f 27 e4 cf 62 de 66 12 5a 55 66 df 99 75
0150 15 56 28 b4 00 fb fb 3a 29 04 0e d5 0f af fd bb
0160 18 ae ce 7c 5c 44 69 32 60 aa b3 86 c0 a3 7b 11
0170 b1 14 f1 c4 15 ae bb 65 3b e4 68 17 94 28 d4 3a
0180 4d 8b c3 ec 38 81 3e ca 30 a1 3c f1 bb 18 d5 24
0190 f1 99 2d 44 d8 b1 a4 2e a3 0b 22 e6 c9 5b 19 9d
01a0 8d 18 2f 88 40 b0 9d 05 95 85 c3 1a d6 91 fa 06
01b0 19 ff 03 8a ca 2c 39 a9 43 42 11 57 36 17 17 c4
01c0 9d 32 20 28 a7 46 48 11 3b d8 c9 d7 ec 77 cf 3c
01d0 89 c1 ec 87 18 ce ff 85 16 d9 6b 34 c3 c6 14 f1
01e0 06 99 c9 ab c4 ed 04 11 50 62 23 be a1 6a f3 5c
01f0 88 3a cc db e1 10 4e ef 0c fd b5 4e 12 fb 23 0a

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
IV
0000 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 72 ef c1 eb fe 1e e2 59 75 a6 eb 3a a8 58 9d da
0010 2b 26 1f 1c 85 bd ab 44 2a 9e 5b 2d d1 d7 c3 95
0020 7a 16 fc 08 e5 26 d4 b1 22 3f 1b 12 32 a1 1a f2
0030 74 c3 d7 0d ac 57 f8 3e 09 83 c4 98 f1 a6 f1 ae
0040 cb 02 1c 3e 70 08 5a 1e 52 7f 1c e4 1e e5 91 1a
0050 82 02 01 61 52 9c d8 27 73 76 2d af 54 59 de 94
0060 a0 a8 2a da e7 e1 70 3c 80 85 43 c2 9e d6 fb 32
0070 d9 e0 04 32 7c 13 55 18 0c 99 5a 07 74 14 93 a0
0080 9c 21 ba 01 a3 87 88 2d a4 f6 25 34 b8 7b b1 5d
0090 60 d1 97 20 1c 0f d3 bf 30 c1 50 0a 3e cf ec dd
00a0 66 d8 72 1f 90 bc c4 c1 7e e9 25 c6 1b 0a 03 72
00b0 7a 9c 0d 5f 5c a4 62 fb fa 0a f1 c2 51 3a 9d 9d
00c0 4b 53 45 bd 27 a5 f6 e6 53 f7 51 69 3e 6b 6a 2b
00d0 8e ad 57 d5 11 e0 0e 58 c4 5b 7b 8d 00 5a f7 92
00e0 88 f5 c7 c2 2f d4 f1 bf 7a 89 8b 03 a5 63 4c 6a
00f0 1a e3 f9 fa e5 de 4f 29 6a 28 96 b2 3e 7e d4 3e
0100 d1 4f a5 a2 80 3f 4d 28 f0 d3 ff cf 24 75 76 77
0110 ae bd b4 7b b3 88 37 87 08 94 8a 8d 41 26 ed 18
0120 39 e0 da 29 a5 37 a8 c1 98 b3 c6 6a b0 07 12 dd
0130 26 16 74 bf 45 a7 3d 67 f7 69 14 f8 30 ca 01 4b
0140 65 59 6f 27 e4 cf 62 de 66 12 5a 55 66 df 99 75
0150 15 56 28 b4 00 fb fb 3a 29 04 0e d5 0f af fd bb
0160 18 ae ce 7c 5c 44 69 32 60 aa b3 86 c0 a3 7b 11
0170 b1 14 f1 c4 15 ae bb 65 3b e4 68 17 94 28 d4 3a
0180 4d 8b c3 ec 38 81 3e ca 30 a1 3c f1 bb 18 d5 24
0190 f1 99 2d 44 d8 b1 a4 2e a3 0b 22 e6 c9 5b 19 9d
01a0 8d 18 2f 88 40 b0 9d 05 95 85 c3 1a d6 91 fa 06
01b0 19 ff 03 8a ca 2c 39 a9 43 42 11 57 36 17 17 c4
01c0 9d 32 20 28 a7 46 48 11 3b d8 c9 d7 ec 77 cf 3c
01d0 89 c1 ec 87 18 ce ff 85 16 d9 6b 34 c3 c6 14 f1
01e0 06 99 c9 ab c4 ed 04 11 50 62 23 be a1 6a f3 5c
01f0 88 3a cc db e1 10 4e ef 0c fd b5 4e 12 fb 23 0a
Ciphertext
0000 32 60 ae 8d ad 1f 4a 32 c5 ca fe 3a b0 eb 95 54
0010 9d 46 1a 67 ce b9 e5 aa 2d 3a fb 62 de ce 05 53
0020 19 3b a5 0c 75 be 25 1e 08 d1 d0 8f 10 88 57 6c
0030 7e fd fa af 3f 45 95 59 57 1e 12 51 17 53 b0 7a
0040 f0 73 f3 5d a0 6a f0 ce 0b bf 6b 8f 5c cc 5c ea
0050 50 0e c1 b2 11 bd 51 f6 3b 60 6b f6 52 87 96 ca
0060 12 17 3b a3 9b 89 35 ee 44 cc ce 64 6f 90 a4 5b
0070 f9 cc c5 67 f0 ac e1 3d c2 d5 3e be ed c8 1f 58
0080 b2 e4 11 79 dd df 0d 5a 5c 42 f5 d8 50 6c 1a 5d
0090 2f 8f 59 f3 ea 87 3c bc d0 ee c1 9a cb f3 25 42
00a0 3b d3 dc b8 c2 b1 bf 1d 1e ae d0 eb a7 f0 69 8e
00b0 43 14 fb eb 2f 15 66 d1 b9 25 30 08 cb cc f4 5a
00c0 2b 0d 9c 5c 9c 21 47 4f 40 76 e0 2b e2 60 50 b9
00d0 9d ee 4f d6 8a 4c f8 90 e4 96 e4 fc ae 7b 70 f9
00e0 4e a5 a9 06 2d a0 da eb a1 99 3d 2c cd 1d d3 c2
00f0 44 b8 42 88 01 49 5a 58 b2 16 54 7e 7e 84 7c 46
0100 d1 d7 56 37 7b 62 42 d2 e5 fb 83 bf 75 2b 54 e0
0110 df 71 e8 89 f3 a2 bb 0f 4c 10 80 5b f3 c5 90 37
0120 6e 3c 24 e2 2f f5 7f 7f a9 65 57 73 75 32 5c ea
0130 5d 92 0d b9 4b 9c 33 6b 45 5f 6e 89 4c 01 86 6f
0140 e9 fb b8 c8 d3 f7 0a 29 57 28 5f 6d fb 5d cd 8c
0150 bf 54 78 2f 8f e7 76 6d 47 23 81 99 13 ac 77 34
0160 21 e3 a3 10 95 86 6b ad 22 c8 6a 60 36 b2 51 8b
0170 20 59 b4 22 9d 18 c8 c2 cc bd f9 06 c6 cc 6e 82
0180 46 4e e5 7b dd b0 be bc b1 dc 64 53 25 bf b3 e6
0190 65 ef 72 51 08 2c 88 eb b1 cf 20 3b d7 79 fd d3
01a0 86 75 71 3c 8d aa dd 17 e1 ca be e4 32 b0 97 87
01b0 b6 dd f3 30 4e 38 b7 31 b4 5d f5 df 51 b7 8f cf
01c0 b3 d3 24 66 02 8d 0b a3 65 55 e7 e1 1a b0 ee 06
01d0 66 06 1d 16 45 d9 62 44 4b c4 7a 38 18 89 30 a8
01e0 4b 4d 56 13 95 c7 3c 08 70 21 92 7c a6 38 b7 af
01f0 c8 a8 67 9c cb 84 c2 65 55 44 0e c7 f1 04 45 cd

Testing cipher AES-256-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 62 49 77 57 24 70 93 69 99 59 57 49 66 96 76 27
0020 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
0030 02 88 41 97 16 93 99 37 51 05 82 09 74 94 45 92
IV
0000 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 1c 3b 3a 10 2f 77 03 86 e4 83 6c 99 e3 70 cf 9b
0010 ea 00 80 3f 5e 48 23 57 a4 ae 12 d4 14 a3 e6 3b
0020 5d 31 e2 76 f8 fe 4a 8d 66 b3 17 f9 ac 68 3f 44
0030 68 0a 86 ac 35 ad fc 33 45 be fe cb 4b b1 88 fd
0040 57 76 92 6c 49 a3 09 5e b1 08 fd 10 98 ba ec 70
0050 aa a6 69 99 a7 2a 82 f2 7d 84 8b 21 d4 a7 41 b0
0060 c5 cd 4d 5f ff 9d ac 89 ae ba 12 29 61 d0 3a 75
0070 71 23 e9 87 0f 8a cf 10 00 02 08 87 89 14 29 ca
0080 2a 3e 7a 7d 7d f7 b1 03 55 16 5c 8b 9a 6d 0a 7d
0090 e8 b0 62 c4 50 0d c4 cd 12 0c 0f 74 18 da e3 d0
00a0 b5 78 1c 34 80 3f a7 54 21 c7 90 df e1 de 18 34
00b0 f2 80 d7 66 7b 32 7f 6c 8c d7 55 7e 12 ac 3a 0f
00c0 93 ec 05 c5 2e 04 93 ef 31 a1 2d 3d 92 60 f7 9a
00d0 28 9d 6a 37 9b c7 0c 50 84 14 73 d1 a8 cc 81 ec
00e0 58 3e 96 45 e0 7b 8d 96 70 65 5b a5 bb cf ec c6
00f0 dc 39 66 38 0a d8 fe cb 17 b6 ba 02 46 9a 02 0a
0100 84 e1 8e 8f 84 25 20 70 c1 3e 9f 1f 28 9b e5 4f
0110 bc 48 14 57 77 8f 61 60 15 e1 32 7a 02 b1 40 f1
0120 50 5e b3 09 32 6d 68 37 8f 83 74 59 5c 84 9d 84
0130 f4 c3 33 ec 44 23 88 51 43 cb 47 bd 71 c5 ed ae
0140 9b e6 9a 2f fe ce b1 be c9 de 24 4f be 15 99 2b
0150 11 b7 7c 04 0f 12 bd 8f 6a 97 5a 44 a0 f9 0c 29
0160 a9 ab c3 d4 d8 93 92 72 84 c5 87 54 cc e2 94 52
0170 9f 86 14 dc d2 ab a9 91 92 5f ed c4 ae 74 ff ac
0180 6e 33 3b 93 eb 4a ff 04 79 da 9a 41 0e 44 50 e0
0190 dd 7a e4 c6 e2 91 09 00 57 5d a4 01 fc 07 05 9f
01a0 64 5e 8b 7e 9b fd ef 33 94 30 54 ff 84 01 14 93
01b0 c2 7b 34 29 ea ed b4 ed 53 76 44 1a 77 ed 43 85
01c0 1a d7 7f 16 f5 41 df d2 69 d5 0d 6a 5f 14 fb 0a
01d0 ab 1c bb 4c 15 50 be 97 f7 ab 40 66 19 3c 4c aa
01e0 77 3d ad 38 01 4b d2 09 2f a7 55 c8 24 bb 5e 54
01f0 c4 f3 6f fd a9 fc ea 70 b9 c6 e6 93 e1 48 c1 51

Testing cipher AES-256-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 62 49 77 57 24 70 93 69 99 59 57 49 66 96 76 27
0020 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
0030 02 88 41 97 16 93 99 37 51 05 82 09 74 94 45 92
IV
0000 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 77 a3 12 51 61 8a 15 e6 b9 2d 1d 66 df fe 7b 50
0010 b5 0b ad 55 23 05 ba 02 17 a6 10 68 8e ff 7e 11
0020 e1 d0 22 54 38 e0 93 24 2d 6d b2 74 fd e8 01 d4
0030 ca e0 6f 20 92 c7 28 b2 47 85 59 df 58 e8 37 c2
0040 46 9e e4 a4 fa 79 4e 4b bc 7f 39 bc 02 6e 3c b7
0050 2c 33 b0 88 8f 25 b4 ac f5 6a 2a 98 04 f1 ce 6d
0060 3d 6e 1d c6 ca 18 1d 4b 54 61 79 d5 55 44 aa 77
0070 60 c4 0d 06 74 15 39 c7 e3 cd 9d 2f 66 50 b2 01
0080 3f d0 ee b8 c2 b8 e3 d8 d2 40 cc ae 2d 4c 98 32
0090 0a 74 42 e1 c8 d7 5a 42 d6 e6 cf a4 c2 ec a1 79
00a0 8d 15 8c 7a ec df 82 49 0f 24 bb 9b 38 e1 08 bc
00b0 da 12 c3 fa f9 a2 11 41 c3 61 3b 58 36 7f 92 2a
00c0 aa 26 cd 22 f2 3d 70 8d ae 69 9a d7 cb 40 a8 ad
00d0 0b 6e 27 84 97 3d cb 60 56 84 c0 8b 8d 69 98 c6
00e0 9a ac 04 99 21 87 1e bb 65 30 1a 46 19 ca 80 ec
00f0 b4 85 a3 1d 74 42 23 ce 8d dc 23 94 82 8d 6a 80
0100 47 0c 09 2f 5b a4 13 c3 37 8f a6 05 42 55 c6 f9
0110 df 44 95 86 2b bb 32 87 68 1f 93 1b 68 7c 88 8a
0120 bf 84 4d fc 8f c2 83 31 e5 79 92 8c d1 2b d2 39
0130 0a e1 23 cf 03 81 8d 14 de dd e5 c0 c2 4c 8a b0
0140 18 bf ca 75 ca 09 6f 2d 53 1f 3d 16 19 e7 85 f1
0150 ad a4 37 ca b9 2e 98 05 58 b3 dc e1 47 4a fb 75
0160 bf ed bf 8f f5 4c b2 61 8e 02 44 c9 ac 0d 3c 66
0170 fb 51 59 8c d2 db 11 f9 be 39 79 1a be 44 7c 63
0180 09 4f 7c 45 3b 7f f8 7c b5 bb 36 b7 c7 9e fb 08
0190 72 d1 70 58 b8 3b 15 ab 08 66 ad 8a 58 65 6c 5a
01a0 7e 20 db df 30 8b 24 61 d9 7c 0e c0 02 4a 27 15
01b0 05 52 49 cf 3b 47 8d dd 47 40 de 65 4f 75 ca 68
01c0 6e 0d 73 45 c6 9e d5 0c dc 2a 8b 33 2b 1f 88 24
01d0 10 8a c9 37 eb 05 05 85 60 8e e7 34 09 7f c0 90
01e0 54 fb ff 89 ee ae ea 79 1f 4a 7a b1 f9 86 82 94
01f0 a4 f9 e2 7b 42 af 81 00 cb 9d 59 ce f9 64 58 03

Testing cipher AES-256-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 62 49 77 57 24 70 93 69 99 59 57 49 66 96 76 27
0020 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
0030 02 88 41 97 16 93 99 37 51 05 82 09 74 94 45 92
IV
0000 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 e3 87 aa a5 8b a4 83 af a7 e8 eb 46 97 78 31 7e
0010 cf 4c f5 73 aa 9d 4e ac 23 f2 cd f9 14 e4 e2 00
0020 a8 b4 90 e4 2e e6 46 80 2d c6 ee 2b 47 1b 27 81
0030 95 d6 09 18 ec ec b4 4b f7 99 66 f8 3f ab a0 49
0040 92 98 eb c6 99 c0 c8 63 47 15 a3 20 bb 4f 07 5d
0050 62 2e 74 c8 c9 32 00 4f 25 b4 1e 36 10 25 b5 a8
0060 78 15 39 1f 61 08 fc 4a fa 6a 05 d9 30 3c 6b a6
0070 8a 12 8a 55 70 5d 41 59 85 83 2f de aa e6 c8 e1
0080 91 10 e8 4d 1b 1f 19 9a 26 92 11 9e dc 96 13 26
0090 58 f0 9d a7 c6 23 ef ce c7 12 53 7a 3d 94 c0 bf
00a0 5d 7e 35 2e c9 4a e5 79 7f db 37 7d c1 55 11 50
00b0 72 1a df 15 bd 26 a8 ef c2 fc aa d5 68 81 fa 9e
00c0 62 46 2c 28 f3 0a e1 ce ac a9 3c 34 5c f2 43 b7
00d0 3f 54 2e 20 74 a7 05 bd 26 43 bb 9f 7c c7 9b b6
00e0 e7 09 1e a6 e2 32 df 0f 9a d0 d6 cf 50 23 27 87
00f0 6d 82 20 7a bf 21 15 cd ac f6 d5 a4 8f 6c 18 79
0100 a6 5b 11 5f 0f 8b 3c b3 c5 9d 15 dd 8c 76 9b c0
0110 14 79 5a 18 37 f3 90 1b 58 45 eb 49 1a df ef e0
0120 97 b1 fa 30 a1 2f c1 f6 5b a2 29 05 03 15 39 97
0130 1a 10 f2 f3 6c 32 1b b5 13 31 cd ef b3 9e 39 64
0140 c7 ef 07 99 94 f5 b6 9b 2e dd 83 a7 1e f5 49 97
0150 1e e9 3f 44 ea c3 93 8f cd d6 1d 01 fa 71 79 9d
0160 a3 a8 09 1c 4c 48 aa 9e d2 63 ff 07 49 df 95 d4
0170 4f ef 6a 0b b5 78 ec 69 45 6a a5 40 8a e3 2c 7a
0180 f0 8a d7 ba 89 21 28 7e 3b be e3 1b 76 7b e0 6a
0190 0e 70 5c 86 4a 76 91 37 df 28 29 22 83 ea 81 a2
01a0 48 02 41 b4 4d 99 21 cd be c1 bc 28 dc 1f da 11
01b0 4b d8 e5 21 7a c9 d8 eb af a7 20 e9 da 4f 9a ce
01c0 23 1c c9 49 e5 b9 6f e7 6f fc 21 06 3f dd c8 3a
01d0 6b 86 79 c0 0d 35 e0 95 76 a8 75 30 5b ed 5f 36
01e0 ed 24 2c 89 00 dd 1f a9 65 bc 95 0d fc e0 9b 13
01f0 22 63 a1 ee f5 2d d6 88 8c 30 9f 5a 7d 71 28 26

Testing cipher AES-256-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 62 49 77 57 24 70 93 69 99 59 57 49 66 96 76 27
0020 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
0030 02 88 41 97 16 93 99 37 51 05 82 09 74 94 45 92
IV
0000 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 bf 53 d2 da de 78 e8 22 a4 d9 49 a9 bc 67 66 b0
0010 1b 06 a8 ef 70 d2 67 48 c6 a7 fc 36 d8 0a e4 c5
0020 52 0f 7c 4a b0 ac 85 44 42 4f a4 05 16 2f ef 5a
0030 6b 7f 22 94 98 06 36 18 d3 9f 00 03 cb 5f b8 d1
0040 c8 6b 64 34 97 da 1f f9 45 c8 d3 be de ca 4f 47
0050 97 02 a7 a7 35 f0 43 dd b1 d6 aa ad e3 c4 a0 ac
0060 7c a7 f3 fa 52 79 be f5 6f 82 cd 7a 2f 38 67 2e
0070 82 48 14 e1 07 00 30 0a 05 5e 16 30 b8 f1 cb 0e
0080 91 9f 5e 94 20 10 a4 16 e2 bf 48 cb 46 99 3d 3c
0090 b6 a5 1c 19 ba cf 86 47 85 a0 0b c2 ec ff 15 d3
00a0 50 87 5b 24 6e d5 3e 68 be 6f 55 bd 7e 05 cf c2
00b0 b2 ed 64 32 19 8a 64 44 b6 d8 c2 47 fa b9 41 f5
00c0 69 76 8b 5c 42 93 66 f1 d3 f0 0f 03 45 b9 61 23
00d0 d5 62 04 c0 1c 63 b2 2c e7 8b af 11 6e 52 5e d9
00e0 0f de a3 9f a4 69 49 4d 38 66 c3 1e 05 f2 95 ff
00f0 21 fe a8 d4 e6 e1 3d 67 e4 7c e7 22 e9 69 8a 1c
0100 10 48 d6 8e bc de 76 b8 6f cf 97 6e ab 8a a9 79
0110 02 68 b7 06 8e 01 7a 8b 9b 74 94 09 51 4f 10 53
0120 02 7f d1 6c 37 86 ea 1b ac 5f 15 cb 79 71 1e e2
0130 ab e8 2f 5c f8 b1 3a e7 30 30 ef 5b 9e 44 57 e7
0140 5d 13 04 f9 88 d6 2d d6 fc 4b 94 ed 38 ba 83 1d
0150 a4 b7 63 49 71 b6 cd 8e c3 25 d9 c6 1c 00 f1 df
0160 73 62 7e d3 74 5a 5e 84 89 f3 a9 5c 69 63 9c 32
0170 cd 6e 1d 53 7a 85 f7 5c c8 44 72 6e 8a 72 fc 00
0180 77 ad 22 00 0f 1d 50 78 f6 b8 66 31 8c 66 8f 1a
0190 d0 3d 5a 5f ce d5 21 9f 2e ab bd 0a a5 c0 f4 60
01a0 d1 83 f0 44 04 a0 d6 f4 69 55 8e 81 fa b2 4a 16
01b0 79 05 ab 4c 78 78 50 2a d3 e3 8f db e6 2a 41 55
01c0 6c ec 37 32 57 59 53 3c e8 f2 5f 36 7c 87 bb 55
01d0 78 d6 67 ae 93 f9 e2 fd 99 bc bc 5f 2f bb a8 8c
01e0 f6 51 61 39 42 0f cf f3 b7 36 1d 86 32 2c 4b d8
01f0 4c 82 f3 35 ab b1 52 c4 a9 34 11 37 3a aa 82 20

Testing cipher AES-256-XTS(encrypt/decrypt)
Key
0000 27 18 28 18 28 45 90 45 23 53 60 28 74 71 35 26
0010 62 49 77 57 24 70 93 69 99 59 57 49 66 96 76 27
0020 31 41 59 26 53 58 97 93 23 84 62 64 33 83 27 95
0030 02 88 41 97 16 93 99 37 51 05 82 09 74 94 45 92
IV
0000 ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 64 49 7e 5a 83 1e 4a 93 2c 09 be 3e 53 93 37 6d
0010 aa 59 95 48 b8 16 03 1d 22 4b bf 50 a8 18 ed 23
0020 50 ea e7 e9 60 87 c8 a0 db 51 ad 29 0b d0 0c 1a
0030 c1 62 08 57 63 5b f2 46 c1 76 ab 46 3b e3 0b 80
0040 8d a5 48 08 1a c8 47 b1 58 e1 26 4b e2 5b b0 91
0050 0b bc 92 64 71 08 08 94 15 d4 5f ab 1b 3d 26 04
0060 e8 a8 ef f1 ae 40 20 cf a3 99 36 b6 68 27 b2 3f
0070 37 1b 92 20 0b e9 02 51 e6 d7 3c 5f 86 de 5f d4
0080 a9 50 78 19 33 d7 9a 28 27 2b 78 2a 2e c3 13 ef
0090 df cc 06 28 f4 3d 74 4c 2d c2 ff 3d cb 66 99 9b
00a0 50 c7 ca 89 5b 0c 64 79 1e ea a5 f2 94 99 fb 1c
00b0 02 6f 84 ce 5b 5c 72 ba 10 83 cd db 5c e4 54 34
00c0 63 16 65 c3 33 b6 0b 11 59 3f b2 53 c5 17 9a 2c
00d0 8d b8 13 78 2a 00 48 56 a1 65 30 11 e9 3f b6 d8
00e0 76 c1 83 66 dd 86 83 f5 34 12 c0 c1 80 f9 c8 48
00f0 59 2d 59 3f 86 09 ca 73 63 17 d3 56 e1 3e 2b ff
0100 3a 9f 59 cd 9a eb 19 cd 48 25 93 d8 c4 61 28 bb
0110 32 42 3b 37 a9 ad fb 48 2b 99 45 3f be 25 a4 1b
0120 f6 fe b4 aa 0b ef 5e d2 4b f7 3c 76 29 78 02 54
0130 82 c1 31 15 e4 01 5a ac 99 2e 56 13 a3 b5 c2 f6
0140 85 b8 47 95 cb 6e 9b 26 56 d8 c8 81 57 e5 2c 42
0150 f9 78 d8 63 4c 43 d0 6f ea 92 8f 28 22 e4 65 aa
0160 65 76 e9 bf 41 93 84 50 6c c3 ce 3c 54 ac 1a 6f
0170 67 dc 66 f3 b3 01 91 e6 98 38 0b c9 99 b0 5a bc
0180 e1 9d c0 c6 dc c2 dd 00 1e c5 35 ba 18 de b2 df
0190 1a 10 10 23 10 83 18 c7 5d c9 86 11 a0 9d c4 8a
01a0 0a cd ec 67 6f ab df 22 2f 07 e0 26 f0 59 b6 72
01b0 b5 6e 5c bc 8e 1d 21 bb d8 67 dd 92 72 12 05 46
01c0 81 d7 0e a7 37 13 4c df ce 93 b6 f8 2a e2 24 23
01d0 27 4e 58 a0 82 1c c5 50 2e 2d 0a b4 58 5e 94 de
01e0 69 75 be 5e 0b 4e fc e5 1c d3 e7 0c 25 a1 fb bb
01f0 d6 09 d2 73 ad 5b 0d 59 63 1c 53 1f 6a 0a 57 b9

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
0010 bf be bd bc bb ba b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
IV
0000 9a 78 56 34 12 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10
Ciphertext
0000 6c 16 25 db 46 71 52 2d 3d 75 99 60 1d e7 ca 09
0010 ed

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
0010 bf be bd bc bb ba b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
IV
0000 9a 78 56 34 12 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11
Ciphertext
0000 d0 69 44 4b 7a 7e 0c ab 09 e2 44 47 d2 4d eb 1f
0010 ed bf

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
0010 bf be bd bc bb ba b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
IV
0000 9a 78 56 34 12 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12
Ciphertext
0000 e5 df 13 51 c0 54 4b a1 35 0b 33 63 cd 8e f4 be
0010 ed bf 9d

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
0010 bf be bd bc bb ba b9 b8 b7 b6 b5 b4 b3 b2 b1 b0
IV
0000 9a 78 56 34 12 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13
Ciphertext
0000 9d 84 c8 13 f7 19 aa 2c 7b e3 f6 61 71 c7 c5 c2
0010 ed bf 9d ac

Testing cipher AES-128-XTS(encrypt/decrypt)
Key
0000 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
0010 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
IV
0000 21 43 65 87 a9 00 00 00 00 00 00 00 00 00 00 00
Plaintext
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
00a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
00b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
00c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
00d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
00e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
00f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
0100 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0110 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
0120 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
0130 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
0140 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
0150 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
0160 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
0170 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
0180 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f
0190 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f
01a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af
01b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
01c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
01d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df
01e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef
01f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff
Ciphertext
0000 38 b4 58 12 ef 43 a0 5b d9 57 e5 45 90 7e 22 3b
0010 95 4a b4 aa f0 88 30 3a d9 10 ea df 14 b4 2b e6
0020 8b 24 61 14 9d 8c 8b a8 5f 99 2b e9 70 bc 62 1f
0030 1b 06 57 3f 63 e8 67 bf 58 75 ac af a0 4e 42 cc
0040 bd 7b d3 c2 a0 fb 1f ff 79 1e c5 ec 36 c6 6a e4
0050 ac 1e 80 6d 81 fb f7 09 db e2 9e 47 1f ad 38 54
0060 9c 8e 66 f5 34 5d 7c 1e b9 4f 40 5d 1e c7 85 cc
0070 6f 6a 68 f6 25 4d d8 33 9f 9d 84 05 7e 01 a1 77
0080 41 99 04 82 99 95 16 b5 61 1a 38 f4 1b b6 47 8e
0090 6f 17 3f 32 08 05 dd 71 b1 93 2f c3 33 cb 9e e3
00a0 99 36 be ea 9a d9 6f a1 0f b4 11 2b 90 17 34 dd
00b0 ad 40 bc 18 78 99 5f 8e 11 ae e7 d1 41 a2 f5 d4
00c0 8b 7a 4e 1e 7f 0b 2c 04 83 0e 69 a4 fd 13 78 41
00d0 1c 2f 28 7e df 48 c6 c4 e5 c2 47 a1 96 80 f7 fe
00e0 41 ce fb d4 9b 58 21 06 e3 61 6c bb e4 df b2 34
00f0 4b 2a e9 51 93 91 f3 e0 fb 49 22 25 4b 1d 6d 2d
0100 19 c6 d4 d5 37 b3 a2 6f 3b cc 51 58 8b 32 f3 ec
0110 a0 82 9b 6a 5a c7 25 78 fb 81 4f b4 3c f8 0d 64
0120 a2 33 e3 f9 97 a3 f0 26 83 34 2f 2b 33 d2 5b 49
0130 25 36 b9 3b ec b2 f5 e1 a8 b8 2f 5b 88 33 42 72
0140 9e 8a e0 9d 16 93 88 41 a2 1a 97 fb 54 3e ea 3b
0150 bf f5 9f 13 c1 a1 84 49 e3 98 70 1c 1a d5 16 48
0160 34 6c bc 04 c2 7b b2 da 3b 93 a1 37 2c ca e5 48
0170 fb 53 be e4 76 f9 e9 c9 17 73 b1 bb 19 82 83 94
0180 d5 5d 3e 1a 20 ed 69 11 3a 86 0b 68 29 ff a8 47
0190 22 46 04 43 50 70 22 1b 25 7e 8d ff 78 36 15 d2
01a0 ca e4 80 3a 93 aa 43 34 ab 48 2a 0a fa c9 c0 ae
01b0 da 70 b4 5a 48 1d f5 de c5 df 8c c0 f4 23 c7 7a
01c0 5f d4 6c d3 12 02 1d 4b 43 88 62 41 9a 79 1b e0
01d0 3b b4 d9 7c 0e 59 57 85 42 53 1b a4 66 a8 3b af
01e0 92 ce fc 15 1b 5c c1 61 1a 16 78 93 81 9b 63 fb
01f0 8a 6b 18 e8 6d e6 02 90 fa 72 b7 97 b0 ce 59 f3

Testing cipher id-aes128-wrap(encrypt/decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 1f a6 8b 0a 81 12 b4 47 ae f3 4b d8 fb 5a 7b 82
0010 9d 3e 86 23 71 d2 cf e5

Testing cipher id-aes192-wrap(encrypt/decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 96 77 8b 25 ae 6c a4 35 f9 2b 5b 97 c0 50 ae d2
0010 46 8a b8 a1 7a d8 4e 5d

Testing cipher id-aes256-wrap(encrypt/decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
Ciphertext
0000 64 e8 c3 f9 ce 0f 5b a2 63 e9 77 79 05 81 8a 2a
0010 93 c8 19 1e 7d 6e 8a e7

Testing cipher id-aes192-wrap(encrypt/decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
0010 00 01 02 03 04 05 06 07
Ciphertext
0000 03 1d 33 26 4e 15 d3 32 68 f2 4e c2 60 74 3e dc
0010 e1 c6 c7 dd ee 72 5a 93 6b a8 14 91 5c 67 62 d2

Testing cipher id-aes256-wrap(encrypt/decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
0010 00 01 02 03 04 05 06 07
Ciphertext
0000 a8 f9 bc 16 12 c6 8b 3f f6 e6 f4 fb e3 0e 71 e4
0010 76 9c 8b 80 a3 2c b8 95 8c d5 d1 7d 6b 25 4d a1

Testing cipher id-aes256-wrap(encrypt/decrypt)
Key
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
Plaintext
0000 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
0010 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
Ciphertext
0000 28 c9 f4 04 c4 b8 10 f4 cb cc b3 5c fb 87 f8 26
0010 3f 57 86 e2 d8 0e d3 26 cb c7 f0 e7 1a 99 f4 3b
0020 fb 98 8b 9b 7a 02 dd 21

../util/shlib_wrap.sh ./evp_extra_test
PASS
test SSL protocol
../util/shlib_wrap.sh ./ssltest -test_cipherlist
Testing cipherlist order only. Ignoring all other options.
testing SSLv3 cipher list order: ok
testing TLSv1 cipher list order: ok
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaac8 a cert? 0x0x801b08540
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaad8 a cert? 0x0x801b08700
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 2048 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 2048 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 2048 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.04 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.03 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 2048 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
Testing a lot of proxy conditions.
Some of them may turn out being invalid, which is fine.
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b087e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.04 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.04 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = A
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b087e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.02 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.05 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b087e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.03 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.02 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.03 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b087e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.03 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.02 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.04 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
Proxy rights check with condition 'A|B&!C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b087e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.02 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.03 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=2 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa68 a cert? 0x0x801b087e0
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.02 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.03 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
Testing a lot of proxy conditions.
Some of them may turn out being invalid, which is fine.
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = A
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = A
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A|B&!C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08e00
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.04 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.04 s
Approximate total client time:   0.02 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = B
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08e00
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.03 s
Approximate total client time:   0.02 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.04 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'B' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = C
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = none
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = none
Proxy rights check with condition 'A|B&!C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'B' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa88 a cert? 0x0x801b08e00
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.04 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.04 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'C' proved invalid
ERROR in CLIENT
34383504648:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
SSLv3, cipher (NONE) (NONE)
1 handshakes of 256 bytes done
test sslv2
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication
Testing was requested for a disabled protocol. Skipping tests.
test sslv3
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2 via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with client authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv2 with both client and server authentication via BIO pair
Testing was requested for a disabled protocol. Skipping tests.
test sslv3 via BIO pair
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with server authentication via BIO pair
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1
Available compression methods:
  1: zlib compression
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2
Available compression methods:
  1: zlib compression
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with client authentication
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test dtlsv1.2 with both client and server authentication
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
DTLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 w/o (EC)DHE via BIO pair
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with 1024bit DHE via BIO pair
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with server authentication
Available compression methods:
  1: zlib compression
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with client authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair
Available compression methods:
  1: zlib compression
client authentication
server authentication
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
  Initial proxy rights = BC
depth=3 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=2 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1
  Certificate proxy rights = AB, resulting proxy rights = B
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
  Certificate proxy rights = BC, resulting proxy rights = B
Proxy rights check with condition 'A|B&!C' proved valid
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
test sslv2/sslv3 with both client and server authentication via BIO pair and app verify
Available compression methods:
  1: zlib compression
client authentication
server authentication
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa68 a cert? 0x0x801b08a80
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
In app_verify_callback, allowing cert. Arg is: Test Callback Argument
Finished printing do we have a context? 0x0x7fffffffaa78 a cert? 0x0x801b08e00
cert depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2/CN=Proxy 1/CN=Proxy 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites
Testing ciphersuites for TLSv1.2
Testing AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 NULL-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES256-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
TLSv1.2, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-GCM-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES256-SHA384
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-GCM-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-GCM-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA256
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA256, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ciphersuites for SSLv3
Testing AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing IDEA-CBC-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 IDEA-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing RC4-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 RC4-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing NULL-MD5
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 NULL-MD5, 1024 bit RSA
1 handshakes of 256 bytes done
dh
Testing DHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-SEED-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-SEED-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing DHE-RSA-CAMELLIA128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing EDH-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
testing connection with weak DH, expecting failure
Available compression methods:
  1: zlib compression
ERROR in CLIENT
34383504648:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3613:
SSLv3, cipher (NONE) (NONE), 1024 bit RSA
1 handshakes of 256 bytes done
ec
Testing ECDHE-RSA-AES256-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-AES128-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES128-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-RC4-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-RC4-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-DES-CBC3-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-DES-CBC3-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Testing ECDHE-RSA-NULL-SHA
Available compression methods:
  1: zlib compression
SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-NULL-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA
10 handshakes of 256 bytes done
Approximate total server time:   0.02 s
Approximate total client time:   0.02 s
rsa
test tls1 with 1024bit RSA, no (EC)DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.04 s
Approximate total client time:   0.01 s
dh
test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
Available compression methods:
  1: zlib compression
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
10 handshakes of 256 bytes done
Approximate total server time:   0.01 s
Approximate total client time:   0.04 s
test tls1 with PSK
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with PSK via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 PSK-AES256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with custom extensions
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with serverinfo
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Servername 2 is NULL
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
Available compression methods:
  1: zlib compression
Switching server context.
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
1 handshakes of 256 bytes done
srp
test tls1 with SRP
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-RSA-AES-256-CBC-SHA, 1024 bit RSA
1 handshakes of 256 bytes done
test tls1 with SRP auth
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
test tls1 with SRP auth via BIO pair
Available compression methods:
  1: zlib compression
TLSv1, cipher TLSv1/SSLv3 SRP-AES-256-CBC-SHA
1 handshakes of 256 bytes done
rsa
Setting up TSA test directory...
Creating CA for TSA tests...
Creating a new CA for the TSA tests...
Generating a 1024 bit RSA private key
....++++++
......++++++
writing new private key to 'tsacakey.pem'
-----
Creating tsa_cert1.pem TSA server cert...
Generating a 1024 bit RSA private key
............++++++
...++++++
writing new private key to 'tsa_key1.pem'
-----
Using extension tsa_cert
Signature ok
subject=/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Getting CA Private Key
Creating tsa_cert2.pem non-TSA server cert...
Generating a 1024 bit RSA private key
...........................++++++
...............++++++
writing new private key to 'tsa_key2.pem'
-----
Using extension non_tsa_cert
Signature ok
subject=/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa2
Getting CA Private Key
Creating req1.req time stamp request for file testtsa...
Using configuration from ../CAtsa.cnf
Printing req1.req...
Using configuration from ../CAtsa.cnf
Version: 1
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Policy OID: tsa_policy1
Nonce: 0xABDAC649DBF22286
Certificate required: yes
Extensions:
Generating valid response for req1.req...
Using configuration from ../CAtsa.cnf
Warning: could not open file ./tsa_serial for reading, using serial number: 1
Response has been generated.
Printing response...
Using configuration from ../CAtsa.cnf
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: tsa_policy1
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x01
Time stamp: Nov 22 07:51:32 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: 0xABDAC649DBF22286
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Verifying valid response...
Verification: OK
Verification: OK
Verifying valid token...
Using configuration from ../CAtsa.cnf
Verification: OK
Verification: OK
Creating req2.req time stamp request for file testtsa...
Using configuration from ../CAtsa.cnf
Printing req2.req...
Using configuration from ../CAtsa.cnf
Version: 1
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Policy OID: tsa_policy2
Nonce: unspecified
Certificate required: no
Extensions:
Generating valid response for req2.req...
Using configuration from ../CAtsa.cnf
Response has been generated.
Checking '-token_in' and '-token_out' options with '-reply'...
Using configuration from ../CAtsa.cnf
Using configuration from ../CAtsa.cnf
Using configuration from ../CAtsa.cnf
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x02
Time stamp: Nov 22 07:51:32 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Using configuration from ../CAtsa.cnf
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x02
Time stamp: Nov 22 07:51:32 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Using configuration from ../CAtsa.cnf
Response has been generated.
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x03
Time stamp: Nov 22 07:51:32 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Printing response...
Using configuration from ../CAtsa.cnf
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: tsa_policy2
Hash Algorithm: sha1
Message data:
    0000 - 48 44 c4 76 26 9d e5 5d-9c 67 1e 3b 0c ec b3 cd   HD.v&..].g.;....
    0010 - c5 b8 6e 67                                       ..ng
Serial number: 0x02
Time stamp: Nov 22 07:51:32 2016 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=HU/ST=Budapest/L=Buda/O=Hun-TSA Ltd./CN=tsa1
Extensions:
Verifying valid response...
Verification: OK
Verification: OK
Verifying response against wrong request, it should fail...
Verification: FAILED
34383504648:error:2F06606C:time stamp routines:TS_CHECK_POLICY:policy mismatch:ts_rsp_verify.c:595:
Ok
Verifying response against wrong request, it should fail...
Verification: FAILED
34383504648:error:2F06606C:time stamp routines:TS_CHECK_POLICY:policy mismatch:ts_rsp_verify.c:595:
Ok
Creating req3.req time stamp request for file CAtsa.cnf...
Using configuration from ../CAtsa.cnf
Printing req3.req...
Using configuration from ../CAtsa.cnf
Version: 1
Hash Algorithm: sha1
Message data:
    0000 - 1c b9 52 2b 5c 27 b0 ae-83 b8 b2 c1 6d 82 1a 7f   ..R+\'......m...
    0010 - db 63 45 e7                                       .cE.
Policy OID: unspecified
Nonce: unspecified
Certificate required: no
Extensions:
Verifying response against wrong request, it should fail...
Verification: FAILED
34383504648:error:2F064067:time stamp routines:TS_CHECK_IMPRINTS:message imprint mismatch:ts_rsp_verify.c:681:
Ok
Cleaning up...
Test IGE mode
../util/shlib_wrap.sh ./igetest
Test JPAKE
../util/shlib_wrap.sh ./jpaketest
p = F9E5B365665EA7A05A9C534502780FEE6F1AB5BD4F49947FD036DBD7E905269AF46EF28B0FC07487EE4F5D20FB3C0AF8E700F3A2FA3414970CBED44FEDFF80CE78D800F184BB82435D137AADA2C6C16523247930A63B85661D1FC817A51ACD96168E95898A1F83A79FFB529368AA7833ABD1B0C3AEDDB14D2E1A2F71D99F763F
g = 2
q = 7CF2D9B2B32F53D02D4E29A2813C07F7378D5ADEA7A4CA3FE81B6DEBF482934D7A37794587E03A43F727AE907D9E057C738079D17D1A0A4B865F6A27F6FFC0673C6C0078C25DC121AE89BD56D16360B291923C98531DC2B30E8FE40BD28D66CB0B474AC4C50FC1D3CFFDA949B4553C19D5E8D861D76ED8A6970D17B8ECCFBB1F
A->B s1
B->A s1
A->B s2
B->A s2
Alice's key = 247FC72CD18AD66702C0559EDA274CFC379750ADAD7C5AE05F285F91266ED26E761879391B0D7FCCCD592F9E77EEFBD0C0DCC873A1D3ED188FB895AD6CB93BE32CEBDB27C4C93299F47DF66E521A9FCA30A0686579C9B137925BAA42D8F4BFE60D50393D9CABF98ABE891D48025BA8D06AFBD335A23BD49122AA5EB9B3C41BD0
Bob's key   = 247FC72CD18AD66702C0559EDA274CFC379750ADAD7C5AE05F285F91266ED26E761879391B0D7FCCCD592F9E77EEFBD0C0DCC873A1D3ED188FB895AD6CB93BE32CEBDB27C4C93299F47DF66E521A9FCA30A0686579C9B137925BAA42D8F4BFE60D50393D9CABF98ABE891D48025BA8D06AFBD335A23BD49122AA5EB9B3C41BD0
A->B s3a
B->A s3b
A->B s1
B->A s1
A->B s2
B->A s2
Alice's key = C4424D352C87EE57A03F7EA6BDF237FC3900442D7A466C6FB0A11271C8CFDE7EA4156C608DD831F38EB8014AF1022012992D11AC361386FDD92AC9216633E2AA8B410A3557E01C06C334EC065E6685E1E419C2E780FAF2743F68D95320BE79C7179AA211E07F51B4A36B873118BD09F1B382A12C98EE245B0CB889630E6EE8C0
Bob's key   = 6191151168DBE6865346F9860EDC4664C0E8111804729DDECD805E9816C04FB0986FD9F72E17951E6BF8836A219799BCA6E6381CEAF41E1FCC8A28CD6D3B6B108209CAEFBBCC7ECE2746A14E8DD057D09829C662FBB380C7097527862FF7A69C4FC7D118BFECB4729219FAD9CE990CDD196C035BF583432CF7EF80DE4A38FC0B
A->B s3a
Bob fails to process Alice's step 3a
34383504648:error:3106706A:lib(49):JPAKE_STEP3A_process:hash of hash of key mismatch:jpake.c:476:
Test SRP
../util/shlib_wrap.sh ./srptest
N = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
g = 2
Salt = D684D806E0BA04331BA3B642D213619FCC304F90
Verifier = B4F74102292D33DB2806F8D7CE5A4BCE8F49A2B68540A943971C92006C01ADBDB519FC15E29D1C51B4301EC1957139EFF5CD95949D1A809787BBCA9DFF5A9120C8F138B2A157E2022983E41B7BE5C734C603393136A8B9B04E9C5D66BD8ACC019F6FEA91EDD518B49435B21D9D61A9BE1C4C80CEAB4CF27333619323F219D098
b = 2D7FAECF6C1E72D22AB5EFC2935DCF8E0164C0B2A718C662CD0B88AB03E502AB
B = 4EC5F5B445D4A6CD3C64004EA01280F8941B98CFC8E3363A9FB39626199530D381F298C85347DF9447C532A99B7C81106C5525B8EE4DE5EF4548AA7BD780B8264E915A5631AD778AEE941F952FA5B4065F5A5E0AEAD165CD4DD776618140CE65F1B7510EBCCEC10058670879726F0C27F4895E45BAC741A36E7355873E0159CF
a = AD704B67CBE09A695FBE6915E6FBF19ABD103C4CB0A935A7B4307BB99867622
A = 5CE4E15FF5DDF1E82FEC7508D053B75E87A79E310C7C4A3C23B958E782057675B52ED6CD21EF17FE8D9FE3C9B5657F81C31ACD6267CC530CD75733638E302B830628BCB4F79C896B90D07531F26E0A5EA222D6918A20A613B852D314139C8B3D28BF813D414614B4CCA7F1BAB88D7A7A060ECFD4869E9F569301B7BD1ECC9812
Client's key = 9902536C5110704C9EF1CBDB5E63413B13BCEC4E792AB4838349DCC902BA38C95405B0582F568146D51B4D9899C9671C271418DF4B09720B12520658D0F7CEA55E98093D65EBCA034ED7C68DFECDC4D8C42F22010925F57B646FC55077F04F5CABD59B991E53E347CD784E704241E3C467D693AD85E51AA8C3077D253AFC0F15
Server's key = 2173DB6B169D0B742FAFB6A531077F57F387293C15761139107EF6D141FD07A31637A455EBA9F34441F0B6377ACE8E153EEFBB22B75B3C25FAD31356184F473D36E4497CE0D09165FE734AD0118004B397BB3978C09465F023D1B695C3652C1F078784B5E02A628B0091D581A8BB911C13CC5824A47BCC5B86F6F565F30DF4
Keys mismatch
N = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
g = 2
Salt = 13FD13245F93E2A0C12016953D0847EB903B08B8
Verifier = 6D790970F6DC314DF89A7BB5BEAF8B8FA5188A377DA7A55663E92F0987F4D575E0D51219C1933F8D6A8089F045B68A6C01D9766F24E7E6F4AF92D98948644735FBE66E7FDCA31FEFEC38FE72518583926306EA9D694CA0702489F9CB287CD3F8041A476E2C065FBC77ABC1A5C5C5E16C4AEEA03C2BF7F993CE941D295E5D5A10
b = C87280B8F5BFF7A6AA956D22C46458050B342EDF1A367CF027A924263E684CB4
B = EC4DD0A0C43A7020A7CE0C6895F15BCFD11F2B97147F5232446C1B1A4BA69C05A88DFD50A03E05A9C7FC360CA6EBA4A9BF55684F1F6FBE4DF5B911FC5D19B793A86057FD019D8DA79B87369D53986982752416D1633F60F805D2EC2D7797523AEBB4C6B11CC7B8018C6C9A29AFE2AC73BF05F387E90643AAC3B3AD9D4A0970F3
a = B851954C9ED22C91F12BEE72E75443F031AA517CAA135351A08A7067C3B9EE0E
A = 26F226058EAAFD1DF76339734B435FC38B4B60488CE4DFBD7A8C399E2CFEB930CD5CDF7A68EC6E1CB9230CF0F13D18DC1F2BB7F6385C6561618AE504DB5046D6C5DC5EB7506096C1332D915D803A8D520F88EC8A260EFC4EDCCF9470ECEBDD59D06F4B39ED8EB1F253BD8A6DFDD9F03624DA5664FCE053C3080A83143021F96
Client's key = 1F9A1E3D17D659A83DA388A36AF5C5C7148647ABCB09BA3BCBBFC9DE26B4D2B4A5D9FE061CF9090C8DBA02997BC8023521E8C1E655C4D2F3864624215009114E7A7B41476E856C05B73B06A171C95B186C240D2261D2C9EC7E6FE9A4FB32ED4830B89F957C09A8068CF7A0C27C6CE3FB2018790E6A5B24100785E2A2980E428C
Server's key = 1F9A1E3D17D659A83DA388A36AF5C5C7148647ABCB09BA3BCBBFC9DE26B4D2B4A5D9FE061CF9090C8DBA02997BC8023521E8C1E655C4D2F3864624215009114E7A7B41476E856C05B73B06A171C95B186C240D2261D2C9EC7E6FE9A4FB32ED4830B89F957C09A8068CF7A0C27C6CE3FB2018790E6A5B24100785E2A2980E428C
CMS consistency test
/usr/local/bin/perl5 cms-test.pl
CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: OK
signed detached content DER format, RSA key: OK
signed content test streaming BER format, RSA: OK
signed content DER format, DSA key: OK
signed detached content DER format, DSA key: OK
signed detached content DER format, add RSA signer: OK
signed content test streaming BER format, DSA key: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK
signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: OK
signed content test streaming multipart S/MIME format, 2 DSA and 2 RSA keys: OK
enveloped content test streaming S/MIME format, 3 recipients: OK
enveloped content test streaming S/MIME format, 3 recipients, 3rd used: OK
enveloped content test streaming S/MIME format, 3 recipients, key only used: OK
enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients: OK
CMS <= PKCS#7 compatibility tests
signed content DER format, RSA key: OK
signed detached content DER format, RSA key: OK
signed content test streaming BER format, RSA: OK
signed content DER format, DSA key: OK
signed detached content DER format, DSA key: OK
signed detached content DER format, add RSA signer: OK
signed content test streaming BER format, DSA key: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK
signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: OK
signed content test streaming multipart S/MIME format, 2 DSA and 2 RSA keys: OK
enveloped content test streaming S/MIME format, 3 recipients: OK
enveloped content test streaming S/MIME format, 3 recipients, 3rd used: OK
enveloped content test streaming S/MIME format, 3 recipients, key only used: OK
enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients: OK
CMS <=> CMS consistency tests
signed content DER format, RSA key: OK
signed detached content DER format, RSA key: OK
signed content test streaming BER format, RSA: OK
signed content DER format, DSA key: OK
signed detached content DER format, DSA key: OK
signed detached content DER format, add RSA signer: OK
signed content test streaming BER format, DSA key: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK
signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: OK
signed content test streaming multipart S/MIME format, 2 DSA and 2 RSA keys: OK
enveloped content test streaming S/MIME format, 3 recipients: OK
enveloped content test streaming S/MIME format, 3 recipients, 3rd used: OK
enveloped content test streaming S/MIME format, 3 recipients, key only used: OK
enveloped content test streaming S/MIME format, AES-256 cipher, 3 recipients: OK
signed content test streaming BER format, 2 DSA and 2 RSA keys, keyid: OK
signed content test streaming PEM format, 2 DSA and 2 RSA keys: OK
signed content MIME format, RSA key, signed receipt request: OK
signed receipt MIME format, RSA key: OK
enveloped content test streaming S/MIME format, 3 recipients, keyid: OK
enveloped content test streaming PEM format, KEK: OK
enveloped content test streaming PEM format, KEK, key only: OK
data content test streaming PEM format: OK
encrypted content test streaming PEM format, 128 bit RC2 key: OK
encrypted content test streaming PEM format, 40 bit RC2 key: OK
encrypted content test streaming PEM format, triple DES key: OK
encrypted content test streaming PEM format, 128 bit AES key: OK
CMS <=> CMS consistency tests, modified key parameters
signed content test streaming PEM format, RSA keys, PSS signature: OK
signed content test streaming PEM format, RSA keys, PSS signature, no attributes: OK
signed content test streaming PEM format, RSA keys, PSS signature, SHA384 MGF1: OK
enveloped content test streaming S/MIME format, OAEP default parameters: OK
enveloped content test streaming S/MIME format, OAEP SHA256: OK
enveloped content test streaming S/MIME format, ECDH: OK
enveloped content test streaming S/MIME format, ECDH, key identifier: OK
enveloped content test streaming S/MIME format, ECDH, AES128, SHA256 KDF: OK
enveloped content test streaming S/MIME format, ECDH, K-283, cofactor DH: skipped, EC2M disabled
enveloped content test streaming S/MIME format, X9.42 DH: OK
compressed content test streaming PEM format: OK
ALL TESTS SUCCESSFUL.
Test OCSP
=== VALID OCSP RESPONSES ===
NON-DELEGATED; Intermediate CA -> EE
Response verify OK
NON-DELEGATED; Root CA -> Intermediate CA
Response verify OK
NON-DELEGATED; Root CA -> EE
Response verify OK
DELEGATED; Intermediate CA -> EE
Response verify OK
DELEGATED; Root CA -> Intermediate CA
Response verify OK
DELEGATED; Root CA -> EE
Response verify OK
=== INVALID SIGNATURE on the OCSP RESPONSE ===
NON-DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
NON-DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
NON-DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
=== WRONG RESPONDERID in the OCSP RESPONSE ===
NON-DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
NON-DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
NON-DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
=== WRONG ISSUERNAMEHASH in the OCSP RESPONSE ===
NON-DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
NON-DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
NON-DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
=== WRONG ISSUERKEYHASH in the OCSP RESPONSE ===
NON-DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
NON-DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
NON-DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
=== WRONG KEY in the DELEGATED OCSP SIGNING CERTIFICATE ===
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069075:OCSP routines:OCSP_basic_verify:signature failure:ocsp_vfy.c:105:
=== INVALID SIGNATURE on the DELEGATED OCSP SIGNING CERTIFICATE ===
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:certificate signature failure
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:certificate signature failure
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:certificate signature failure
=== WRONG SUBJECT NAME in the ISSUER CERTIFICATE ===
NON-DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:166:
NON-DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:166:
NON-DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:166:
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:unable to get local issuer certificate
=== WRONG KEY in the ISSUER CERTIFICATE ===
NON-DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
NON-DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
NON-DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92:
DELEGATED; Intermediate CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:certificate signature failure
DELEGATED; Root CA -> Intermediate CA
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:certificate signature failure
DELEGATED; Root CA -> EE
Response Verify Failure
34383504648:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103:
34383504648:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705:
34383504648:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
34383504648:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:138:Verify error:certificate signature failure
=== INVALID SIGNATURE on the ISSUER CERTIFICATE ===
NON-DELEGATED; Intermediate CA -> EE
Response verify OK
NON-DELEGATED; Root CA -> Intermediate CA
Response verify OK
NON-DELEGATED; Root CA -> EE
Response verify OK
DELEGATED; Intermediate CA -> EE
Response verify OK
DELEGATED; Root CA -> Intermediate CA
Response verify OK
DELEGATED; Root CA -> EE
Response verify OK
ALL OCSP TESTS SUCCESSFUL
Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value -1, received 0
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value -1, received 0
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161122/test
*** Error code 1

Stop.
make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161122
root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20161122 # exity

exity: Command not found.
You have new mail.
root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20161122 # exit

exit

Script done on Tue Nov 22 01:18:27 2016

Please fix.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2016 and Happy New Year 2017

From dwmw2 at infradead.org  Tue Nov 22 17:56:17 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 17:56:17 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.184639.797476776722171891.levitte@openssl.org>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
Message-ID: <1479837377.8937.50.camel@infradead.org>

On Tue, 2016-11-22 at 18:46 +0100, Richard Levitte wrote:
> In message <489af892b16b43ee9a7009ffe52db794 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 17:40:54 +0000, "Salz, Rich" <rsalz at akamai.com> said:
> 
> rsalz> > The more interesting part is when it tries to load files it guesses are raw DER.
> rsalz> 
> rsalz> And this part worries me.? I do not think a "security library" should be guessing.
> 
> It does this by trying to interpret the blob against known ASN.1
> definitions, and will only succeed when there's a complete match.? I'm
> not terribly worried...

And even if you were, you should be *more* worried about making
*applications* do it for themselves :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/ead8802c/attachment.bin>

From rsalz at akamai.com  Tue Nov 22 18:03:31 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Nov 2016 18:03:31 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479837377.8937.50.camel@infradead.org>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
Message-ID: <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>

> > It does this by trying to interpret the blob against known ASN.1
> > definitions, and will only succeed when there's a complete match.? I'm
> > not terribly worried...

I am.  With locales and UTF8, the old simple days of text/binary are probably long gone.  And if any ASN.1 definition has extensibility in it, then we have to be concerned about things being wrapped, something like prefix attacks, and so on.  
 
> And even if you were, you should be *more* worried about making
> *applications* do it for themselves :)

I cannot control what an application does, and I am not responsible for any other application's reputation.  I do have a strongly vested stake in OpenSSL's. 

It is already possible to write a utility library that tries everything in turn, and returns an enumeration that says "seems to be an X509 certificate" etc.  And then another routine that takes that enumeration and the blob and calls the right decoder.  I would be okay with that, even if it were part of OpenSSL.  I am opposed to guessing and parsing in one step, and would -1 any PR for that, forcing a team discussion.


From James.Bottomley at HansenPartnership.com  Tue Nov 22 18:25:48 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Tue, 22 Nov 2016 10:25:48 -0800
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1479839148.2376.31.camel@HansenPartnership.com>

On Tue, 2016-11-22 at 18:03 +0000, Salz, Rich wrote:
> > > It does this by trying to interpret the blob against known ASN.1
> > > definitions, and will only succeed when there's a complete match.
> > >   I'm
> > > not terribly worried...
> 
> I am.  With locales and UTF8, the old simple days of text/binary are
> probably long gone.  And if any ASN.1 definition has extensibility in
> it, then we have to be concerned about things being wrapped,
> something like prefix attacks, and so on.  
>  
> > And even if you were, you should be *more* worried about making
> > *applications* do it for themselves :)
> 
> I cannot control what an application does, and I am not responsible
> for any other application's reputation.  I do have a strongly vested
> stake in OpenSSL's. 
> 
> It is already possible to write a utility library that tries 
> everything in turn, and returns an enumeration that says "seems to be 
> an X509 certificate" etc.  And then another routine that takes that 
> enumeration and the blob and calls the right decoder.  I would be 
> okay with that, even if it were part of OpenSSL.  I am opposed to 
> guessing and parsing in one step, and would -1 any PR for that, 
> forcing a team discussion.

That's not the proposal.  The proposal is to use PEM form because we
can make it uniquely self describing using the guard tags which
obviates the problem above.

On the larger issue of non-self describing formats like ASN.1: if your
theory that there's a security hole by allowing opportunistic format
detection is correct, simply making the user specify is palming our bug
off on to the user and abdicating responsibility because now when
they're tricked into an exploit they can be blamed not openssl.  If
such a bug exists, doing opportunistic format detection the better
guarantor of overall system security because if such a bug is found, it
would have to be fixed within openssl to everyone's benefit.

James


From rsalz at akamai.com  Tue Nov 22 18:29:09 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Nov 2016 18:29:09 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479839148.2376.31.camel@HansenPartnership.com>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479839148.2376.31.camel@HansenPartnership.com>
Message-ID: <4b4fc178e0fe4b14aeb21529f1fcb569@usma1ex-dag1mb1.msg.corp.akamai.com>

> That's not the proposal.  The proposal is to use PEM form because we can
> make it uniquely self describing using the guard tags which obviates the
> problem above.

Well that's what you want.  David wants more than that :)
 
> On the larger issue of non-self describing formats like ASN.1: if your theory
> that there's a security hole by allowing opportunistic format detection is
> correct, simply making the user specify is palming our bug off on to the user
> and abdicating responsibility because now when they're tricked into an
> exploit they can be blamed not openssl.  If such a bug exists, doing
> opportunistic format detection the better guarantor of overall system
> security because if such a bug is found, it would have to be fixed within
> openssl to everyone's benefit.

We differ.

From uri at ll.mit.edu  Tue Nov 22 19:02:57 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 22 Nov 2016 19:02:57 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.134859.1138930452149962704.levitte@openssl.org>
References: <20161116.190703.2026777923936653632.levitte@openssl.org>
 <1479735749.8937.5.camel@infradead.org>
 <1479744347.2309.21.camel@HansenPartnership.com>
 <20161122.134859.1138930452149962704.levitte@openssl.org>
Message-ID: <C78892FC-4456-4B04-ABDF-247D14250B07@ll.mit.edu>

    James.Bottomley> Yes, that's right.  When any SSL program sees a TPM wrapped key, it
    James.Bottomley> should just do the right thing if it has the engine capability without
    James.Bottomley> needing the user to add any options to the command line.
    
    Mm...  I'm not sure I agree with the method, passing a BIO for the
    key_id. 

I?m sure I rather disagree, and rather strongly.

    I would much rather have seen a patch where OpenSSL's PEM
    module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
    from it, securing it somehow (since key_id is expected to be be NUL
    terminated) and pass that to the engine.

I would much rather use PEM only to contain keys/certs instead of ?pointing? at them in some weird way.
    
    My vote goes to a URI based spec rather than bastardising PEM files.

+10^101. ?

    I understand this kinda throws years of developmemt out the window,
    but there you have it.

?It?s never too late to turn back on a wrong road?
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/cd11ecc2/attachment-0001.bin>

From dwmw2 at infradead.org  Tue Nov 22 19:37:55 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 22 Nov 2016 19:37:55 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <4b4fc178e0fe4b14aeb21529f1fcb569@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479839148.2376.31.camel@HansenPartnership.com>
 <4b4fc178e0fe4b14aeb21529f1fcb569@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1479843475.8937.52.camel@infradead.org>

On Tue, 2016-11-22 at 18:29 +0000, Salz, Rich wrote:
> > That's not the proposal.  The proposal is to use PEM form because we can
> > make it uniquely self describing using the guard tags which obviates the
> > problem above.
> 
> Well that's what you want.  David wants more than that :)

S'true :)

> > On the larger issue of non-self describing formats like ASN.1: if your theory
> > that there's a security hole by allowing opportunistic format detection is
> > correct, simply making the user specify is palming our bug off on to the user
> > and abdicating responsibility because now when they're tricked into an
> > exploit they can be blamed not openssl.  If such a bug exists, doing
> > opportunistic format detection the better guarantor of overall system
> > security because if such a bug is found, it would have to be fixed within
> > openssl to everyone's benefit.
> 
> We differ.

We do. I think James put it well though, when he talked of "palming our
bug off onto the user and abdicating responsibility". The library
doesn't get to sit in its ivory tower of perfection; you are
responsible for the API you inflict on users and how they actually
*use* it.

And besides, even if we force applications to iterate over the possible
formats for themselves, they aren't going to have a bug *there*. Any
bug will be in our parser for one specific format or another. We didn't
even *save* our reputation by forcing the application authors to jump
through hoops.

And more to the point, you already *do* this, in d2i_AutoPrivateKey().
It's just that you only handle *some* of the known key formats, so the
application has to explicitly try the others. What's being proposed
here is merely that we fix that up to have full coverage ? not a
radical new approach at all.

Oh, and that we automatically distinguish between PEM and DER forms,
but *that* much is fairly trivial and safe.

And the locale / character set issue is not relevant here. ASN.1 is
binary, PEM is ASCII.

When we come to talk about passwords, *sure* we can look at character
sets. But that is a somewhat orthogonal issue.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161122/c516dcda/attachment.bin>

From thomas.francis.jr at pobox.com  Tue Nov 22 20:26:16 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Tue, 22 Nov 2016 15:26:16 -0500
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479843475.8937.52.camel@infradead.org>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479839148.2376.31.camel@HansenPartnership.com>
 <4b4fc178e0fe4b14aeb21529f1fcb569@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479843475.8937.52.camel@infradead.org>
Message-ID: <39fc2676-2c90-7336-231f-38138a7963e8@pobox.com>

On 11/22/16 2:37 PM, David Woodhouse wrote:
> On Tue, 2016-11-22 at 18:29 +0000, Salz, Rich wrote:

<snip>

> And the locale / character set issue is not relevant here. ASN.1 is
> binary, PEM is ASCII.

PEM should be ASCII; in practice it is not necessarily ASCII.  There are 
several products that produce "PEM files" in various EBCDIC character 
sets.  Other products produce them in ASCII, but then  transfer them 
with an EBCDIC to ASCII conversion.  And in still others, it's the 
customer who transfers it manually, converting from EBCDIC to ASCII when 
the file was ASCII.  These latter two are less common in my limited 
experience, which is fortunate, because recovering from that is very 
difficult.

I've also seen some windows products that will produce "unicode" pem 
files, which may or may not have a BOM at the beginning, and other 
products which produce the files with the UTF-8 BOM at the beginning, too.

While it's easy for me to say these files are malformed, the customer 
doesn't care.  They have the file; they expect it to work.

In most of those cases, the user will open the file, and see exactly 
what they expect, a PEM header, followed by what looks like base64 
encoded data, and a matching footer.  It's very difficult to convince a 
customer the file is incorrect in the face of that.  Even if you get 
them to acknowledge the file isn't in the expected format, again they 
don't care.  They have the file, usually from some very expensive 
software or process, your much less important software had better use it 
(yup, I've had those conversations with customers, fortunately with tech 
support filtering my side of the conversation :) ).

In any event, I don't think it's OpenSSL's job to detect and fix these 
kinds of issues.  Although probably 90% of them could be fixed with a 
simple EBCDIC->ASCII converter, ignoring BOMs and recognizing the 
Windows "unicode" format. :)

TOM

From levitte at openssl.org  Tue Nov 22 23:03:41 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 00:03:41 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161123.000341.1937900079739030126.levitte@openssl.org>

In message <021a5d5b885845f5ab79c4420232e415 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 18:03:31 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> It is already possible to write a utility library that tries
rsalz> everything in turn, and returns an enumeration that says "seems
rsalz> to be an X509 certificate" etc.  And then another routine that
rsalz> takes that enumeration and the blob and calls the right
rsalz> decoder.  I would be okay with that, even if it were part of
rsalz> OpenSSL.  I am opposed to guessing and parsing in one step, and
rsalz> would -1 any PR for that, forcing a team discussion.

Uhmmmm...  the d2i functions are already both in one.  Are you saying
they should be split in two, one part that does all the checking and
the other that just decodes, trusting that all checks are already
done?  What you're gonna do there is double part of the work.

But, what I get from you is "what if a octet stream matches two
different ASN.1 types?  Is that it?

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

From levitte at openssl.org  Tue Nov 22 23:07:32 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 00:07:32 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479839148.2376.31.camel@HansenPartnership.com>
References: <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479839148.2376.31.camel@HansenPartnership.com>
Message-ID: <20161123.000732.1588044569239621619.levitte@openssl.org>

In message <1479839148.2376.31.camel at HansenPartnership.com> on Tue, 22 Nov 2016 10:25:48 -0800, James Bottomley <James.Bottomley at HansenPartnership.com> said:

James.Bottomley> On Tue, 2016-11-22 at 18:03 +0000, Salz, Rich wrote:
James.Bottomley> > > > It does this by trying to interpret the blob against known ASN.1
James.Bottomley> > > > definitions, and will only succeed when there's a complete match.
James.Bottomley> > > >   I'm
James.Bottomley> > > > not terribly worried...
James.Bottomley> > 
James.Bottomley> > I am.  With locales and UTF8, the old simple days of text/binary are
James.Bottomley> > probably long gone.  And if any ASN.1 definition has extensibility in
James.Bottomley> > it, then we have to be concerned about things being wrapped,
James.Bottomley> > something like prefix attacks, and so on.  
James.Bottomley> >  
James.Bottomley> > > And even if you were, you should be *more* worried about making
James.Bottomley> > > *applications* do it for themselves :)
James.Bottomley> > 
James.Bottomley> > I cannot control what an application does, and I am not responsible
James.Bottomley> > for any other application's reputation.  I do have a strongly vested
James.Bottomley> > stake in OpenSSL's. 
James.Bottomley> > 
James.Bottomley> > It is already possible to write a utility library that tries 
James.Bottomley> > everything in turn, and returns an enumeration that says "seems to be 
James.Bottomley> > an X509 certificate" etc.  And then another routine that takes that 
James.Bottomley> > enumeration and the blob and calls the right decoder.  I would be 
James.Bottomley> > okay with that, even if it were part of OpenSSL.  I am opposed to 
James.Bottomley> > guessing and parsing in one step, and would -1 any PR for that, 
James.Bottomley> > forcing a team discussion.
James.Bottomley> 
James.Bottomley> That's not the proposal.  The proposal is to use PEM form because we
James.Bottomley> can make it uniquely self describing using the guard tags which
James.Bottomley> obviates the problem above.

This is a side thread that discusses the 'file' scheme loader in my
STORE effort.  So, uhmmm, we're a bit away from just PEM here.
However, if we go back to the discussion about TSS KEY BLOBs, yeah,
I've only seen a PEM proposal, and that's a muuuuch easier case.

James.Bottomley> On the larger issue of non-self describing formats like ASN.1: if your
James.Bottomley> theory that there's a security hole by allowing opportunistic format
James.Bottomley> detection is correct, simply making the user specify is palming our bug
James.Bottomley> off on to the user and abdicating responsibility because now when
James.Bottomley> they're tricked into an exploit they can be blamed not openssl.  If
James.Bottomley> such a bug exists, doing opportunistic format detection the better
James.Bottomley> guarantor of overall system security because if such a bug is found, it
James.Bottomley> would have to be fixed within openssl to everyone's benefit.

I agree with that sentiment.

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

From dwmw2 at infradead.org  Wed Nov 23 08:23:38 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 08:23:38 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161122.180610.153176201036564955.levitte@openssl.org>
References: <20161122.172142.1234479047401597555.levitte@openssl.org>
 <1479832087.8937.49.camel@infradead.org>
 <1479833048.2376.21.camel@HansenPartnership.com>
 <20161122.180610.153176201036564955.levitte@openssl.org>
Message-ID: <1479889418.8937.54.camel@infradead.org>

On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
> 
> Actually, I agree with this, and that goes along with how our PEM
> routines work (specifically, PEM_X509_INFO_read_bio()), it just
> treats the data as an octet string and hands it down to a d2i routine
> of choice, with a pointer to where to place the result.
> 
> It's not very hard to imagine adding the possibility for external
> handlers for specific PEM content types, which could be handed an
> octet string and a pointer to a X509_INFO (which is the structure used
> to collect the data in), or something like that (I can also imagine
> having one separate handler for each type of data that can be
> returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
> and so on and so forth).? That would make it possible for an engine to
> declare its own handler during the binding call, along with all other
> information it feeds back to libcrypto.

Yeah, something like that.

It's worth noting that the 'PEM content types' are just the same as the
'DER content types'. It's just that if you have a PEM header, you know
precisely *which* DER content type you have after base64-decoding (and
decryption in some cases), and you don't have to do what
d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

So maybe it's just "content types" that we have handlers for, each with
an optional PEM tag for matching, *and* an optional match function
which is given the parsed ASN.1 and checks if it's a match.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/f6e36e1b/attachment-0001.bin>

From tmraz at redhat.com  Wed Nov 23 08:39:35 2016
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 23 Nov 2016 09:39:35 +0100
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.000341.1937900079739030126.levitte@openssl.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
Message-ID: <1479890375.2544.3.camel@redhat.com>

On St, 2016-11-23 at 00:03 +0100, Richard Levitte wrote:
> In message <021a5d5b885845f5ab79c4420232e415 at usma1ex-dag1mb1.msg.corp
> .akamai.com> on Tue, 22 Nov 2016 18:03:31 +0000, "Salz, Rich" <rsalz@
> akamai.com> said:
> 
> rsalz> It is already possible to write a utility library that tries
> rsalz> everything in turn, and returns an enumeration that says
> "seems
> rsalz> to be an X509 certificate" etc.??And then another routine that
> rsalz> takes that enumeration and the blob and calls the right
> rsalz> decoder.??I would be okay with that, even if it were part of
> rsalz> OpenSSL.??I am opposed to guessing and parsing in one step,
> and
> rsalz> would -1 any PR for that, forcing a team discussion.
> 
> Uhmmmm...??the d2i functions are already both in one.??Are you saying
> they should be split in two, one part that does all the checking and
> the other that just decodes, trusting that all checks are already
> done???What you're gonna do there is double part of the work.
> 
> But, what I get from you is "what if a octet stream matches two
> different ASN.1 types???Is that it?

I also would not be too much worried - the API call should not be
completely universal - the application should know whether it is
loading a certificate or private key. It should just be able to use a
single call to load a certificate in PEM, DER, or whatever other
possible data format. The same for private keys, 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.)




From levitte at openssl.org  Wed Nov 23 08:56:17 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 09:56:17 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479889418.8937.54.camel@infradead.org>
References: <1479833048.2376.21.camel@HansenPartnership.com>
 <20161122.180610.153176201036564955.levitte@openssl.org>
 <1479889418.8937.54.camel@infradead.org>
Message-ID: <20161123.095617.817714375930121040.levitte@openssl.org>

In message <1479889418.8937.54.camel at infradead.org> on Wed, 23 Nov 2016 08:23:38 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Actually, I agree with this, and that goes along with how our PEM
dwmw2> > routines work (specifically, PEM_X509_INFO_read_bio()), it just
dwmw2> > treats the data as an octet string and hands it down to a d2i routine
dwmw2> > of choice, with a pointer to where to place the result.
dwmw2> > 
dwmw2> > It's not very hard to imagine adding the possibility for external
dwmw2> > handlers for specific PEM content types, which could be handed an
dwmw2> > octet string and a pointer to a X509_INFO (which is the structure used
dwmw2> > to collect the data in), or something like that (I can also imagine
dwmw2> > having one separate handler for each type of data that can be
dwmw2> > returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL,
dwmw2> > and so on and so forth).? That would make it possible for an engine to
dwmw2> > declare its own handler during the binding call, along with all other
dwmw2> > information it feeds back to libcrypto.
dwmw2> 
dwmw2> Yeah, something like that.
dwmw2> 
dwmw2> It's worth noting that the 'PEM content types' are just the same as the
dwmw2> 'DER content types'. It's just that if you have a PEM header, you know
dwmw2> precisely *which* DER content type you have after base64-decoding (and
dwmw2> decryption in some cases), and you don't have to do what
dwmw2> d2i_AutoPrivateKey() does to infer it from the ASN.1 structure.

True.

dwmw2> So maybe it's just "content types" that we have handlers for, each with
dwmw2> an optional PEM tag for matching, *and* an optional match function
dwmw2> which is given the parsed ASN.1 and checks if it's a match.

I'm not sure what you mean with a match function...  but going off on
a limb, how about a reference to an OpenSSL style ASN1 description?
So basically, for an imaginary TSS KEY BLOB (one that actually would
use that TssBlob definition we talked about earlier), these three
items would be specified:

    "TSS KEY BLOB",
    ASN1_ITEM_rptr(TSS_BLOB),	/* TSS_BLOB ASN1 stuff defined in engine */
    handler			/* Essentially a d2i function */

Or did you mean that the matching would also involve checking the
contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
if they correspond to your structures?  If that's what you mean, my
gut feeling tells me - and I haven't had my morning coffee yet - we're
now moving into a territory where I fully expect dragons...  not to
mention the worries Rich expressed.

Cheers,
Richard ( coffee.  Now! )

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

From dwmw2 at infradead.org  Wed Nov 23 09:47:17 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 09:47:17 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479890375.2544.3.camel@redhat.com>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <1479890375.2544.3.camel@redhat.com>
Message-ID: <1479894437.8937.56.camel@infradead.org>

On Wed, 2016-11-23 at 09:39 +0100, Tomas Mraz wrote:
> 
> I also would not be too much worried - the API call should not be
> completely universal - the application should know whether it is
> loading a certificate or private key. It should just be able to use a
> single call to load a certificate in PEM, DER, or whatever other
> possible data format. The same for private keys, etc.

Well, except in the case where the application asks to use a PKCS#12
file as the identity. In which case you want to load cert, key, and
supporting cert chain all from the same place.

And you often have a PEM file which contains both the certificate and
the private key.

But yes, generally you *know* what you're looking for.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/692cff65/attachment.bin>

From dwmw2 at infradead.org  Wed Nov 23 09:55:13 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 09:55:13 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.095617.817714375930121040.levitte@openssl.org>
References: <1479833048.2376.21.camel@HansenPartnership.com>
 <20161122.180610.153176201036564955.levitte@openssl.org>
 <1479889418.8937.54.camel@infradead.org>
 <20161123.095617.817714375930121040.levitte@openssl.org>
Message-ID: <1479894913.8937.58.camel@infradead.org>

On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
> 
> 
> dwmw2> So maybe it's just "content types" that we have handlers for, each with
> dwmw2> an optional PEM tag for matching, *and* an optional match function
> dwmw2> which is given the parsed ASN.1 and checks if it's a match.
> 
> I'm not sure what you mean with a match function...? but going off on
> a limb, how about a reference to an OpenSSL style ASN1 description?
> So basically, for an imaginary TSS KEY BLOB (one that actually would
> use that TssBlob definition we talked about earlier), these three
> items would be specified:
> 
> ??? "TSS KEY BLOB",
> ??? ASN1_ITEM_rptr(TSS_BLOB),???/* TSS_BLOB ASN1 stuff defined in engine */
> ??? handler?????????????????????/* Essentially a d2i function */
> 
> Or did you mean that the matching would also involve checking the
> contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
> if they correspond to your structures?? If that's what you mean, my
> gut feeling tells me - and I haven't had my morning coffee yet - we're
> now moving into a territory where I fully expect dragons...? not to
> mention the worries Rich expressed.

Oh $DEITY no,  not looking in the contents of the OCTET_STRING.
Basically I'm thinking of doing precisely what d2i_AutoPrivateKey()
already does, just with expanded coverage and slightly less hard-coded
stuff.

The "match" part there is a little simplistic; we basically parse the
ASN.1 into a STACK_OF(ASN1_TYPE), then 

 if (sk_ASN1_TYPE_num(inkey) == 6)
   /* it's DSA in OpenSSL's format */
 if (sk_ASN1_TYPE_num(inkey) == 4)
   /* it's ECDSA according to RFC5915 */
 if (sk_ASN1_TYPE_num(unkey) == 3)
   /* Unencrypted PKCS#8 */

... etc.

Those checks could possibly stand to be a *little* more discerning, and
 each one might live in a specific format-handler's "ASN.1 match"
function. But that's the general idea. And we *do* already have the
"decide, then parse" model that Rich was talking about.

And yes, if we're going to make the checks slightly more discerning
then instead of just counting the items in the sequence, we could see
if it matches the ASN.1 description. And as you say, it doesn't have to
be a match *function* for each handler; just the ASN.1 description.?

Doing it like that would prevent any implementations (like the one in
the TPM engine) from being *tempted* to go prodding around in the
contents of OCTET STRINGs. Which is probably a feature :)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/bf3b1d72/attachment-0001.bin>

From levitte at openssl.org  Wed Nov 23 10:47:34 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 11:47:34 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479894913.8937.58.camel@infradead.org>
References: <1479889418.8937.54.camel@infradead.org>
 <20161123.095617.817714375930121040.levitte@openssl.org>
 <1479894913.8937.58.camel@infradead.org>
Message-ID: <20161123.114734.2150320044696719276.levitte@openssl.org>

In message <1479894913.8937.58.camel at infradead.org> on Wed, 23 Nov 2016 09:55:13 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > 
dwmw2> > dwmw2> So maybe it's just "content types" that we have handlers for, each with
dwmw2> > dwmw2> an optional PEM tag for matching, *and* an optional match function
dwmw2> > dwmw2> which is given the parsed ASN.1 and checks if it's a match.
dwmw2> > 
dwmw2> > I'm not sure what you mean with a match function...? but going off on
dwmw2> > a limb, how about a reference to an OpenSSL style ASN1 description?
dwmw2> > So basically, for an imaginary TSS KEY BLOB (one that actually would
dwmw2> > use that TssBlob definition we talked about earlier), these three
dwmw2> > items would be specified:
dwmw2> > 
dwmw2> > ??? "TSS KEY BLOB",
dwmw2> > ??? ASN1_ITEM_rptr(TSS_BLOB),???/* TSS_BLOB ASN1 stuff defined in engine */
dwmw2> > ??? handler?????????????????????/* Essentially a d2i function */
dwmw2> > 
dwmw2> > Or did you mean that the matching would also involve checking the
dwmw2> > contents of the OCTET_STRING that TSS KEY BLOBs currently are, to see
dwmw2> > if they correspond to your structures?? If that's what you mean, my
dwmw2> > gut feeling tells me - and I haven't had my morning coffee yet - we're
dwmw2> > now moving into a territory where I fully expect dragons...? not to
dwmw2> > mention the worries Rich expressed.
dwmw2> 
dwmw2> Oh $DEITY no,  not looking in the contents of the OCTET_STRING.
dwmw2> Basically I'm thinking of doing precisely what d2i_AutoPrivateKey()
dwmw2> already does, just with expanded coverage and slightly less hard-coded
dwmw2> stuff.

<snip>

dwmw2> Doing it like that would prevent any implementations (like the one in
dwmw2> the TPM engine) from being *tempted* to go prodding around in the
dwmw2> contents of OCTET STRINGs. Which is probably a feature :)

Right...

But then, embedding everything in an OCTET STRING isn't exactly a
novel idea either.  How do we discern a DER encoded TSS KEY BLOB from
whatever else that had the same "novel" idea? An OCTET STRING is an
OCTET STRING is an OCTET STRING...  See the dragons hovering over
there? ;-)

Cheers,
Richard

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

From dwmw2 at infradead.org  Wed Nov 23 10:53:30 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 10:53:30 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.114734.2150320044696719276.levitte@openssl.org>
References: <1479889418.8937.54.camel@infradead.org>
 <20161123.095617.817714375930121040.levitte@openssl.org>
 <1479894913.8937.58.camel@infradead.org>
 <20161123.114734.2150320044696719276.levitte@openssl.org>
Message-ID: <1479898410.8937.62.camel@infradead.org>

On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
> 
> Right...
> 
> But then, embedding everything in an OCTET STRING isn't exactly a
> novel idea either.? How do we discern a DER encoded TSS KEY BLOB from
> whatever else that had the same "novel" idea? An OCTET STRING is an
> OCTET STRING is an OCTET STRING...? See the dragons hovering over
> there? ;-)

We don't. Crap like that is auto-detected in PEM form only. And yes, it
*really* should have used the TssBlob structure, not just the OCTET
STRING.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/3ccdfe30/attachment.bin>

From peter.sylvester at edelweb.fr  Wed Nov 23 11:58:14 2016
From: peter.sylvester at edelweb.fr (Peter Sylvester Edelweb)
Date: Wed, 23 Nov 2016 11:58:14 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.114734.2150320044696719276.levitte@openssl.org>
References: <1479889418.8937.54.camel@infradead.org>
 <20161123.095617.817714375930121040.levitte@openssl.org>
 <1479894913.8937.58.camel@infradead.org>
 <20161123.114734.2150320044696719276.levitte@openssl.org>
Message-ID: <61d2627d-f7d9-c8aa-c4e9-497eb7c85c75@edelweb.fr>

There is at least one real life HSM engine, that encodes numerical identifiers as "pseudo prime
numbers", you end up with a
RSA private key that has 1 and 2 prime numbers?

No new ASN.1

Best



On 11/23/2016 11:47 AM, Richard Levitte wrote:
> In message <1479894913.8937.58.camel at infradead.org> on Wed, 23 Nov 2016 09:55:13 +0000, David Woodhouse <dwmw2 at infradead.org> said:
>
> dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote:
> dwmw2> > 
> dwmw2> > 
> dwmw2> > dwmw2> So maybe it's just "content types" that we have handlers for, each with
> dwmw2> > dwmw2> an optional PEM tag for matching, *and* an optional match function
> dwmw2> > dwmw2> which is given the parsed ASN.1 and checks if it's a match.
> dwmw2> > 
> dwmw2> > I'm not sure what you mean with a match function...  but going off on
> dwmw2> > a limb, how about a reference to an OpenSSL style ASN1 description?
> dwmw2> > So basically, for an imaginary TSS KEY BLOB (one that actually would
> dwmw2> > use that TssBlob definition we talked about earlier), these three
> dwmw2> > items would be specified:
> dwmw2> > 
> dwmw2> >     "TSS KEY BLOB",
> dwmw2> >     ASN1_ITEM_rptr(TSS_BLOB),   /* TSS_BLOB ASN1 stuff defined in engine */
> dwmw2> >     handler                     /* Essentially a d2i function */
> dwmw2> > 
> Richard
>


From dwmw2 at infradead.org  Wed Nov 23 12:58:34 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 12:58:34 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <39fc2676-2c90-7336-231f-38138a7963e8@pobox.com>
References: <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <489af892b16b43ee9a7009ffe52db794@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479839148.2376.31.camel@HansenPartnership.com>
 <4b4fc178e0fe4b14aeb21529f1fcb569@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479843475.8937.52.camel@infradead.org>
 <39fc2676-2c90-7336-231f-38138a7963e8@pobox.com>
Message-ID: <1479905914.8937.72.camel@infradead.org>

On Tue, 2016-11-22 at 15:26 -0500, Thomas Francis, Jr. wrote:
> On 11/22/16 2:37 PM, David Woodhouse wrote:
> > And the locale / character set issue is not relevant here. ASN.1 is
> > binary, PEM is ASCII.
> PEM should be ASCII; in practice it is not necessarily ASCII.? There are 
> several products that produce "PEM files" in various EBCDIC character 
> sets.? Other products produce them in ASCII, but then? transfer them 
> with an EBCDIC to ASCII conversion.? And in still others, it's the 
> customer who transfers it manually, converting from EBCDIC to ASCII when 
> the file was ASCII.? These latter two are less common in my limited 
> experience, which is fortunate, because recovering from that is very 
> difficult.
> 
> I've also seen some windows products that will produce "unicode" pem 
> files, which may or may not have a BOM at the beginning, and other 
> products which produce the files with the UTF-8 BOM at the beginning, too.
> 
> While it's easy for me to say these files are malformed, the customer 
> doesn't care.? They have the file; they expect it to work.

Ewww.

I have to confess that I'm mostly disinclined to care. I'll just go
back to your first sentence cited above, and "clarify" my original
statement to "the PEM that we *support* is ASCII".

But if people *really* expect it to work... would you seriously suggest
that this abomination (at least the EBCDIC and UTF-16+BOM variants) is
something that applications ought to support automatically? If so,
perhaps you'd be arguing that I should update my draft at
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html to
mandate support for it? I suppose checking for a BOM and eating UTF-16
really *isn't* that complicated for an application.

As things stand I suppose I should at least mention it, but I'm
inclined to say that applications MAY support these variants but are
not required to.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/4f5d63fe/attachment-0001.bin>

From rsalz at akamai.com  Wed Nov 23 13:13:05 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 Nov 2016 13:13:05 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.000341.1937900079739030126.levitte@openssl.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
Message-ID: <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>


> Uhmmmm...  the d2i functions are already both in one.  Are you saying they
> should be split in two, one part that does all the checking and the other that
> just decodes, trusting that all checks are already done?  What you're gonna
> do there is double part of the work.

Well, not double, but first do the cascade then return an indicator of which specific one worked.  Then the application can call a routine to again do the decode.

If it bothers you, return the size as an output parameter.  That fits with our i2d model.
 
> But, what I get from you is "what if a octet stream matches two different
> ASN.1 types?  Is that it?

Yes among others.  How do you know it will *never* happen?

From levitte at openssl.org  Wed Nov 23 13:26:58 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 14:26:58 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161123.142658.110286065069080447.levitte@openssl.org>

In message <c5e2f2ebdd9c42be840c34cdbb7bf3bb at usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 13:13:05 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > Uhmmmm...  the d2i functions are already both in one.  Are you saying they
rsalz> > should be split in two, one part that does all the checking and the other that
rsalz> > just decodes, trusting that all checks are already done?  What you're gonna
rsalz> > do there is double part of the work.
rsalz> 
rsalz> Well, not double, but first do the cascade then return an
rsalz> indicator of which specific one worked.  Then the application
rsalz> can call a routine to again do the decode.

Why is it different if we do exactly that in libcrypto?

rsalz> If it bothers you, return the size as an output parameter.
rsalz> That fits with our i2d model.

Dunno about you, but I'm talking d2i, not i2d.  Different beast.

rsalz> > But, what I get from you is "what if a octet stream matches two different
rsalz> > ASN.1 types?  Is that it?
rsalz> 
rsalz> Yes among others.  How do you know it will *never* happen?

I don't, and in some cases (such as the TSS KEY BLOB), there will most
likely ONLY be a PEM decoder, which is a much easier ballgame.

Quite frankly, that's a though that should go back to David and his
demand of automatic detection.  If anyone would *ever* create a raw
DER file holding a tss OCTET STRING, then the file spec *will* have to
have an indication of what type of content it is.
If we're thinking in URI terms, I could think of a contraption like
file:whatever.pem?t=tsskeyblob ...  or dare I say it,
tpmkey:file=whatever.pem  (David is so going to hate me ;-) ...)


Cheers,
Richard

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

From dwmw2 at infradead.org  Wed Nov 23 13:33:45 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 13:33:45 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1479908025.8937.74.camel@infradead.org>

On Wed, 2016-11-23 at 13:13 +0000, Salz, Rich wrote:
> > But, what I get from you is "what if a octet stream matches two different
> > ASN.1 types?  Is that it?
> 
> Yes among others.  How do you know it will *never* happen?

Because if anyone tries to invent yet *another* ASN.1 form for storing
keys, I am going to personally visit them in the small hours and stick
a bat up their nightshirt?

Hopefully we don't need to add completely new ones; we can use the
existing PKCS#8 and PKCS#12 containers for new things.

But even if a new form is invented which is ambiguous with existing
forms, that's OK too. We don't support 'detection' of that new format
by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless
the type is explicitly specified.

There is potential for confusion if the new object type doesn't just
have the same ASN.1 structure as the old object, but objects of the new
type can be completely valid objects of the old type too, and can be
loaded as such. But that would have been a problem *anyway*. There's
nothing new here.

If I make a new object type which looks like a PKCS#1 RSA key but is
actually something completely different, it's *already* likely that
OpenSSL will load that new object as if it was an RSA key in some
cases.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/79b08f33/attachment.bin>

From levitte at openssl.org  Wed Nov 23 13:34:21 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 14:34:21 +0100 (CET)
Subject: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless handling
 of TPM based RSA keys in openssl)
In-Reply-To: <1479823032.8937.37.camel@infradead.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
Message-ID: <20161123.143421.2219208184032604165.levitte@openssl.org>

Change of subject, this part of the thread isn't so much TPM any more...

In message <1479823032.8937.37.camel at infradead.org> on Tue, 22 Nov 2016 13:57:12 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > Just let me shamelessly mention my STORE effort again ;-)
dwmw2> > Among others, it does attempt to solve that very problem (in the
dwmw2> > 'file' scheme handler).
dwmw2> 
dwmw2> Neat. Note that I have a ready-made test suite for you in OpenConnect:
dwmw2> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
dwmw2> 
dwmw2> For every one of the key files therein, does your current
dwmw2> implementation work? :)

Nope, not even for all the PEM files...  I'm seeing a number of them
(I noticed the PKCS#8 ones in particular) that don't return any data
at all.

I haven't look that deeply into PEM_X509_INFO_read_bio before, and it
seems to only cover a subset of all the types we recognise.
Considering it's undocumented, I'm wondering if that's the right
function to pursue.  The other option is to create a function in the
'file' scheme loader that does the same thing but with a table of
handlers.  I'm quite fine with that idea...

Cheers,
Richard

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

From rsalz at akamai.com  Wed Nov 23 13:51:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 Nov 2016 13:51:03 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.142658.110286065069080447.levitte@openssl.org>
References: <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.142658.110286065069080447.levitte@openssl.org>
Message-ID: <2360f57bb7504a328e5517ac92e19427@usma1ex-dag1mb1.msg.corp.akamai.com>


> Why is it different if we do exactly that in libcrypto?

Because *we* are not guessing.  We are telling the application "we think it's a FOO" and then letting the application decide what to do.

Security libraries *should not guess.*

From dwmw2 at infradead.org  Wed Nov 23 13:54:00 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 13:54:00 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.142658.110286065069080447.levitte@openssl.org>
References: <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.142658.110286065069080447.levitte@openssl.org>
Message-ID: <1479909240.8937.76.camel@infradead.org>

On Wed, 2016-11-23 at 14:26 +0100, Richard Levitte wrote:
> 
> Quite frankly, that's a though that should go back to David and his
> demand of automatic detection.? If anyone would *ever* create a raw
> DER file holding a tss OCTET STRING, then the file spec *will* have to
> have an indication of what type of content it is.
> If we're thinking in URI terms, I could think of a contraption like
> file:whatever.pem?t=tsskeyblob ...? or dare I say it,
> tpmkey:file=whatever.pem? (David is so going to hate me ;-) ...)

Nah, that's fine. I mean, I hated you already, but I don't hate you any
*more* for that observation.

I don't care about supporting every bizarre esoteric format under the
sun. All I'm after is consistency between applications for the *common*
and *reasonable* file formats.

Right now, if I have a PKCS#12 file with my identity certificate, I can
use that with a *subset* of the applications installed in my system.

If I have a PKCS#8 file, I can use that with a *different* subset of
the applications. A different subset according to whether it's PEM or
DER.

If it's on a PKCS#11 token, I can use that with a *different* subset.

And many applications can be configured to build with a choice of
crypto libraries, so the formats they support will be *different* from
one distribution to another.

It's that mess that I'm trying to fix, but only for the key formats
which are common enough that users have a reasonable expectation that
they'll work.

If some nutter starts writing the TPM_KEY12 OCTET STREAM to a DER file
without even using the TssBlob structure from the TSS spec, I am not
going to lose any sleep over that.

And note that I am actively soliciting input on *what* forms should be
expected to "Just Work" and which are less important.

Perhaps there's a case to be made for ditching DER entirely and
expecting people to use PEM? Or at least expect DER to work only for
PKCS#12, PKCS#8 and PKCS#1?

I'd certainly be OK with never adding any *new* DER forms to the list
of "shall be expected to work", and requiring PEM instead for anything
new. With the caveat that I *am* being led by what's actually out there
in the wild, being issued to users through their corporate and other
PKI infrastructure.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/40292fb1/attachment-0001.bin>

From levitte at openssl.org  Wed Nov 23 14:21:06 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 15:21:06 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479908025.8937.74.camel@infradead.org>
References: <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
Message-ID: <20161123.152106.1226513754734735097.levitte@openssl.org>

In message <1479908025.8937.74.camel at infradead.org> on Wed, 23 Nov 2016 13:33:45 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Wed, 2016-11-23 at 13:13 +0000, Salz, Rich wrote:
dwmw2> > > But, what I get from you is "what if a octet stream matches two different
dwmw2> > > ASN.1 types?  Is that it?
dwmw2> > 
dwmw2> > Yes among others.  How do you know it will *never* happen?
dwmw2> 
dwmw2> Because if anyone tries to invent yet *another* ASN.1 form for storing
dwmw2> keys, I am going to personally visit them in the small hours and stick
dwmw2> a bat up their nightshirt?

(let's keep the heat down, shall we?)

dwmw2> Hopefully we don't need to add completely new ones; we can use the
dwmw2> existing PKCS#8 and PKCS#12 containers for new things.
dwmw2> 
dwmw2> But even if a new form is invented which is ambiguous with existing
dwmw2> forms, that's OK too. We don't support 'detection' of that new format
dwmw2> by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless
dwmw2> the type is explicitly specified.

Errr...  Now I'm confused.  Wasn't that (explicit type spec) exactly
what you didn't want to see, no matter if the file was PEM or raw DER?

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

From levitte at openssl.org  Wed Nov 23 14:32:18 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 15:32:18 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <2360f57bb7504a328e5517ac92e19427@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.142658.110286065069080447.levitte@openssl.org>
 <2360f57bb7504a328e5517ac92e19427@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161123.153218.494728264715626786.levitte@openssl.org>

In message <2360f57bb7504a328e5517ac92e19427 at usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 13:51:03 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > Why is it different if we do exactly that in libcrypto?
rsalz> 
rsalz> Because *we* are not guessing.  We are telling the application
rsalz> "we think it's a FOO" and then letting the application decide
rsalz> what to do.

We don't have the functionality to do it that way, at all.  All we
have are the d2i functions, which will either return with an error
indication or return the fully parsed and decoded structure.

Essentially, you're suggesting that we split out the matching part of
the d2i functions and put that to good use.  Or do you have some other
idea, along the lines if magic?

rsalz> Security libraries *should not guess.*

Isn't telling the application "we think it's a FOO" guessing?  What's
the application going to do, go "naaaah, methinks it's a BAR" and try
to decode the blob as that (and most probably fail) rather than FOO?

Cheers,
Richard

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

From rsalz at akamai.com  Wed Nov 23 14:41:14 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 Nov 2016 14:41:14 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.153218.494728264715626786.levitte@openssl.org>
References: <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.142658.110286065069080447.levitte@openssl.org>
 <2360f57bb7504a328e5517ac92e19427@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.153218.494728264715626786.levitte@openssl.org>
Message-ID: <3d837eb338bb47a68938676967ed1092@usma1ex-dag1mb1.msg.corp.akamai.com>


> Essentially, you're suggesting that we split out the matching part of the d2i
> functions and put that to good use.  Or do you have some other idea, along
> the lines if magic?

NO.  I am suggesting add one new routine that tries varies "convert to native" and returns which conversion worked.  And then another new routine that takes that return value and calls that conversion routine directly.  The cost of doing this is one extra d2i.  By the application.  And that first routine should ideally return a bitmask of all functions that succeeded so that handling ambiguities are built-in to the API.
 
> rsalz> Security libraries *should not guess.*
> 
> Isn't telling the application "we think it's a FOO" guessing?  What's the
> application going to do, go "naaaah, methinks it's a BAR" and try to decode
> the blob as that (and most probably fail) rather than FOO?

It might.  Or it might throw up its hands and give up.  Or it might check to see if the file is ambiguous and do something.  The point is, it is not openssl that is doing that.  

From peter.sylvester at edelweb.fr  Wed Nov 23 14:41:56 2016
From: peter.sylvester at edelweb.fr (Peter Sylvester Edelweb)
Date: Wed, 23 Nov 2016 14:41:56 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479908025.8937.74.camel@infradead.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
Message-ID: <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>

On 11/23/2016 02:33 PM, David Woodhouse wrote:
> If I make a new object type which looks like a PKCS#1 RSA key but is
> actually something completely different, it's *already* likely that
> OpenSSL will load that new object as if it was an RSA key in some
> cases.
>

An exemple used by the 'gem' engine.

openssl rsa -in key.pem -text
Private-Key: (4096 bit)
modulus:
    00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f:
    01:39:34:b7:23:93:5a:61:05:af:b1:04:49:8a:68:
 
    95:69:23:21:8d:20:a3:60:e6:e5:65:69:bf:b6:41:
    f2:40:5c:1d:e3:53:15:90:ff:6d:34:26:45:46:b6:
....
   97:f6:7c:f6:0f:5d:d8:59:02:a8:3c:b0:b4:06:2f:
    c7:b7:c7
publicExponent: 65537 (0x10001)
privateExponent: 1 (0x1)
prime1: 44 (0x2c)
prime2: 41 (0x29)
exponent1: 1 (0x1)
exponent2: 1 (0x1)
coefficient: 1 (0x1)

-----BEGIN RSA PRIVATE KEY-----
MIICHwIBAAKCAgEAxNmkJ+oXEAk1eYn8EB8BOTS3I5NaYQWvsQRJimg3roh2YLrs
YI4KljjdJcN8EfvyIKfonUDJSRxn4BNInqq8EErhcG8j+BcO+D178RJVvfoiiA/b
f1ru5rxuRywLKD3875QVvA6quc5V5I7EybEDO+v6yhlEZp3TN+3qSdTHnXZwBB7B
rh8Z7XbF7yWKNIeb3rRgfVUodxA5lYTBM92TRdz48b/NT6eS4+hrPvsFu71vCSQB
zbBWukwzzmIEfzGnzJ2NUwaq1uPC1HmzyqMrS90YVdZpTA8yTOVys2HXrUsguTD+
nCTgCizPBYUQe4iYmAgznTPpZ3KHiWGu2Il5lQRzrDcbOqtfvnon8ELqsK7+4QU3
9nNol7BCqPOmcWcT8Kx80qq11AKQYFEX5OygzI+Qp/F1o4oTlIs5/FFtBZZQ/T5+
j9DuewkpDfecKioBpVskZzwOnI9834u+CxCSqfYpb1XYD42HxnxLhsTjcYBzTbx+
xQUnpIUD6HxaCLFfNcCDYJSpD7KXHzO+pekyuLig1DNBlhVRa6i3yYj9JpmraW+6
1Sk2CQ7nvyB4FKAeXUFpCzS0eMZ7lPQ9qXlPiPF2eP//Jgg1FPvnQc+MHcGVaSMh
jSCjYOblZWm/tkHyQFwd41MVkP9tNCZFRraX9nz2D13YWQKoPLC0Bi/Ht8cCAwEA
AQIBAQIBLAIBKQIBAQIBAQIBAQ==
-----END RSA PRIVATE KEY-----

From dwmw2 at infradead.org  Wed Nov 23 14:49:23 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 14:49:23 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <20161123.152106.1226513754734735097.levitte@openssl.org>
References: <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <20161123.152106.1226513754734735097.levitte@openssl.org>
Message-ID: <1479912563.8937.78.camel@infradead.org>

On Wed, 2016-11-23 at 15:21 +0100, Richard Levitte wrote:
> In message <1479908025.8937.74.camel at infradead.org> on Wed, 23 Nov 2016 13:33:45 +0000, David Woodhouse <dwmw2 at infradead.org> said:
> 
> dwmw2> On Wed, 2016-11-23 at 13:13 +0000, Salz, Rich wrote:
> dwmw2> > > But, what I get from you is "what if a octet stream matches two different
> dwmw2> > > ASN.1 types?? Is that it?
> dwmw2> > 
> dwmw2> > Yes among others.? How do you know it will *never* happen?
> dwmw2> 
> dwmw2> Because if anyone tries to invent yet *another* ASN.1 form for storing
> dwmw2> keys, I am going to personally visit them in the small hours and stick
> dwmw2> a bat up their nightshirt?
> 
> (let's keep the heat down, shall we?)

You're no fun :)

> dwmw2> Hopefully we don't need to add completely new ones; we can use the
> dwmw2> existing PKCS#8 and PKCS#12 containers for new things.
> dwmw2> 
> dwmw2> But even if a new form is invented which is ambiguous with existing
> dwmw2> forms, that's OK too. We don't support 'detection' of that new format
> dwmw2> by its ASN.1 structure. It'll be PEM-only like the TSS blobs are unless
> dwmw2> the type is explicitly specified.
> 
> Errr...? Now I'm confused.? Wasn't that (explicit type spec) exactly
> what you didn't want to see, no matter if the file was PEM or raw DER?

I do not want to see it for *reasonable* file types which are in
*common* use?. Users should be able to just give the filename to the
application, and expect it to Just Work.

Invent something new and esoteric and stupid, and I don't care about
that as much. I might have been joking about visiting you in the small
hours, but I'm *not* going to tell applications that they have to
accept your format automatically, and that they can't make users jump
through hoops to explicitly specify it.

-- 
dwmw2

? And I'm still more than happy to take input on which file types meet
  that definition, and adjust my draft accordingly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/e9b74c69/attachment.bin>

From James.Bottomley at HansenPartnership.com  Wed Nov 23 15:23:09 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 23 Nov 2016 07:23:09 -0800
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479898410.8937.62.camel@infradead.org>
References: <1479889418.8937.54.camel@infradead.org>
 <20161123.095617.817714375930121040.levitte@openssl.org>
 <1479894913.8937.58.camel@infradead.org>
 <20161123.114734.2150320044696719276.levitte@openssl.org>
 <1479898410.8937.62.camel@infradead.org>
Message-ID: <1479914589.2417.7.camel@HansenPartnership.com>

On Wed, 2016-11-23 at 10:53 +0000, David Woodhouse wrote:
> On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote:
> > 
> > Right...
> > 
> > But then, embedding everything in an OCTET STRING isn't exactly a
> > novel idea either.  How do we discern a DER encoded TSS KEY BLOB 
> > from whatever else that had the same "novel" idea? An OCTET STRING 
> > is an OCTET STRING is an OCTET STRING...  See the dragons hovering 
> > over there? ;-)
> 
> We don't. Crap like that is auto-detected in PEM form only. And yes, 
> it *really* should have used the TssBlob structure, not just the 
> OCTET STRING.

Well, not that I'm advocating doing this, but for TPM keys we actually
can.  The binary content is recognisable even if it just contains a
TPM_KEY12 structure.  The first two bytes are a fixed tag, the second
two must be zero and then we have a set of flags and length fields with
fairly restricted value ranges.  The encrypted private key, authority
and hashes are at the end, so there's an effective and quite long
header at the beginning.  For an RSA2048 key, the structure will always
be 559 bytes long as well.

However, to get back to the plan: you want an additional "do I
recognise this PEM" file callback instead of a "try this bio" one.  I
can code that up and see what it looks like.

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/dfed90fb/attachment-0001.bin>

From levitte at openssl.org  Wed Nov 23 15:27:59 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 16:27:59 +0100 (CET)
Subject: [openssl-dev] STORE (was: [RFC 0/2] Proposal for seamless
 handling of TPM based RSA keys in openssl)
In-Reply-To: <3d837eb338bb47a68938676967ed1092@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <2360f57bb7504a328e5517ac92e19427@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.153218.494728264715626786.levitte@openssl.org>
 <3d837eb338bb47a68938676967ed1092@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161123.162759.986555832386191027.levitte@openssl.org>

[subject change]

In message <3d837eb338bb47a68938676967ed1092 at usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 14:41:14 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > Essentially, you're suggesting that we split out the matching part of the d2i
rsalz> > functions and put that to good use.  Or do you have some other idea, along
rsalz> > the lines if magic?
rsalz> 
rsalz> NO.  I am suggesting add one new routine that tries varies
rsalz> "convert to native" and returns which conversion worked.  And
rsalz> then another new routine that takes that return value and calls
rsalz> that conversion routine directly.  The cost of doing this is
rsalz> one extra d2i.  By the application.  And that first routine
rsalz> should ideally return a bitmask of all functions that succeeded
rsalz> so that handling ambiguities are built-in to the API.

Ok, I hear you, and this can be done.  However, since this is in STORE
terms, it will have to be a STORE API thing.  Not all URIs will give
you a DER blob to fiddle with at your heart's content, some of them
will just give you a key referense (which is best stored in a
EVP_PKEY).  Engine keys stored in the engine device are the prime
example.

rsalz> > rsalz> Security libraries *should not guess.*
rsalz> > 
rsalz> > Isn't telling the application "we think it's a FOO" guessing?  What's the
rsalz> > application going to do, go "naaaah, methinks it's a BAR" and try to decode
rsalz> > the blob as that (and most probably fail) rather than FOO?
rsalz> 
rsalz> It might.  Or it might throw up its hands and give up.  Or it
rsalz> might check to see if the file is ambiguous and do something.
rsalz> The point is, it is not openssl that is doing that.

Speaking of ambiguity, I was thinking of having my 'file' scheme
loader try all d2i's and having it "throw up its hands" if it found
more than one matching.  STOREerr(..., STORE_R_MABIGUOUS_CONTENT) type
of thing...  The application or users would be left to give some extra
information in the URI.

Cheers,
Richard

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


From dwmw2 at infradead.org  Wed Nov 23 16:43:00 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 16:43:00 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
Message-ID: <1479919380.8937.82.camel@infradead.org>

On Wed, 2016-11-23 at 14:41 +0000, Peter Sylvester Edelweb wrote:
> 
> An exemple used by the 'gem' engine.
> 
> openssl rsa -in key.pem -text
> Private-Key: (4096 bit)
> modulus:
> ??? 00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f:
> ??? 01:39:34:b7:23:93:5a:61:05:af:b1:04:49:8a:68:
> ?
> ??? 95:69:23:21:8d:20:a3:60:e6:e5:65:69:bf:b6:41:
> ??? f2:40:5c:1d:e3:53:15:90:ff:6d:34:26:45:46:b6:
> ....
> ?? 97:f6:7c:f6:0f:5d:d8:59:02:a8:3c:b0:b4:06:2f:
> ??? c7:b7:c7
> publicExponent: 65537 (0x10001)
> privateExponent: 1 (0x1)
> prime1: 44 (0x2c)
> prime2: 41 (0x29)
> exponent1: 1 (0x1)
> exponent2: 1 (0x1)
> coefficient: 1 (0x1)

Oh, that's special :)

FWIW I am perfectly content for applications *not* to automatically
work with such keys. Making the user jump through extra hoops to use
them would be perfectly fine in my book.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/50a8bc23/attachment.bin>

From rsalz at akamai.com  Wed Nov 23 17:00:14 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 Nov 2016 17:00:14 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479919380.8937.82.camel@infradead.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
 <1479919380.8937.82.camel@infradead.org>
Message-ID: <a0a83ad2f35145c293c8c7f4f1642943@usma1ex-dag1mb1.msg.corp.akamai.com>


> FWIW I am perfectly content for applications *not* to automatically work
> with such keys. Making the user jump through extra hoops to use them
> would be perfectly fine in my book.

oh I see.  "Users shouldn't care, it should just work"  But only for some keys.

Part of my I am opposed to guessing. 

From dwmw2 at infradead.org  Wed Nov 23 18:42:29 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 18:42:29 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <a0a83ad2f35145c293c8c7f4f1642943@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
 <1479919380.8937.82.camel@infradead.org>
 <a0a83ad2f35145c293c8c7f4f1642943@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1479926549.8937.84.camel@infradead.org>

On Wed, 2016-11-23 at 17:00 +0000, Salz, Rich wrote:
> 
> > FWIW I am perfectly content for applications *not* to automatically work
> > with such keys. Making the user jump through extra hoops to use them
> > would be perfectly fine in my book.
> 
> oh I see.? "Users shouldn't care, it should just work"? But only for some keys.
> 
> Part of my I am opposed to guessing.

For me it's the other way round. Magically detecting *that* particular
perfectly valid PKCS#1 RSA key is actually intended for the gem engine
would indeed be guessing. It's a bizarre abuse of PKCS#1 and it doesn't
seem reasonable for anyone to "guess" that without explicit direction.

But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
similar files in both DER and PEM forms, for *those* it makes sense for
applications to Just Work. And it shouldn't really involve "guessing".

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161123/5bf4a598/attachment-0001.bin>

From dwmw2 at infradead.org  Wed Nov 23 21:10:26 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Nov 2016 21:10:26 -0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479848342.10701.6.camel@gnutls.org>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <1479829774.8937.41.camel@infradead.org>
 <1479848342.10701.6.camel@gnutls.org>
Message-ID: <0bdd15c372c55318eb20479d8bc3cd35.squirrel@twosheds.infradead.org>


> On Tue, 2016-11-22 at 15:49 +0000, David Woodhouse wrote:
>> On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote:
>> > The more interesting part is when it tries to load files it guesses
>> > are raw DER.? It's currently only trying a few chosen content
>> > types,
>> > I'm happy to add more as time goes.? However, I suspect that
>> > nothing
>> > in your test suite will trigger that part.
>>
>> There's a selection of .der and .p12 files there too.
>>
>> Adding non-ASCII passwords and running in different locales (and
>> stress-testing both the old and the new PKCS#12 BMPstring bugs) is
>> still on my TODO list.
>
> Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> can express the same string in various (different) ways, so they cannot
> be directly used as passwords. I have recently added RFC7613
> "normalization" to gnutls, to address the differences.
>
> https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html

Right. You normalise to NFC, yes? That's what my draft recommends. It's a
shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
better than PKCS#8 :)


-- 
dwmw2


From levitte at openssl.org  Wed Nov 23 21:23:18 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 22:23:18 +0100
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
	based RSA keys in openssl
In-Reply-To: <1479926549.8937.84.camel@infradead.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
 <1479919380.8937.82.camel@infradead.org>
 <a0a83ad2f35145c293c8c7f4f1642943@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479926549.8937.84.camel@infradead.org>
Message-ID: <DEAE711B-E9ED-4F5A-A15B-99D7BD23AFB1@openssl.org>



David Woodhouse <dwmw2 at infradead.org> skrev: (23 november 2016 19:42:29 CET)
>On Wed, 2016-11-23 at 17:00 +0000, Salz, Rich wrote:
>> 
>> > FWIW I am perfectly content for applications *not* to automatically
>work
>> > with such keys. Making the user jump through extra hoops to use
>them
>> > would be perfectly fine in my book.
>> 
>> oh I see.? "Users shouldn't care, it should just work"? But only for
>some keys.
>> 
>> Part of my I am opposed to guessing.
>
>For me it's the other way round. Magically detecting *that* particular
>perfectly valid PKCS#1 RSA key is actually intended for the gem engine
>would indeed be guessing. It's a bizarre abuse of PKCS#1 and it doesn't
>seem reasonable for anyone to "guess" that without explicit direction.
>
>But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
>similar files in both DER and PEM forms, for *those* it makes sense for
>applications to Just Work. And it shouldn't really involve "guessing".

I take that as "recognizing what we decide to support". And as has already been mentioned, we already do that with d2i_AutoPrivatekey. 

Cheers 
Richard 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From levitte at openssl.org  Wed Nov 23 21:33:56 2016
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 23 Nov 2016 22:33:56 +0100
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of
	TPM	based RSA keys in openssl
In-Reply-To: <DEAE711B-E9ED-4F5A-A15B-99D7BD23AFB1@openssl.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
 <1479919380.8937.82.camel@infradead.org>
 <a0a83ad2f35145c293c8c7f4f1642943@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479926549.8937.84.camel@infradead.org>
 <DEAE711B-E9ED-4F5A-A15B-99D7BD23AFB1@openssl.org>
Message-ID: <6F631F7A-77A6-4924-815D-3D9D5EC82A75@openssl.org>



Richard Levitte <levitte at openssl.org> skrev: (23 november 2016 22:23:18 CET)
>
>
>David Woodhouse <dwmw2 at infradead.org> skrev: (23 november 2016 19:42:29
>CET)
>>On Wed, 2016-11-23 at 17:00 +0000, Salz, Rich wrote:
>>> 
>>> > FWIW I am perfectly content for applications *not* to
>automatically
>>work
>>> > with such keys. Making the user jump through extra hoops to use
>>them
>>> > would be perfectly fine in my book.
>>> 
>>> oh I see.? "Users shouldn't care, it should just work"? But only for
>>some keys.
>>> 
>>> Part of my I am opposed to guessing.
>>
>>For me it's the other way round. Magically detecting *that* particular
>>perfectly valid PKCS#1 RSA key is actually intended for the gem engine
>>would indeed be guessing. It's a bizarre abuse of PKCS#1 and it
>doesn't
>>seem reasonable for anyone to "guess" that without explicit direction.
>>
>>But for the sane and common cases of PKCS#1, PKCS#8, PKCS#12 and
>>similar files in both DER and PEM forms, for *those* it makes sense
>for
>>applications to Just Work. And it shouldn't really involve "guessing".
>
>I take that as "recognizing what we decide to support". And as has
>already been mentioned, we already do that with d2i_AutoPrivatekey. 

That being said, though, your recommendation should probably specify (after discussing it) exactly what keys, certs and so on should be supported. Otherwise, everyone will have a slightly different idea of what's reasonable and you will end up in the same space as today... 

Cheers 
Richard 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From dwmw2 at infradead.org  Thu Nov 24 13:20:31 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 24 Nov 2016 13:20:31 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of
	TPM	based RSA keys in openssl
In-Reply-To: <6F631F7A-77A6-4924-815D-3D9D5EC82A75@openssl.org>
References: <20161122.184639.797476776722171891.levitte@openssl.org>
 <1479837377.8937.50.camel@infradead.org>
 <021a5d5b885845f5ab79c4420232e415@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161123.000341.1937900079739030126.levitte@openssl.org>
 <c5e2f2ebdd9c42be840c34cdbb7bf3bb@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479908025.8937.74.camel@infradead.org>
 <277e3ae0-5528-5d13-63f8-6ac084dd58a7@edelweb.fr>
 <1479919380.8937.82.camel@infradead.org>
 <a0a83ad2f35145c293c8c7f4f1642943@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1479926549.8937.84.camel@infradead.org>
 <DEAE711B-E9ED-4F5A-A15B-99D7BD23AFB1@openssl.org>
 <6F631F7A-77A6-4924-815D-3D9D5EC82A75@openssl.org>
Message-ID: <1479993631.8937.91.camel@infradead.org>

On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote:
> That being said, though, your recommendation should probably specify
> (after discussing it) exactly what keys, certs and so on should be
> supported. Otherwise, everyone will have a slightly different idea of
> what's reasonable and you will end up in the same space as today...?

Oh $DEITY yes, that's the whole point. And I don't think I've left much
ambiguity there. As ever, suggestions for improvement would be most
welcome...

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#rfc.section.4.1

4.1.  File name

   Many applications support the use of certificates and private keys
   stored in files on the file system.  Such applications MUST support
   the use of files in any of the formats mandated in Section 5, in both
   PEM and DER containers.

   Applications MUST NOT require the user to provide any additional
   hints regarding the contents of the file, such as whether the
   contents are in PEM or DER format.  This MUST be determined by the
   application itself, automatically.

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#formats

5.  File formats

   ...

   Applications MUST accept all of the formats below without requiring
   any additional information from the user or the configuration.  Where
   an application has an existing "key format" or similar option which
   has historically been required to disambiguate between formats
   (either the formats below or between PEM and DER), application SHOULD
   NOT document this use of that legacy option as current practice, and
   SHOULD default to working it out automatically.  Application authors
   who cannot achieve this SHOULD consider taking up goat farming, and
   never touching a cryptographic application again in their life.

5.1.  PKCS#1 and other native ASN.1 encodings

   Applications MUST support unencrypted private keys:

   o  RSA keys in PKCS#1 form as defined by [RFC2437]
   o  DSA keys in the ASN.1 form defined by OpenSSL and documented in
      Appendix B (if DSA keys are supported at all)
   o  ECDSA keys in the form defined by [RFC5915]
   o  EdDSA keys in the form defined by [I-D.ietf-curdle-pkix]

5.2.  PKCS#8

   Applications MUST support keys stored in PKCS#8 form as defined in
   [RFC5208] for all key types.  Applications MUST support unencypted
   PKCS#8 objects, as well as those which are encrypted in various forms
   as discussed in Section 6.1.

   Applications MAY support the updated version of PKCS#8 is defined in
   [RFC5958]. ...

5.3.  PKCS#12

   Applications MUST support the use of certificates and keys from
   PKCS#12 objects ([RFC7292]), encrypted with any of the the methods
   mandated in Section 6.1.  Applications MUST support the use of at
   least SHA1 and SHA256 HMAC, and SHOULD support other HMAC algorithms
   which become common.

6.  Private keys

6.1.  Encryption

   Applications MUST support the encrypted PEM files in the form based
   on [RFC1423] which is commonly used by historical versions of
   OpenSSL, with at least the DES-EDE3-CBC, AES-128-CBC and AES-256-CBC
   modes.

   For PKCS#12 [RFC7292] and PKCS#8 [RFC5208] formats, applications MUST
   support reading objects stored with the following encryption methods:

   o  PBES1 pbeWithMD5AndDES-CBC [RFC2898]
   o  PBES1 pbeWithSHA1And3-KeyTripleDES-CBC [RFC7292]
   o  PBES2 AES-128-CBC (OID: 2.16.840.1.101.3.4.1.2) [RFC2898]
   o  PBES2 AES-256-CBC (OID: 2.16.840.1.101.3.4.1.42) [RFC2898]

   The weak methods included in the above list are unfortunately still
   commonplace, and thus clients need to keep supporting them as noted
   in Section 11.  However, applications MAY emit a warning to the user
   when weak (or no) encryption is used, and MAY require an additional
   configuration directive to enable the use of weakly-encrypted and
   unencrypted keys.

   The presence of these algorithms in the list is not in any way to be
   taken as approval for tools to continue creating objects in such
   forms.  Except for a brief discussion in Section 6.3. the creation of
   private keys is outside the scope of this document.

   ...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161124/21c76a68/attachment.bin>

From doctor at doctor.nl2k.ab.ca  Thu Nov 24 13:58:32 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Thu, 24 Nov 2016 06:58:32 -0700
Subject: [openssl-dev] Still seeing openssl 1.0.2 Daily snap issue
Message-ID: <20161124135832.GA87939@doctor.nl2k.ab.ca>

Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value -1, received 0
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value -1, received 0
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161124/test
*** Error code 1

Stop.
make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161124
root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20161124 # exit
exit

Script done on Thu Nov 24 05:39:49 2016

Please fix

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2016 and Happy New Year 2017

From levitte at openssl.org  Thu Nov 24 14:16:51 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 24 Nov 2016 15:16:51 +0100 (CET)
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <1479993631.8937.91.camel@infradead.org>
References: <DEAE711B-E9ED-4F5A-A15B-99D7BD23AFB1@openssl.org>
 <6F631F7A-77A6-4924-815D-3D9D5EC82A75@openssl.org>
 <1479993631.8937.91.camel@infradead.org>
Message-ID: <20161124.151651.400732908561154012.levitte@openssl.org>

In message <1479993631.8937.91.camel at infradead.org> on Thu, 24 Nov 2016 13:20:31 +0000, David Woodhouse <dwmw2 at infradead.org> said:

dwmw2> On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote:
dwmw2> > That being said, though, your recommendation should probably specify
dwmw2> > (after discussing it) exactly what keys, certs and so on should be
dwmw2> > supported. Otherwise, everyone will have a slightly different idea of
dwmw2> > what's reasonable and you will end up in the same space as today...?
dwmw2> 
dwmw2> Oh $DEITY yes, that's the whole point. And I don't think I've left much
dwmw2> ambiguity there. As ever, suggestions for improvement would be most
dwmw2> welcome...
<snip>
dwmw2> http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#formats
dwmw2> 
dwmw2> 5.  File formats
dwmw2> 
dwmw2>    ...
...

D'oh, I feel silly now.

Cheers,
Richard

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

From dwmw2 at infradead.org  Thu Nov 24 15:33:47 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 24 Nov 2016 15:33:47 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <CAJU7zaJR9P1U1XUnoGY24q0LYX=1oa53-J8dEBNdUrome_LACw@mail.gmail.com>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <1479829774.8937.41.camel@infradead.org>
 <1479848342.10701.6.camel@gnutls.org>
 <0bdd15c372c55318eb20479d8bc3cd35.squirrel@twosheds.infradead.org>
 <CAJU7zaJR9P1U1XUnoGY24q0LYX=1oa53-J8dEBNdUrome_LACw@mail.gmail.com>
Message-ID: <1480001627.8937.93.camel@infradead.org>

On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > > Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> > > can express the same string in various (different) ways, so they cannot
> > > be directly used as passwords. I have recently added RFC7613
> > > "normalization" to gnutls, to address the differences.
> > > 
> > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > 
> > Right. You normalise to NFC, yes? That's what my draft recommends. It's a
> > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > better than PKCS#8 :)
> 
> NFC normalization is one step of RFC7613. I think recommending RFC7613
> is better than making any recommendation.

Hmmm.... I'd be happier if RFC7613 had any mention of using its
profiles for key derivation. (And even happier if the PKCS#12 and
PKCS#8 standards mandated its use!)

This is really something that should be required of the software which
*creates* the key file. I've tried to limit my draft to the *use* of
existing files ? but on the plus side, that means I can say things like
"try X and if that doesn't work try Y", at least for the file
decryption, if not for hardware.

So sure, if there is existing software which is *creating* key files
and using the rules in RFC7613 when it does so, then it makes sense for
me to suggest that.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161124/db436f2f/attachment.bin>

From doctor at doctor.nl2k.ab.ca  Fri Nov 25 07:46:37 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Fri, 25 Nov 2016 00:46:37 -0700
Subject: [openssl-dev] Still problems with openssl 1.0.2 snapshot
Message-ID: <20161125074637.GA49089@doctor.nl2k.ab.ca>

ALL OCSP TESTS SUCCESSFUL
Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value -1, received 0
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value -1, received 0
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161125/test
*** Error code 1

Stop.
make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161125

Please fix
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2016 and Happy New Year 2017

From dwmw2 at infradead.org  Fri Nov 25 10:33:41 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 25 Nov 2016 10:33:41 +0000
Subject: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
In-Reply-To: <CAJU7zaLBSeYcYQEc05hrC+jyuRyq+PtJu8UursiXrAvc9WVw2A@mail.gmail.com>
References: <1479820158.8937.29.camel@infradead.org>
 <20161122.141856.1869335431570395500.levitte@openssl.org>
 <1479823032.8937.37.camel@infradead.org>
 <20161122.161415.1555282309472446656.levitte@openssl.org>
 <1479829774.8937.41.camel@infradead.org>
 <1479848342.10701.6.camel@gnutls.org>
 <0bdd15c372c55318eb20479d8bc3cd35.squirrel@twosheds.infradead.org>
 <CAJU7zaJR9P1U1XUnoGY24q0LYX=1oa53-J8dEBNdUrome_LACw@mail.gmail.com>
 <1480001627.8937.93.camel@infradead.org>
 <CAJU7zaLBSeYcYQEc05hrC+jyuRyq+PtJu8UursiXrAvc9WVw2A@mail.gmail.com>
Message-ID: <1480070021.8937.98.camel@infradead.org>

On Fri, 2016-11-25 at 08:54 +0100, Nikos Mavrogiannopoulos wrote:
> On Thu, Nov 24, 2016 at 4:33 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote:
> > > On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > > > > Locales is not the only thing you have to worry about. UTF-8 and UTF-16
> > > > > can express the same string in various (different) ways, so they cannot
> > > > > be directly used as passwords. I have recently added RFC7613
> > > > > "normalization" to gnutls, to address the differences.
> > > > > 
> > > > > https://lists.gnupg.org/pipermail/gnutls-devel/2016-November/008240.html
> > > > 
> > > > Right. You normalise to NFC, yes? That's what my draft recommends. It's a
> > > > shame that PKCS#12 doesn't *mandate* that... but hey, at least it does
> > > > better than PKCS#8 :)
> > > 
> > > NFC normalization is one step of RFC7613. I think recommending RFC7613
> > > is better than making any recommendation.
> > 
> > Hmmm.... I'd be happier if RFC7613 had any mention of using its
> > profiles for key derivation. (And even happier if the PKCS#12 and
> > PKCS#8 standards mandated its use!)
> 
> They predate it by several years. At the time they were published very
> few could conceive how UTF-8/unicode would look like.

The original PKCS documents predated the publication of Unicode by a
few months in 1991. Sure, *NOBODY* could have predicted in early 1991
that some kind of coherent approach to character sets would be a good
idea ?

And yes, UTF-8 came later (1992, I believe?) but isn't necessary. Even
the original RSA PKCS#12?uses Unicode, and specifies the use of
BMPString for key derivation. Although it neglected to specify any
normalisation. (Did normalisation exist, at that point?)

Even by the time PKCS#5 was brought into the IETF fold in 2000
(RFC2898) it was fairly clear that?you kind of had to agree on the
mapping of password characters to numbers, and it was "recommended that
applications follow some common text encoding rules. ASCII and UTF-8
[27] are two possibilities."

I know, it's useless to look back and, with the benefit of hindsight,
criticise the original standards. I'm mostly just reacting to your
"excuse". And standards *do* evolve. PKCS#8 was updated again in
RFC5958 and even then it could have been mandated that UTF-8/NFC be
used for key derivation.

> > This is really something that should be required of the software which
> > *creates* the key file. I've tried to limit my draft to the *use* of
> > existing files ? but on the plus side, that means I can say things like
> > "try X and if that doesn't work try Y", at least for the file
> > decryption, if not for hardware.
> > So sure, if there is existing software which is *creating* key files
> > and using the rules in RFC7613 when it does so, then it makes sense for
> > me to suggest that.
> 
> gnutls after 3.5.7 will be using RFC7613 for all types of passwords.

Including *rejecting* passwords such as '<my cat is a &#x9;by>' as
shown in example 17 in ?4.3? Or do we end up in a situation where
applications which are *loading* key files should attempt such a
password anyway, even though it *shouldn't* work?

And how about PKCS#12? RFC7613 mandates UTF-8 but we just ignore that
bit and do UTF-16 instead for PKCS#12, with the rest of the RFC7613
rules?

-- 
dwmw2

? https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161125/d9cd2721/attachment.bin>

From rsalz at akamai.com  Sat Nov 26 00:31:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 26 Nov 2016 00:31:03 +0000
Subject: [openssl-dev] Still problems with openssl 1.0.2 snapshot
In-Reply-To: <20161125074637.GA49089@doctor.nl2k.ab.ca>
References: <20161125074637.GA49089@doctor.nl2k.ab.ca>
Message-ID: <d209a9a1843c4f6ca0b72a5de4f02893@usma1ex-dag1mb1.msg.corp.akamai.com>

How do you configure?

> test_dtls1_not_bleeding failed: expected return value -1, received 0
> ** test_dtls1_not_bleeding failed **
...
> 4 tests failed
> *** Error code 1



From doctor at doctor.nl2k.ab.ca  Sat Nov 26 12:25:52 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sat, 26 Nov 2016 05:25:52 -0700
Subject: [openssl-dev] Still showing openssl 1.0.2 snapshot issue
Message-ID: <20161126122552.GA19838@doctor.nl2k.ab.ca>

How long for this to get fixed?

../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value -1, received 0
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value -1, received 0
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161126/test
*** Error code 1

Stop.
make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161126

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2016 and Happy New Year 2017

From rsalz at akamai.com  Sat Nov 26 13:58:46 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 26 Nov 2016 13:58:46 +0000
Subject: [openssl-dev] Still showing openssl 1.0.2 snapshot issue
In-Reply-To: <20161126122552.GA19838@doctor.nl2k.ab.ca>
References: <20161126122552.GA19838@doctor.nl2k.ab.ca>
Message-ID: <8763b8210d19494bab40e3d7ea390ae5@usma1ex-dag1mb1.msg.corp.akamai.com>


> How long for this to get fixed?
> 
> ../util/shlib_wrap.sh ./heartbeat_test

I posted yesterday, what's your config.  I standard config/make does not do this for me.

From openssl at roumenpetrov.info  Sun Nov 27 08:11:09 2016
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sun, 27 Nov 2016 10:11:09 +0200
Subject: [openssl-dev] Still showing openssl 1.0.2 snapshot issue
In-Reply-To: <8763b8210d19494bab40e3d7ea390ae5@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20161126122552.GA19838@doctor.nl2k.ab.ca>
 <8763b8210d19494bab40e3d7ea390ae5@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <583A951D.9030401@roumenpetrov.info>

Salz, Rich wrote:
> [SNIP]
> I posted yesterday, what's your config. I standard config/make does 
> not do this for me.
For instance:
CONFIGURE_ARGS=--prefix=... -DOPENSSL_NO_BUF_FREELISTS shared no-ssl2 
no-ssl3 zlib-dynamic enable-gost enable-unit-test linux-x86_64

Roumen


From doctor at doctor.nl2k.ab.ca  Sun Nov 27 13:27:54 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sun, 27 Nov 2016 06:27:54 -0700
Subject: [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue
Message-ID: <20161127132754.GA9061@doctor.nl2k.ab.ca>

Can you get his fixed?

../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value -1, received 0
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value -1, received 0
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127/test
*** Error code 1

Stop.
make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2016 and Happy New Year 2017

From rsalz at akamai.com  Sun Nov 27 14:21:25 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 27 Nov 2016 14:21:25 +0000
Subject: [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue
In-Reply-To: <20161127132754.GA9061@doctor.nl2k.ab.ca>
References: <20161127132754.GA9061@doctor.nl2k.ab.ca>
Message-ID: <3bbd178a07b04948acbbef1b4c084bfb@usma1ex-dag1mb1.msg.corp.akamai.com>


> Can you get his fixed?
> 
> ../util/shlib_wrap.sh ./heartbeat_test
> test_dtls1_not_bleeding failed: expected return value -1, received 0
> ** test_dtls1_not_bleeding failed **

Again:  How are you configuring ?

It does not fail for me.

From matt at openssl.org  Mon Nov 28 09:51:25 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 28 Nov 2016 09:51:25 +0000
Subject: [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue
In-Reply-To: <20161127132754.GA9061@doctor.nl2k.ab.ca>
References: <20161127132754.GA9061@doctor.nl2k.ab.ca>
Message-ID: <2c9842ee-d7dc-51fc-089e-5736510beb6a@openssl.org>



On 27/11/16 13:27, The Doctor wrote:
> Can you get his fixed?
> 
> ../util/shlib_wrap.sh ./heartbeat_test
> test_dtls1_not_bleeding failed: expected return value -1, received 0
> ** test_dtls1_not_bleeding failed **
> --------
> test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
> ** test_dtls1_not_bleeding_empty_payload failed **
> --------
> test_tls1_not_bleeding failed: expected return value -1, received 0
> ** test_tls1_not_bleeding failed **
> --------
> test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
> ** test_tls1_not_bleeding_empty_payload failed **
> --------
> 4 tests failed
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127/test
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127
> 

Fix here:

https://github.com/openssl/openssl/pull/2010

Matt

From tshort at akamai.com  Mon Nov 28 14:17:21 2016
From: tshort at akamai.com (Short, Todd)
Date: Mon, 28 Nov 2016 14:17:21 +0000
Subject: [openssl-dev] Still showing openssl 1.0.2 snapshot issue
In-Reply-To: <583A951D.9030401@roumenpetrov.info>
References: <20161126122552.GA19838@doctor.nl2k.ab.ca>
 <8763b8210d19494bab40e3d7ea390ae5@usma1ex-dag1mb1.msg.corp.akamai.com>
 <583A951D.9030401@roumenpetrov.info>
Message-ID: <24F0D730-1BFC-47F8-8543-67B95D4B11DB@akamai.com>

FYI: The use of -DOPENSSL_NO_BUF_FREELISTS to config or Configure is not recommended, use the proper configuration option:

no-buf-freelists

--
-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 Nov 27, 2016, at 3:11 AM, Roumen Petrov <openssl at roumenpetrov.info<mailto:openssl at roumenpetrov.info>> wrote:

Salz, Rich wrote:
[SNIP]
I posted yesterday, what's your config. I standard config/make does not do this for me.
For instance:
CONFIGURE_ARGS=--prefix=... -DOPENSSL_NO_BUF_FREELISTS shared no-ssl2 no-ssl3 zlib-dynamic enable-gost enable-unit-test linux-x86_64

Roumen

--
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/20161128/4da402de/attachment.html>

From uri at ll.mit.edu  Mon Nov 28 20:11:59 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 28 Nov 2016 20:11:59 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
Message-ID: <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>

    Mac OS X 10.11.6, Xcode-8.1. 
    
    $ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc
    Configuring OpenSSL version 1.1.1-dev (0x10101000L)
        no-asan         [default]  OPENSSL_NO_ASAN
        no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
        no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
        no-egd          [default]  OPENSSL_NO_EGD
        no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
        no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
        no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
        no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
        no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
        no-msan         [default]  OPENSSL_NO_MSAN
        no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
        no-sctp         [default]  OPENSSL_NO_SCTP
        no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
        no-ssl3         [default]  OPENSSL_NO_SSL3
        no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
        no-tls1_3       [default]  OPENSSL_NO_TLS1_3
        no-ubsan        [default]  OPENSSL_NO_UBSAN
        no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
        no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
        no-zlib-dynamic [default] 
    Configuring for darwin64-x86_64-cc
    
    PERL          =/opt/local/bin/perl5.24
    PERLVERSION   =5.24.0 for darwin-thread-multi-2level
    HASHBANGPERL  =/usr/bin/env perl
    CC            =clang
    CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
    CXX           =clang++
    CXXFLAG       =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
    DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
    EX_LIBS       =-lz 
    $ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 enable-rc5 enable-tls1_3 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc
    Configuring OpenSSL version 1.1.1-dev (0x10101000L)
        no-asan         [default]  OPENSSL_NO_ASAN
        no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
        no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
        no-egd          [default]  OPENSSL_NO_EGD
        no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
        no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
        no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
        no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
        no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
        no-msan         [default]  OPENSSL_NO_MSAN
        no-sctp         [default]  OPENSSL_NO_SCTP
        no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
        no-ssl3         [default]  OPENSSL_NO_SSL3
        no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
        no-ubsan        [default]  OPENSSL_NO_UBSAN
        no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
        no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
        no-zlib-dynamic [default] 
    Configuring for darwin64-x86_64-cc
    
    PERL          =/opt/local/bin/perl5.24
    PERLVERSION   =5.24.0 for darwin-thread-multi-2level
    HASHBANGPERL  =/usr/bin/env perl
    CC            =clang
    CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
    CXX           =clang++
    CXXFLAG       =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
    DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
    EX_LIBS       =-lz 
    $ make depend && make clean && make -j 4 all && make test && make install
    . . . . .
    
    ../test/recipes/80-test_ssl_new.t .......... 15/19 
        #   Failed test 'running ssl_test 19-mac-then-encrypt.conf'
        #   at ../test/recipes/80-test_ssl_new.t line 121.
        # Looks like you failed 1 test of 3.
    
    #   Failed test 'Test configuration 19-mac-then-encrypt.conf'
    #   at ../test/recipes/80-test_ssl_new.t line 87.
    # Looks like you failed 1 test of 19.
    ../test/recipes/80-test_ssl_new.t .......... Dubious, test returned 1 (wstat 256, 0x100)
    Failed 1/19 subtests 
    . . . . .
    

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161128/211b6696/attachment-0001.bin>

From kgoldman at us.ibm.com  Mon Nov 28 20:16:57 2016
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Mon, 28 Nov 2016 15:16:57 -0500
Subject: [openssl-dev] Openssl 1.1 port - hash state serializing
Message-ID: <o1i3bc$82m$2@blaine.gmane.org>

There was no answer on the 'users' list, so this is perhaps now a 
feature request.

Is there a possibility of getting this function?

~~

I have a simulation of a hardware device that has the following 
characteristics:

- does hashing functions
- resource constrained
- multi-user

Therefore, a typical pattern is that one application starts a digest 
calculation, then the hash state must get swapped out for another user.

In 1.0, I did this by (cheating) serializing the hash state to swap out, 
than deserializing to swap back in.  This required looking inside the 
hash state structure.  I know it wasn't portable across versions, but 
the structure was pretty stable.

Is there a way to do this in 1.1?  Can one be added?


From appro at openssl.org  Mon Nov 28 21:26:23 2016
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 28 Nov 2016 22:26:23 +0100
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
Message-ID: <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>

>     Mac OS X 10.11.6, Xcode-8.1. 
>     
>     $ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc
>     Configuring OpenSSL version 1.1.1-dev (0x10101000L)
>         no-asan         [default]  OPENSSL_NO_ASAN
>         no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
>         no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>         no-egd          [default]  OPENSSL_NO_EGD
>         no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
>         no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
>         no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
>         no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
>         no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>         no-msan         [default]  OPENSSL_NO_MSAN
>         no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>         no-sctp         [default]  OPENSSL_NO_SCTP
>         no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
>         no-ssl3         [default]  OPENSSL_NO_SSL3
>         no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
>         no-tls1_3       [default]  OPENSSL_NO_TLS1_3
>         no-ubsan        [default]  OPENSSL_NO_UBSAN
>         no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
>         no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
>         no-zlib-dynamic [default] 
>     Configuring for darwin64-x86_64-cc
>     
>     PERL          =/opt/local/bin/perl5.24
>     PERLVERSION   =5.24.0 for darwin-thread-multi-2level
>     HASHBANGPERL  =/usr/bin/env perl
>     CC            =clang
>     CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
>     CXX           =clang++
>     CXXFLAG       =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
>     DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
>     EX_LIBS       =-lz 
>     $ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 enable-rc5 enable-tls1_3 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc
>     Configuring OpenSSL version 1.1.1-dev (0x10101000L)
>         no-asan         [default]  OPENSSL_NO_ASAN
>         no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
>         no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>         no-egd          [default]  OPENSSL_NO_EGD
>         no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
>         no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
>         no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
>         no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
>         no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>         no-msan         [default]  OPENSSL_NO_MSAN
>         no-sctp         [default]  OPENSSL_NO_SCTP
>         no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
>         no-ssl3         [default]  OPENSSL_NO_SSL3
>         no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
>         no-ubsan        [default]  OPENSSL_NO_UBSAN
>         no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
>         no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
>         no-zlib-dynamic [default] 
>     Configuring for darwin64-x86_64-cc
>     
>     PERL          =/opt/local/bin/perl5.24
>     PERLVERSION   =5.24.0 for darwin-thread-multi-2level
>     HASHBANGPERL  =/usr/bin/env perl
>     CC            =clang
>     CFLAG         =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
>     CXX           =clang++
>     CXXFLAG       =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
>     DEFINES       =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM
>     EX_LIBS       =-lz 
>     $ make depend && make clean && make -j 4 all && make test && make install
>     . . . . .
>     
>     ../test/recipes/80-test_ssl_new.t .......... 15/19 
>         #   Failed test 'running ssl_test 19-mac-then-encrypt.conf'
>         #   at ../test/recipes/80-test_ssl_new.t line 121.
>         # Looks like you failed 1 test of 3.
>     
>     #   Failed test 'Test configuration 19-mac-then-encrypt.conf'
>     #   at ../test/recipes/80-test_ssl_new.t line 87.
>     # Looks like you failed 1 test of 19.
>     ../test/recipes/80-test_ssl_new.t .......... Dubious, test returned 1 (wstat 256, 0x100)
>     Failed 1/19 subtests 
>     . . . . .

I can't reproduce this. But on the other hand I don't have previous
installation on --prefix. I mean I would guess this is because test
program picks shared libraries at --prefix locations instead of just
built ones, and those don't recognize 19-mac-then-encrypt.conf options.
Originally shlib_wrap.sh had DYLD_INSERT_LIBRARIES to make it work, but
it appears to be gone now... You should be able to confirm this by
temporarily renaming --prefix location and running 'make test' or
forcing install without testing...


From uri at ll.mit.edu  Mon Nov 28 21:58:04 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 28 Nov 2016 21:58:04 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
Message-ID: <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>

>I can't reproduce this. But on the other hand I don't have previous
    >installation on --prefix. 

But did you add ?enable-tls1_3? to your config?

    >I mean I would guess this is because test
    >program picks shared libraries at --prefix locations instead of just
    >built ones, and those don't recognize 19-mac-then-encrypt.conf options.
    >Originally shlib_wrap.sh had DYLD_INSERT_LIBRARIES to make it work, but
    >it appears to be gone now... You should be able to confirm this by
    >temporarily renaming --prefix location and running 'make test' or
    >forcing install without testing...

I forced the install without testing, and then re-ran the entire build and test. I?m getting the very same problem.  I must also say that I?ve been tracking 1.1 branch for a very long time, always using this approach (without even forcing the install ? it did not seem confused regarding what libraries to link against). 

The only thing that changed for this build now was addition of ?enable-tls1_3? config option (and of course, pulling the latest stuff from the master).

Removing ?enable-tls1_3? and reconfiguring makes this error disappear. So I think it?s somewhere in tls1_3 code. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161128/067f4f59/attachment.bin>

From appro at openssl.org  Mon Nov 28 22:28:39 2016
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 28 Nov 2016 23:28:39 +0100
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
 <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
Message-ID: <57bdd0ca-731b-ea65-50b7-fbf03c4207b7@openssl.org>

>> I can't reproduce this. But on the other hand I don't have previous
>     >installation on --prefix. 
> 
> But did you add ?enable-tls1_3? to your config?
> 
>     >I mean I would guess this is because test
>     >program picks shared libraries at --prefix locations instead of just
>     >built ones, and those don't recognize 19-mac-then-encrypt.conf options.
>     >Originally shlib_wrap.sh had DYLD_INSERT_LIBRARIES to make it work, but
>     >it appears to be gone now... You should be able to confirm this by
>     >temporarily renaming --prefix location and running 'make test' or
>     >forcing install without testing...
> 
> I forced the install without testing, and then re-ran the entire build and test. I?m getting the very same problem.  I must also say that I?ve been tracking 1.1 branch for a very long time, always using this approach (without even forcing the install ? it did not seem confused regarding what libraries to link against). 
> 
> The only thing that changed for this build now was addition of ?enable-tls1_3? config option (and of course, pulling the latest stuff from the master).
> 
> Removing ?enable-tls1_3? and reconfiguring makes this error disappear. So I think it?s somewhere in tls1_3 code. ;-)

Oh! Missed that. I was concentrated on the fact that it was reported in
MacOS X context... Since it's not my platform of choice I ran only first
suggested test. But it appears that it's actually not os-specific and
can be reproduced even on Linux. Sorry about misleading the discussion.


From uri at ll.mit.edu  Mon Nov 28 22:33:12 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 28 Nov 2016 22:33:12 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <57bdd0ca-731b-ea65-50b7-fbf03c4207b7@openssl.org>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
 <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
 <57bdd0ca-731b-ea65-50b7-fbf03c4207b7@openssl.org>
Message-ID: <6EC23922-5700-4012-80D3-5776BDEB26BB@ll.mit.edu>

    >> The only thing that changed for this build now was addition of ?enable-tls1_3? config option (and of course, pulling the latest stuff from the master).
    >> 
    >> Removing ?enable-tls1_3? and reconfiguring makes this error disappear. So I think it?s somewhere in tls1_3 code. ;-)
    
    > Oh! Missed that. I was concentrated on the fact that it was reported in
    > MacOS X context... 

?  Well, I had to report what platform the problem occurred on, hadn?t I? ?

    > But it appears that it's actually not os-specific and
    > can be reproduced even on Linux.

Good for me! ?

    > Sorry about misleading the discussion.
    
No problem. And it was good to check the build to ensure that indeed ?enable-tls1_3? was the culprit. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161128/1dff55fa/attachment-0001.bin>

From matt at openssl.org  Mon Nov 28 22:55:34 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 28 Nov 2016 22:55:34 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
 <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
Message-ID: <aef1e513-6942-fbc0-b1bc-fa2336a3613f@openssl.org>



On 28/11/16 21:58, Blumenthal, Uri - 0553 - MITLL wrote:
>> I can't reproduce this. But on the other hand I don't have previous
>     >installation on --prefix. 
> 
> But did you add ?enable-tls1_3? to your config?
> 
>     >I mean I would guess this is because test
>     >program picks shared libraries at --prefix locations instead of just
>     >built ones, and those don't recognize 19-mac-then-encrypt.conf options.
>     >Originally shlib_wrap.sh had DYLD_INSERT_LIBRARIES to make it work, but
>     >it appears to be gone now... You should be able to confirm this by
>     >temporarily renaming --prefix location and running 'make test' or
>     >forcing install without testing...
> 
> I forced the install without testing, and then re-ran the entire build and test. I?m getting the very same problem.  I must also say that I?ve been tracking 1.1 branch for a very long time, always using this approach (without even forcing the install ? it did not seem confused regarding what libraries to link against). 
> 
> The only thing that changed for this build now was addition of ?enable-tls1_3? config option (and of course, pulling the latest stuff from the master).
> 
> Removing ?enable-tls1_3? and reconfiguring makes this error disappear. So I think it?s somewhere in tls1_3 code. ;-)

The problem is in the test. Version negotiation happens before cipher
selection. The test creates a connection which negotiates TLSv1.3. It
then attempts to select a cipher. However no TLSv1.3 ciphers are offered
by the test so the connection aborts. In truth the test is all about
mac-then-encrypt which doesn't apply to TLSv1.3 anyway, so the test
should just disable negotiation of that protocol version.

Matt


From uri at ll.mit.edu  Mon Nov 28 23:00:25 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 28 Nov 2016 23:00:25 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <aef1e513-6942-fbc0-b1bc-fa2336a3613f@openssl.org>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
 <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
 <aef1e513-6942-fbc0-b1bc-fa2336a3613f@openssl.org>
Message-ID: <0AD21E3F-9E18-4F38-BE55-586731143F88@ll.mit.edu>

    > The problem is in the test. Version negotiation happens before cipher
    > selection. The test creates a connection which negotiates TLSv1.3. It
    > then attempts to select a cipher. However no TLSv1.3 ciphers are offered
    > by the test so the connection aborts. In truth the test is all about
    > mac-then-encrypt which doesn't apply to TLSv1.3 anyway, so the test
    > should just disable negotiation of that protocol version.
    
Thanks for explaining! 

Would you be able to push a fix for this test?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161128/0db935f4/attachment.bin>

From matt at openssl.org  Tue Nov 29 09:41:45 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 29 Nov 2016 09:41:45 +0000
Subject: [openssl-dev] Openssl 1.1 port - hash state serializing
In-Reply-To: <o1i3bc$82m$2@blaine.gmane.org>
References: <o1i3bc$82m$2@blaine.gmane.org>
Message-ID: <9a734e37-6ad4-903c-47ca-48544947d3ac@openssl.org>



On 28/11/16 20:16, Ken Goldman wrote:
> There was no answer on the 'users' list, so this is perhaps now a
> feature request.

Please raise feature requests as issues on Github.

Matt

> 
> Is there a possibility of getting this function?
> 
> ~~
> 
> I have a simulation of a hardware device that has the following
> characteristics:
> 
> - does hashing functions
> - resource constrained
> - multi-user
> 
> Therefore, a typical pattern is that one application starts a digest
> calculation, then the hash state must get swapped out for another user.
> 
> In 1.0, I did this by (cheating) serializing the hash state to swap out,
> than deserializing to swap back in.  This required looking inside the
> hash state structure.  I know it wasn't portable across versions, but
> the structure was pretty stable.
> 
> Is there a way to do this in 1.1?  Can one be added?
> 

From matt at openssl.org  Tue Nov 29 09:53:27 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 29 Nov 2016 09:53:27 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <0AD21E3F-9E18-4F38-BE55-586731143F88@ll.mit.edu>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
 <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
 <aef1e513-6942-fbc0-b1bc-fa2336a3613f@openssl.org>
 <0AD21E3F-9E18-4F38-BE55-586731143F88@ll.mit.edu>
Message-ID: <b65b5a56-e4a2-7af9-4cc7-3b644da68d6b@openssl.org>



On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote:
>     > The problem is in the test. Version negotiation happens before cipher
>     > selection. The test creates a connection which negotiates TLSv1.3. It
>     > then attempts to select a cipher. However no TLSv1.3 ciphers are offered
>     > by the test so the connection aborts. In truth the test is all about
>     > mac-then-encrypt which doesn't apply to TLSv1.3 anyway, so the test
>     > should just disable negotiation of that protocol version.
>     
> Thanks for explaining! 
> 
> Would you be able to push a fix for this test?

Fix is in github:

https://github.com/openssl/openssl/pull/2013

Matt


From matt at openssl.org  Tue Nov 29 09:58:50 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 29 Nov 2016 09:58:50 +0000
Subject: [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue
In-Reply-To: <2c9842ee-d7dc-51fc-089e-5736510beb6a@openssl.org>
References: <20161127132754.GA9061@doctor.nl2k.ab.ca>
 <2c9842ee-d7dc-51fc-089e-5736510beb6a@openssl.org>
Message-ID: <2e26a6c7-94af-5206-4691-a6bcb393e162@openssl.org>



On 28/11/16 09:51, Matt Caswell wrote:
> 
> 
> On 27/11/16 13:27, The Doctor wrote:
>> Can you get his fixed?
>>
>> ../util/shlib_wrap.sh ./heartbeat_test
>> test_dtls1_not_bleeding failed: expected return value -1, received 0
>> ** test_dtls1_not_bleeding failed **
>> --------
>> test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0
>> ** test_dtls1_not_bleeding_empty_payload failed **
>> --------
>> test_tls1_not_bleeding failed: expected return value -1, received 0
>> ** test_tls1_not_bleeding failed **
>> --------
>> test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0
>> ** test_tls1_not_bleeding_empty_payload failed **
>> --------
>> 4 tests failed
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127/test
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127
>>
> 
> Fix here:
> 
> https://github.com/openssl/openssl/pull/2010

This has now been pushed so should show up in the next snapshot.

Matt


From James.Bottomley at HansenPartnership.com  Wed Nov 30 15:24:30 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 07:24:30 -0800
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM
 based RSA keys in openssl
Message-ID: <1480519470.2372.2.camel@HansenPartnership.com>

One of the principle problems of using TPM based keys is that there's
no easy way of integrating them with standard file based keys.  This
proposal adds a generic method for handling file based engine keys that
can be loaded as PEM files.  Integration into the PEM loader requires a
BIO based engine API callback which the first patch adds.  The second
patch checks to see if the key can be loaded by any of the present
engines.  Note that this requires that any engine which is to be used
must be present and initialised via openssl.cnf.

I'll also post to this list the patch to openssl_tpm_engine that makes
use if this infrastructure so the integration of the whole can be seen.
 It should also be noted that gnutls has had this functionality since
2012.

The patch was done against 1.0.2h for easier testing and you can try it
and the openssl_tpm_engine out (if you run openSUSE) here:

https://build.opensuse.org/project/show/home:jejb1:Tumbleweed

James

---
v2: make bio callback explicit vi new method rather than overloading
keyid

---

James Bottomley (2):
  engine: add new bio based method for loading engine keys
  pem: load engine keys

 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
 crypto/engine/engine.h   | 17 +++++++++++++++++
 crypto/pem/pem_pkey.c    |  4 ++++
 4 files changed, 60 insertions(+)



From James.Bottomley at HansenPartnership.com  Wed Nov 30 15:26:22 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 07:26:22 -0800
Subject: [openssl-dev] [RFC v2 1/2] engine: add new bio based method for
 loading engine keys
In-Reply-To: <1480519470.2372.2.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
Message-ID: <1480519582.2372.4.camel@HansenPartnership.com>

Some engines have a PEM format for their keys, so add a mechanism
whereby these keys can be read in to EVP_PKEY structures backed by the
engine methods.  The expectation is that each engine that wants to use
this will define its own unique guard tags for the PEM file.

Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
---
 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++++++++++++++++++++++++++++++++++++++
 crypto/engine/engine.h   | 17 +++++++++++++++++
 3 files changed, 56 insertions(+)

diff --git a/crypto/engine/eng_int.h b/crypto/engine/eng_int.h
index 46f163b..1d182c8 100644
--- a/crypto/engine/eng_int.h
+++ b/crypto/engine/eng_int.h
@@ -197,6 +197,7 @@ struct engine_st {
     ENGINE_CTRL_FUNC_PTR ctrl;
     ENGINE_LOAD_KEY_PTR load_privkey;
     ENGINE_LOAD_KEY_PTR load_pubkey;
+    ENGINE_LOAD_KEY_BIO_PTR load_privkey_bio;
     ENGINE_SSL_CLIENT_CERT_PTR load_ssl_client_cert;
     const ENGINE_CMD_DEFN *cmd_defns;
     int flags;
diff --git a/crypto/engine/eng_pkey.c b/crypto/engine/eng_pkey.c
index 23580d9..0eb7d6e 100644
--- a/crypto/engine/eng_pkey.c
+++ b/crypto/engine/eng_pkey.c
@@ -64,6 +64,13 @@ int ENGINE_set_load_privkey_function(ENGINE *e,
     return 1;
 }
 
+int ENGINE_set_load_privkey_bio_function(ENGINE *e,
+					 ENGINE_LOAD_KEY_BIO_PTR load_f)
+{
+    e->load_privkey_bio = load_f;
+    return 1;
+}
+
 int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f)
 {
     e->load_pubkey = loadpub_f;
@@ -88,6 +95,11 @@ ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e)
     return e->load_pubkey;
 }
 
+ENGINE_LOAD_KEY_BIO_PTR ENGINE_get_load_privkey_bio_function(const ENGINE *e)
+{
+    return e->load_privkey_bio;
+}
+
 ENGINE_SSL_CLIENT_CERT_PTR ENGINE_get_ssl_client_cert_function(const ENGINE
                                                                *e)
 {
@@ -184,3 +196,29 @@ int ENGINE_load_ssl_client_cert(ENGINE *e, SSL *s,
     return e->load_ssl_client_cert(e, s, ca_dn, pcert, ppkey, pother,
                                    ui_method, callback_data);
 }
+
+int ENGINE_find_engine_load_key(ENGINE **e, EVP_PKEY **pkey, BIO *bio,
+                                pem_password_cb *cb, void *cb_data)
+{
+    ENGINE *ep;
+    int ret = 0;
+
+    for (ep = ENGINE_get_first(); ep != NULL; ep = ENGINE_get_next(ep)) {
+        if (!ep->load_privkey_bio)
+            continue;
+        if (ep->load_privkey_bio(ep, pkey, bio, cb, cb_data) == 1) {
+            ret = 1;
+            break;
+        }
+
+	/* reset the bio and clear any error */
+	(void)BIO_reset(bio);
+	ERR_clear_error();
+    }
+    if (e)
+        *e = ep;
+    else if (ep)
+        ENGINE_free(ep);
+
+    return ret;
+}
diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h
index bd7b591..022be41 100644
--- a/crypto/engine/engine.h
+++ b/crypto/engine/engine.h
@@ -97,6 +97,7 @@
 # include <openssl/symhacks.h>
 
 # include <openssl/x509.h>
+# include <openssl/pem.h>
 
 #ifdef  __cplusplus
 extern "C" {
@@ -338,6 +339,11 @@ typedef int (*ENGINE_CTRL_FUNC_PTR) (ENGINE *, int, long, void *,
 typedef EVP_PKEY *(*ENGINE_LOAD_KEY_PTR)(ENGINE *, const char *,
                                          UI_METHOD *ui_method,
                                          void *callback_data);
+
+/* Load key from bio if engine recognises the pem guards */
+typedef int (*ENGINE_LOAD_KEY_BIO_PTR)(ENGINE *, EVP_PKEY **,  BIO *,
+				       pem_password_cb *pwd_callback,
+				       void *callback_data);
 typedef int (*ENGINE_SSL_CLIENT_CERT_PTR) (ENGINE *, SSL *ssl,
                                            STACK_OF(X509_NAME) *ca_dn,
                                            X509 **pcert, EVP_PKEY **pkey,
@@ -565,6 +571,8 @@ int ENGINE_set_finish_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR finish_f);
 int ENGINE_set_ctrl_function(ENGINE *e, ENGINE_CTRL_FUNC_PTR ctrl_f);
 int ENGINE_set_load_privkey_function(ENGINE *e,
                                      ENGINE_LOAD_KEY_PTR loadpriv_f);
+int ENGINE_set_load_privkey_bio_function(ENGINE *e,
+					 ENGINE_LOAD_KEY_BIO_PTR loadpriv_f);
 int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f);
 int ENGINE_set_load_ssl_client_cert_function(ENGINE *e,
                                              ENGINE_SSL_CLIENT_CERT_PTR
@@ -611,6 +619,7 @@ ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(const ENGINE *e);
 ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(const ENGINE *e);
 ENGINE_LOAD_KEY_PTR ENGINE_get_load_privkey_function(const ENGINE *e);
 ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e);
+ENGINE_LOAD_KEY_BIO_PTR ENGINE_get_load_privkey_bio_function(const ENGINE *e);
 ENGINE_SSL_CLIENT_CERT_PTR ENGINE_get_ssl_client_cert_function(const ENGINE
                                                                *e);
 ENGINE_CIPHERS_PTR ENGINE_get_ciphers(const ENGINE *e);
@@ -671,6 +680,14 @@ int ENGINE_load_ssl_client_cert(ENGINE *e, SSL *s,
                                 UI_METHOD *ui_method, void *callback_data);
 
 /*
+ * Given a bio, this method iterates over all present engines to
+ * see if any can handle it.  It's functionality depends on the engine
+ * implementing e->load_privkey_bio.
+ */
+int ENGINE_find_engine_load_key(ENGINE **e, EVP_PKEY **pkey, BIO *bio,
+                                pem_password_cb *cb, void *cb_data);
+
+/*
  * This returns a pointer for the current ENGINE structure that is (by
  * default) performing any RSA operations. The value returned is an
  * incremented reference, so it should be free'd (ENGINE_finish) before it is
-- 
2.6.6


From James.Bottomley at HansenPartnership.com  Wed Nov 30 15:27:49 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 07:27:49 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480519470.2372.2.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
Message-ID: <1480519669.2372.6.camel@HansenPartnership.com>

Before trying to process the PEM file, hand it to each of the loaded
engines to see if they recognise the PEM guards.  This uses the new
bio based load key callback, so the engine must be loaded and
implement this callback to be considered.

Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
---
 crypto/pem/pem_pkey.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
index 04d6319..e3737f0 100644
--- a/crypto/pem/pem_pkey.c
+++ b/crypto/pem/pem_pkey.c
@@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x, pem_password_cb *cb,
     int slen;
     EVP_PKEY *ret = NULL;
 
+    /* first check to see if an engine can load the PEM */
+    if (ENGINE_find_engine_load_key(NULL, &ret, (const char *)bp, cb, u) == 1)
+        return ret;
+
     if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY, bp, cb, u))
         return NULL;
     p = data;
-- 
2.6.6


From James.Bottomley at HansenPartnership.com  Wed Nov 30 15:31:25 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 07:31:25 -0800
Subject: [openssl-dev] [PATCH] openssl tpm engine: add new openssl bio
 method for seamless loading of tpm keys
Message-ID: <1480519885.2372.8.camel@HansenPartnership.com>

Permits this engine to be used as part of the openssl pem
routines for loading TPM based keys.  To use this, the
tpm engine must be preloaded via the openssl.cnf file

Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
---
 configure.in |   2 +
 e_tpm.c      | 139 +++++++++++++++++++++++++++++++++++++++++++++++------------
 2 files changed, 113 insertions(+), 28 deletions(-)

diff --git a/configure.in b/configure.in
index d07617d..4e2eff9 100644
--- a/configure.in
+++ b/configure.in
@@ -51,6 +51,8 @@ AC_PROG_LIBTOOL
 CFLAGS="$CFLAGS -Wall"
 AC_SUBST(CFLAGS)
 
+AC_CHECK_LIB(crypto, ENGINE_find_engine_load_key, [AC_DEFINE(HAVE_ENGINE_FIND_ENGINE_LOAD_KEY)])
+
 AC_OUTPUT(Makefile test/Makefile)
 
 echo "CFLAGS=$CFLAGS"
diff --git a/e_tpm.c b/e_tpm.c
index 3e20f8e..40ed4da 100644
--- a/e_tpm.c
+++ b/e_tpm.c
@@ -43,13 +43,20 @@
 #ifndef OPENSSL_NO_HW
 #ifndef OPENSSL_NO_HW_TPM
 
+struct tpm_ui {
+    UI_METHOD *ui_method;
+    pem_password_cb *pem_cb;
+};
+
 /* engine specific functions */
 static int tpm_engine_destroy(ENGINE *);
 static int tpm_engine_init(ENGINE *);
 static int tpm_engine_finish(ENGINE *);
 static int tpm_engine_ctrl(ENGINE *, int, long, void *, void (*)());
 static EVP_PKEY *tpm_engine_load_key(ENGINE *, const char *, UI_METHOD *, void *);
-static char *tpm_engine_get_auth(UI_METHOD *, char *, int, char *, void *);
+/* note unused unless HAVE_ENGINE_FIND_ENGINE_LOAD_KEY is defined */
+static int tpm_engine_load_key_bio(ENGINE *, EVP_PKEY **, BIO *, pem_password_cb *, void *) __attribute__((unused));
+static char *tpm_engine_get_auth(struct tpm_ui *, char *, int, char *, void *);
 
 #ifndef OPENSSL_NO_RSA
 /* rsa functions */
@@ -212,6 +219,9 @@ static int bind_helper(ENGINE * e)
 	    !ENGINE_set_ctrl_function(e, tpm_engine_ctrl) ||
 	    !ENGINE_set_load_pubkey_function(e, tpm_engine_load_key) ||
 	    !ENGINE_set_load_privkey_function(e, tpm_engine_load_key) ||
+#ifdef HAVE_ENGINE_FIND_ENGINE_LOAD_KEY
+            !ENGINE_set_load_privkey_bio_function(e, tpm_engine_load_key_bio) ||
+#endif
 	    !ENGINE_set_cmd_defns(e, tpm_cmd_defns))
 		return 0;
 
@@ -244,7 +254,7 @@ void ENGINE_load_tpm(void)
 	ERR_clear_error();
 }
 
-int tpm_load_srk(UI_METHOD *ui, void *cb_data)
+int tpm_load_srk(struct tpm_ui *ui, void *cb_data)
 {
 	TSS_RESULT result;
 	UINT32 authusage;
@@ -451,8 +461,9 @@ err:
 	return 0;
 }
 
-static char *tpm_engine_get_auth(UI_METHOD *ui_method, char *auth, int maxlen,
-				 char *input_string, void *cb_data)
+static char *tpm_engine_get_auth_ui(UI_METHOD *ui_method, char *auth,
+				    int maxlen, char *input_string,
+				    void *cb_data)
 {
 	UI *ui;
 
@@ -479,6 +490,30 @@ static char *tpm_engine_get_auth(UI_METHOD *ui_method, char *auth, int maxlen,
 	return auth;
 }
 
+static char *tpm_engine_get_auth_pem(pem_password_cb *pem_cb, char *auth,
+				    int maxlen, char *input_string,
+				    void *cb_data)
+{
+	EVP_set_pw_prompt(input_string);
+	if (!pem_cb)
+		pem_cb = PEM_def_callback;
+	pem_cb(auth, maxlen, 0, cb_data);
+	EVP_set_pw_prompt(NULL);
+
+	return auth;
+}
+
+static char *tpm_engine_get_auth(struct tpm_ui *ui, char *auth,
+                                 int maxlen, char *input_string, void *cb_data)
+{
+	if (ui->ui_method)
+		return tpm_engine_get_auth_ui(ui->ui_method, auth, maxlen,
+					      input_string, cb_data);
+	else
+		return tpm_engine_get_auth_pem(ui->pem_cb, auth, maxlen,
+					       input_string, cb_data);
+}
+
 static int tpm_engine_finish(ENGINE * e)
 {
 	DBG("%s", __FUNCTION__);
@@ -575,8 +610,9 @@ int fill_out_rsa_object(RSA *rsa, TSS_HKEY hKey)
 	return 1;
 }
 
-static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
-				     UI_METHOD *ui, void *cb_data)
+static int tpm_engine_load_key_core(ENGINE *e, EVP_PKEY **ppkey,
+				    const char *key_id, BIO *bio,
+				    struct tpm_ui *ui, void *cb_data)
 {
 	ASN1_OCTET_STRING *blobstr;
 	TSS_HKEY hKey;
@@ -589,39 +625,57 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 
 	DBG("%s", __FUNCTION__);
 
-	if (!key_id) {
+	if (!key_id && !bio) {
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_PASSED_NULL_PARAMETER);
-		return NULL;
-	}
-
-	if (!tpm_load_srk(ui, cb_data)) {
-		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_SRK_LOAD_FAILED);
-		return NULL;
+		return 0;
 	}
 
-	if ((bf = BIO_new_file(key_id, "r")) == NULL) {
-		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
-		       TPM_R_FILE_NOT_FOUND);
-		return NULL;
+	if (bio) {
+		bf = bio;
+	} else {
+		if ((bf = BIO_new_file(key_id, "r")) == NULL) {
+			TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
+			       TPM_R_FILE_NOT_FOUND);
+			return 0;
+		}
 	}
 
 	blobstr = PEM_ASN1_read_bio((void *)d2i_ASN1_OCTET_STRING,
 				    "TSS KEY BLOB", bf, NULL, NULL, NULL);
+
+
+	if (!bio)
+		BIO_free(bf);
+
+	/* if no actual key, we're just seeing if we can parse the file */
+	if (!ppkey) {
+		if (blobstr) {
+			ASN1_OCTET_STRING_free(blobstr);
+			return 1;
+		}
+		return 0;
+	}
+
+	/* else we're actually trying to load the key and a wrong
+	 * file format is an error */
 	if (!blobstr) {
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
 		       TPM_R_FILE_READ_FAILED);
-		BIO_free(bf);
-		return NULL;
+		return 0;
+	}
+
+	if (!tpm_load_srk(ui, cb_data)) {
+		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_SRK_LOAD_FAILED);
+		return 0;
 	}
 
-	BIO_free(bf);
 	DBG("Loading blob of size: %d", blobstr->length);
 	if ((result = Tspi_Context_LoadKeyByBlob(hContext, hSRK,
 						   blobstr->length,
 						   blobstr->data, &hKey))) {
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
 		       TPM_R_REQUEST_FAILED);
-		return NULL;
+		return 0;
 	}
 	ASN1_OCTET_STRING_free(blobstr);
 
@@ -631,7 +685,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY,
 		       TPM_R_REQUEST_FAILED);
-		return NULL;
+		return 0;
 	}
 
 	if (authusage) {
@@ -641,7 +695,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		if ((auth = calloc(1, 128)) == NULL) {
 			Tspi_Context_CloseObject(hContext, hKey);
 			TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_MALLOC_FAILURE);
-			return NULL;
+			return 0;
 		}
 
 		if (!tpm_engine_get_auth(ui, (char *)auth, 128,
@@ -650,7 +704,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 			Tspi_Context_CloseObject(hContext, hKey);
 			free(auth);
 			TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_REQUEST_FAILED);
-			return NULL;
+			return 0;
 		}
 
 		if ((result = Tspi_Context_CreateObject(hContext,
@@ -688,7 +742,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 	if ((pkey = EVP_PKEY_new()) == NULL) {
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_MALLOC_FAILURE);
-		return NULL;
+		return 0;
 	}
 	pkey->type = EVP_PKEY_RSA;
 
@@ -696,7 +750,7 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		EVP_PKEY_free(pkey);
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, ERR_R_MALLOC_FAILURE);
-		return NULL;
+		return 0;
 	}
 	rsa->meth = &tpm_rsa;
 	/* call our local init function here */
@@ -708,14 +762,43 @@ static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
 		RSA_free(rsa);
 		Tspi_Context_CloseObject(hContext, hKey);
 		TSSerr(TPM_F_TPM_ENGINE_LOAD_KEY, TPM_R_REQUEST_FAILED);
-		return NULL;
+		return 0;
 	}
 
 	EVP_PKEY_assign_RSA(pkey, rsa);
 
-	return pkey;
+	*ppkey = pkey;
+	return 1;
+}
+ 
+static int tpm_engine_load_key_bio(ENGINE *e, EVP_PKEY **ppkey, BIO *bio,
+				   pem_password_cb *pem_cb, void *cb)
+{
+	struct tpm_ui tui = {
+		.ui_method = NULL,
+		.pem_cb = pem_cb,
+	};
+
+	return tpm_engine_load_key_core(e, ppkey, NULL, bio, &tui, cb);
+}
+
+static EVP_PKEY *tpm_engine_load_key(ENGINE *e, const char *key_id,
+				     UI_METHOD *ui, void *cb)
+{
+	struct tpm_ui tui = {
+		.ui_method = ui,
+		.pem_cb = NULL,
+	};
+	EVP_PKEY *pkey;
+	int ret;
+
+	ret = tpm_engine_load_key_core(e, &pkey, key_id, NULL, &tui, cb);
+	if (ret == 1)
+		return pkey;
+	return NULL;
 }
 
+
 static int tpm_create_srk_policy(void *secret)
 {
 	TSS_RESULT result;
-- 
2.6.6


From rsalz at akamai.com  Wed Nov 30 15:32:05 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 30 Nov 2016 15:32:05 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480519669.2372.6.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
Message-ID: <2b7902ba0aef4d0e9c170614039cfe07@usma1ex-dag1mb1.msg.corp.akamai.com>

Thanks for working to improve openssl.

It is probably easier for you to do a GitHub pull request and then have discussion here, pointing to that PR.
And also, before any of this code could be used, we'll need the appropriate CLA.

From James.Bottomley at HansenPartnership.com  Wed Nov 30 15:43:58 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 07:43:58 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480519669.2372.6.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
Message-ID: <1480520638.2372.12.camel@HansenPartnership.com>

> Thanks for working to improve openssl.

You're welcome.

> It is probably easier for you to do a GitHub pull request and then
> have discussion here, pointing to that PR.

Actually, being a kernel developer, email is far easier.  I'll send a
pull request when everyone's OK with the mechanism, plus it will need
tests and other things.

> And also, before any of this code could be used, we'll need the
> appropriate CLA.

Groan ... since you're changing licences, I don't suppose you'd
consider moving to a DCO model.  It's a whole lot less bureaucratic and
much easier to keep track of.

James


From rsalz at akamai.com  Wed Nov 30 16:04:57 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 30 Nov 2016 16:04:57 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480520638.2372.12.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
Message-ID: <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>


> Actually, being a kernel developer, email is far easier.  I'll send a pull request
> when everyone's OK with the mechanism, plus it will need tests and other
> things.

Well... okay.  I don't know how the community will react.  But I *do* know that the team prefers things as PR's.


> Groan ... since you're changing licences, I don't suppose you'd consider
> moving to a DCO model. 

Sorry, no.  Legal advice and best practices.

From James.Bottomley at HansenPartnership.com  Wed Nov 30 16:19:39 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 08:19:39 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
 <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1480522779.2372.26.camel@HansenPartnership.com>

On Wed, 2016-11-30 at 16:04 +0000, Salz, Rich wrote:
> > Groan ... since you're changing licences, I don't suppose you'd 
> > consider moving to a DCO model.
> 
> Sorry, no.  Legal advice and best practices.

Interesting: whose legal advice?  I assumed you were talking to the
SFLC and I thought they were mostly pre-programmed not to recommend
CLAs after their FSF experience.  I'm asking professionally because the
knee jerk reaction of most lawyers is to recommend a CLA and there's a
group programme (run by the LF) to help them kick the habit.

Plus the DCO is industry best practice: even OpenStack is adopting it
after a long struggle.

James


From rsalz at akamai.com  Wed Nov 30 17:59:32 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 30 Nov 2016 17:59:32 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480522779.2372.26.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
 <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480522779.2372.26.camel@HansenPartnership.com>
Message-ID: <7f4337defe544cac93c2a7e5f4e042d8@usma1ex-dag1mb1.msg.corp.akamai.com>

 
> Plus the DCO is industry best practice: even OpenStack is adopting it after a
> long struggle.

Great.  Good for them.

This is what we're doing.

:)


From James.Bottomley at HansenPartnership.com  Wed Nov 30 19:10:43 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 11:10:43 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <7f4337defe544cac93c2a7e5f4e042d8@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
 <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480522779.2372.26.camel@HansenPartnership.com>
 <7f4337defe544cac93c2a7e5f4e042d8@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1480533043.2372.32.camel@HansenPartnership.com>

On Wed, 2016-11-30 at 17:59 +0000, Salz, Rich wrote:
>  
> > Plus the DCO is industry best practice: even OpenStack is adopting
> > it after a
> > long struggle.
> 
> Great.  Good for them.
> 
> This is what we're doing.
> 
> :)

OK, so where is the foundation charter and who are your lawyers?

James


From rsalz at akamai.com  Wed Nov 30 19:32:02 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 30 Nov 2016 19:32:02 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480533043.2372.32.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
 <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480522779.2372.26.camel@HansenPartnership.com>
 <7f4337defe544cac93c2a7e5f4e042d8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480533043.2372.32.camel@HansenPartnership.com>
Message-ID: <83b58fd9c43844bb956600769012ed36@usma1ex-dag1mb1.msg.corp.akamai.com>

> OK, so where is the foundation charter and who are your lawyers?

Wow, this seems to have taken a turn to the unfriendly.  I apologize if I added to that.  Sometimes a smiley doesn't wipe out all bad impressions.

The OpenSSL Software Foundation is incorporated in the the state of Delaware, United States, as a non-profit corporation. It does not qualify as a tax-exempt charitable organisation under Section 501(c)(3) of the U.S. Internal Revenue Code.   You can email info at opensslfoundation.org with questions.
But do note that openssl open source project itself is not governed by those entities, but rather by the collection of individuals known as the development team.  You can find more information by clicking on the "policies" and "community" tab on the website.  

Hope this helps.

From James.Bottomley at HansenPartnership.com  Wed Nov 30 20:13:24 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 12:13:24 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <83b58fd9c43844bb956600769012ed36@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
 <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480522779.2372.26.camel@HansenPartnership.com>
 <7f4337defe544cac93c2a7e5f4e042d8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480533043.2372.32.camel@HansenPartnership.com>
 <83b58fd9c43844bb956600769012ed36@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1480536804.2372.50.camel@HansenPartnership.com>

On Wed, 2016-11-30 at 19:32 +0000, Salz, Rich wrote:
> > OK, so where is the foundation charter and who are your lawyers?
> 
> Wow, this seems to have taken a turn to the unfriendly.  I apologize
> if I added to that.  Sometimes a smiley doesn't wipe out all bad
> impressions.

No, it's standard if you insist on the CLA route:  If you sign a CLA to
an organization, you have to understand what the organization does
before you understand what you're actually committing to: the actual
commitment isn't within the four corners of the CLA.  Your current ICLA
gives effectively an unlimited perpetual licence to do anything with
regard to sublicensing so the scope of that grant is actually governed
by the bylaws and restrictions of the foundation itself because it is
the grant recipient.  For instance, the old OpenStack ICLA was fairly
similar to yours so you had to dig into their bylaws to understand what
they were actually committing to do with the code (basically sublicense
it to all comers under ASL-2).  The structure of the organisation
matters a lot: unlimited grant to a corporate entity under a CLA is
usually a bad idea because they often have nefarious plans to take your
code private via a dual licence, or they might mean well, but their
intentions become nullified if they get taken over.  Foundations are
usually better because their charter often restricts what they can
actually do with the code and what happens to the grant in the event of
dissolution or takeover, which is why reading and understanding the
charter (and possibly the bylaws) is important.

Usually I don't have to ask, all of this is simply available on the web
most of the time.  It's just the openssl foundation doesn't appear to
have any of this online.

I suspect IBM will need to sign a CCLA ... they'll definitely need to
know who your lawyers are.

> The OpenSSL Software Foundation is incorporated in the the state of
> Delaware, United States, as a non-profit corporation. It does not
> qualify as a tax-exempt charitable organisation under Section
> 501(c)(3) of the U.S. Internal Revenue Code.   You can email 
> info at opensslfoundation.org with questions.
> But do note that openssl open source project itself is not governed
> by those entities, but rather by the collection of individuals known
> as the development team.  You can find more information by clicking
> on the "policies" and "community" tab on the website.  

I did check those links ... they don't have any governance information
about the actual openssl foundation that I can find.

James


From rsalz at akamai.com  Wed Nov 30 21:08:42 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 30 Nov 2016 21:08:42 +0000
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480536804.2372.50.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <1480520638.2372.12.camel@HansenPartnership.com>
 <652c6ee586c341a89f7c8a29a83af03e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480522779.2372.26.camel@HansenPartnership.com>
 <7f4337defe544cac93c2a7e5f4e042d8@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480533043.2372.32.camel@HansenPartnership.com>
 <83b58fd9c43844bb956600769012ed36@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1480536804.2372.50.camel@HansenPartnership.com>
Message-ID: <ac62ca7f538343159b9def65855b530b@usma1ex-dag1mb1.msg.corp.akamai.com>

> I suspect IBM will need to sign a CCLA ... they'll definitely need to know who
> your lawyers are.

We have a CCLA from IBM; contact Christopher Barrett.

> I did check those links ... they don't have any governance information about
> the actual openssl foundation that I can find.

If you want particular details, email the info address I gave you.  And again, that organization does not specify how the openssl project works.

From uri at ll.mit.edu  Wed Nov 30 21:18:40 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 30 Nov 2016 21:18:40 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1480519470.2372.2.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
Message-ID: <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>

On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" <openssl-dev-bounces at openssl.org on behalf of James.Bottomley at HansenPartnership.com> wrote:

    > One of the principle problems of using TPM based keys is that there's
    > no easy way of integrating them with standard file based keys. 

Why should token- and/or TPM-based keys be integrated with file-based keys? OpenSSL and its engines need/should accept URI pointing at the keys. Pointing them at files containing some proprietary reference to keys that are kept in hardware does not seem to make sense. 

So why is it better to say ??engine ?key /some/weird/path/weird-file.pem? than ??engine ?key pkcs11:id=02? (or such)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161130/03bfa539/attachment.bin>

From James.Bottomley at HansenPartnership.com  Wed Nov 30 21:33:24 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 13:33:24 -0800
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
Message-ID: <1480541604.2372.74.camel@HansenPartnership.com>

On Wed, 2016-11-30 at 21:18 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" <
> openssl-dev-bounces at openssl.org on behalf of 
> James.Bottomley at HansenPartnership.com> wrote:
> 
>     > One of the principle problems of using TPM based keys is that
> there's
>     > no easy way of integrating them with standard file based keys. 
> 
> Why should token- and/or TPM-based keys be integrated with file-based
> keys? OpenSSL and its engines need/should accept URI pointing at the
> keys. Pointing them at files containing some proprietary reference to
> keys that are kept in hardware does not seem to make sense. 
> 
> So why is it better to say ??engine ?key /some/weird/path/weird
> -file.pem? than ??engine ?key pkcs11:id=02? (or such)?

There appears to be some confusion here.  pkcs11 is a representation
for defined tokens.  However, for TPM, there's also file representation
of an unloaded key (it has to be parented or "wrapped" to one of the
loaded storage keys, usually the SRK).  There is no URI reference
(other than a file one) because any key so described may exist only in
the file and don't have to be part of the tpm token infrastructure.  To
make use of it, the engine first has to load the key into the TPM. 
 It's actually a simpler way of handling keys than loading them into
the TPM pkcs11 token infrastructure and naming them by slot and key

The point here is that because there's a pem file representation of the
key, it can be used anywhere a PEM file can be *without* having to tell
openssl what the engine is (the PEM guards being unique to the key
type).

James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161130/4b722030/attachment-0001.bin>

From uri at ll.mit.edu  Wed Nov 30 21:41:31 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 30 Nov 2016 21:41:31 +0000
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <1480541604.2372.74.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
 <1480541604.2372.74.camel@HansenPartnership.com>
Message-ID: <91441F38-5D25-47BE-B6C4-567B1C83BC14@ll.mit.edu>

    >> So why is it better to say ??engine ?key /some/weird/path/weird
    >> -file.pem? than ??engine ?key pkcs11:id=02? (or such)?
    >
    > There appears to be some confusion here.  pkcs11 is a representation
    > for defined tokens. 

Well, I did not mean *specifically* pkcs11 ? just as an example of something that currently works.


    > However, for TPM, there's also file representation
    > of an unloaded key (it has to be parented or "wrapped" to one of the
    > loaded storage keys, usually the SRK). 

So this PEM wrapping is needed just to load keys into TPM? How do you refer to those keys when they are already loaded?


    > The point here is that because there's a pem file representation of the
    > key, it can be used anywhere a PEM file can be *without* having to tell
    > openssl what the engine is (the PEM guards being unique to the key
    > type).
    
Well, I think I can see your point (except for the above question), but frankly I don?t like this approach very much.
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161130/4d8dd1da/attachment.bin>

From James.Bottomley at HansenPartnership.com  Wed Nov 30 21:59:43 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 13:59:43 -0800
Subject: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of
 TPM based RSA keys in openssl
In-Reply-To: <91441F38-5D25-47BE-B6C4-567B1C83BC14@ll.mit.edu>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <8411A9FC-9E45-4C88-A75A-2448B8037F24@ll.mit.edu>
 <1480541604.2372.74.camel@HansenPartnership.com>
 <91441F38-5D25-47BE-B6C4-567B1C83BC14@ll.mit.edu>
Message-ID: <1480543183.2372.91.camel@HansenPartnership.com>

On Wed, 2016-11-30 at 21:41 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
>     >> So why is it better to say ??engine ?key
> /some/weird/path/weird
>     >> -file.pem? than ??engine ?key pkcs11:id=02? (or such)?
>     >
>     > There appears to be some confusion here.  pkcs11 is a
> representation
>     > for defined tokens. 
> 
> Well, I did not mean *specifically* pkcs11 ? just as an example of
> something that currently works.
> 
> 
>     > However, for TPM, there's also file representation
>     > of an unloaded key (it has to be parented or "wrapped" to one
> of the
>     > loaded storage keys, usually the SRK). 
> 
> So this PEM wrapping is needed just to load keys into TPM? How do you
> refer to those keys when they are already loaded?

The keys are TPM volatile, so they're effectively unloaded as soon as
you close the TPM connection.  The engine code to use them is here

https://sourceforge.net/p/trousers/openssl_tpm_engine

the TPM connection is from engine init to engine finish and once the
key is loaded, it stays in the TPM until engine finish.  create_tpm_key
is what takes a standard RSA key and wraps it to the SRK as a volatile
key for the TPM.

> 
>     > The point here is that because there's a pem file
> representation of the
>     > key, it can be used anywhere a PEM file can be *without* having
> to tell
>     > openssl what the engine is (the PEM guards being unique to the
> key
>     > type).
>     
> Well, I think I can see your point (except for the above question),
> but frankly I don?t like this approach very much.

It's already a mechanism used by gnutls to load TPM keys, so it makes
sense from a compatibility point of view that it should just work for
openssl as well.  It doesn't preclude using a pkcs11 token approach as
well, it's just a different mechanism for handling keys. 

I like it because it's easier than trying to set up and use TPM token,
which seems to be very hard without admin privileges (the PEM file
approach can be used by any user of the system provided the SRK has a
well known authority).

James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5100 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161130/c1890cbc/attachment.bin>

From uri at ll.mit.edu  Wed Nov 30 22:46:21 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 30 Nov 2016 22:46:21 +0000
Subject: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test
In-Reply-To: <b65b5a56-e4a2-7af9-4cc7-3b644da68d6b@openssl.org>
References: <F53D9F53-3E9F-4839-9D06-1B73BDAF0B72@ll.mit.edu>
 <84C7EEA3-7256-4FC4-8215-287FB990D296@ll.mit.edu>
 <be1218e7-b4c7-c469-3c4a-184539164e6f@openssl.org>
 <8D6D9A8A-21A3-4B26-86FF-E77FD58959CD@ll.mit.edu>
 <aef1e513-6942-fbc0-b1bc-fa2336a3613f@openssl.org>
 <0AD21E3F-9E18-4F38-BE55-586731143F88@ll.mit.edu>
 <b65b5a56-e4a2-7af9-4cc7-3b644da68d6b@openssl.org>
Message-ID: <F5A4F9CB-04F7-4D83-9CD1-B0663CC1F4F3@ll.mit.edu>

I confirm that this fix (currently in the master) resolves the issue.

Thanks!
? 
Regards,
Uri


On 11/29/16, 4:53 AM, "openssl-dev on behalf of Matt Caswell" <openssl-dev-bounces at openssl.org on behalf of matt at openssl.org> wrote:

    
    
    On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote:
    >     > The problem is in the test. Version negotiation happens before cipher
    >     > selection. The test creates a connection which negotiates TLSv1.3. It
    >     > then attempts to select a cipher. However no TLSv1.3 ciphers are offered
    >     > by the test so the connection aborts. In truth the test is all about
    >     > mac-then-encrypt which doesn't apply to TLSv1.3 anyway, so the test
    >     > should just disable negotiation of that protocol version.
    >     
    > Thanks for explaining! 
    > 
    > Would you be able to push a fix for this test?
    
    Fix is in github:
    
    https://github.com/openssl/openssl/pull/2013
    
    Matt
    
    -- 
    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/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161130/f0661e56/attachment-0001.bin>

From levitte at openssl.org  Wed Nov 30 23:22:25 2016
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 01 Dec 2016 00:22:25 +0100
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <1480519669.2372.6.camel@HansenPartnership.com>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
Message-ID: <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>

This patch doesn't fit the rest... 

Generally speaking, I am unsure about your solution. It seems like hack to fit a specific case where something more general could be of greater service to others as well. 

Cheers 
Richard 

On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley <James.Bottomley at HansenPartnership.com> wrote:
>Before trying to process the PEM file, hand it to each of the loaded
>engines to see if they recognise the PEM guards.  This uses the new
>bio based load key callback, so the engine must be loaded and
>implement this callback to be considered.
>
>Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
>---
> crypto/pem/pem_pkey.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
>diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
>index 04d6319..e3737f0 100644
>--- a/crypto/pem/pem_pkey.c
>+++ b/crypto/pem/pem_pkey.c
>@@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY
>**x, pem_password_cb *cb,
>     int slen;
>     EVP_PKEY *ret = NULL;
> 
>+    /* first check to see if an engine can load the PEM */
>+    if (ENGINE_find_engine_load_key(NULL, &ret, (const char *)bp, cb,
>u) == 1)
>+        return ret;
>+
>if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY, bp, cb,
>u))
>         return NULL;
>     p = data;

-- 
levitte at openssl.org 

From James.Bottomley at HansenPartnership.com  Wed Nov 30 23:42:09 2016
From: James.Bottomley at HansenPartnership.com (James Bottomley)
Date: Wed, 30 Nov 2016 15:42:09 -0800
Subject: [openssl-dev] [RFC v2 2/2] pem: load engine keys
In-Reply-To: <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>
References: <1480519470.2372.2.camel@HansenPartnership.com>
 <1480519669.2372.6.camel@HansenPartnership.com>
 <CE0347A6-8757-412C-ADAB-C849AF18C3C4@openssl.org>
Message-ID: <1480549329.2372.97.camel@HansenPartnership.com>

On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote:
> This patch doesn't fit the rest... 

I'm not quite sure I follow why.  To allow engines to load PEM encoded
engine keys in place of machine processed ones, the hook into the
loader has to be in somewhere.  This seems to be the most generic place
to put the hook.

> Generally speaking, I am unsure about your solution. It seems like
> hack to fit a specific case where something more general could be of
> greater service to others as well. 

Well, the more adaptable patch set was the previous one that overloaded
the meaning of key_id.  This one has a specific bio mechanism for
loading PEM files, so it only really works for engines that have PEM
representable unloaded keys (which, to be fair, is almost all of them,
since even the USB crypto keys have a wrapped format).

I've tried to make it as generic as possible, but I am conditioned to
think to my use case: TPM keys.  If you give an example of another use
case, it will help me see where it should be more generic.

James


> Cheers 
> Richard 
> 
> On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley <
> James.Bottomley at HansenPartnership.com> wrote:
> > Before trying to process the PEM file, hand it to each of the
> > loaded
> > engines to see if they recognise the PEM guards.  This uses the new
> > bio based load key callback, so the engine must be loaded and
> > implement this callback to be considered.
> > 
> > Signed-off-by: James Bottomley <jejb at linux.vnet.ibm.com>
> > ---
> > crypto/pem/pem_pkey.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> > 
> > diff --git a/crypto/pem/pem_pkey.c b/crypto/pem/pem_pkey.c
> > index 04d6319..e3737f0 100644
> > --- a/crypto/pem/pem_pkey.c
> > +++ b/crypto/pem/pem_pkey.c
> > @@ -85,6 +85,10 @@ EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp,
> > EVP_PKEY
> > **x, pem_password_cb *cb,
> >     int slen;
> >     EVP_PKEY *ret = NULL;
> > 
> > +    /* first check to see if an engine can load the PEM */
> > +    if (ENGINE_find_engine_load_key(NULL, &ret, (const char *)bp,
> > cb,
> > u) == 1)
> > +        return ret;
> > +
> > if (!PEM_bytes_read_bio(&data, &len, &nm, PEM_STRING_EVP_PKEY, bp,
> > cb,
> > u))
> >         return NULL;
> >     p = data;
> 
> -- 
> levitte at openssl.org