Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[CpServiceSPb .]

> We have no plans to do this.
>> May be will put it into your plans ?
>>> Doubtful. We have lots of other work to do. Writing a full-strength
database-backed OCSP responder is outside of our interests.

I decided not wait for you and I have made OSSL Ocsp responder based at
index DB - storing/getting some necessary parameters for its operating
at Index text DB in my own.
Now is for 1.0.2d version.

Look at: https://github.com/CpServiceSpb/OpenSSLOcsp.git

And a big wishing to you as dev. team is to check code and include to the
next nearest release version.
Because I need Windows version also, but man, who builds (compiles) OSSL
installation for Windows make it for released main versions only (not for
forked) .
And I don' t have Windows building environment for it at the time.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[Salz, Rich]

Congratulations, sounds like nice work!


Ø  And a big wishing to you as dev. team is to check code and include to the 
next nearest release version.

I doubt anyone on the team will review the code, and it almost certainly will 
not become part of OpenSSL.

I hope that others are interested and will contribute to your project.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[Salz, Rich]

Ø  Why this part of code will never become part of OSSL ?

It's not what we do.

OpenSSL is a crypto and TLS toolkit.  It is not a general PKI solution.

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

Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[CpServiceSPb .]

> ... and it almost certainly will not become part of OpenSSL

It sound bad.
Why this part of code will never become part of OSSL ?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4161] Bug : aes-128-ccm cipher mode not working

[Stephen Henson via RT]

On Mon Nov 30 15:25:01 2015, prasha...@ryussi.com wrote:
> Hi,
>
> We are trying to generate CMAC authentication code using EVP_aes_128_ccm
> mode. The CMAC_Final function returning the single byte hash code which
> suppose to return 16-byte hash code.
>
> We tried same algorithm with EVP_aes_128_cbc mode which is returning
> 16-byte hash code but we have specific requirement for EVP_aes_128_ccm mode.
>

CCM mode is not compatible with CMAC.

It doesn't make a lot of sense because CCM mode has a MAC built in. To use that
you need to set up the cipher correctly. See the documentation,
demos/evp/aesccm.c and the wiki for more details.

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

[openssl-dev] [openssl.org #4161] Bug : aes-128-ccm cipher mode not working

[Prashant Dhange via RT]

Hi,

We are trying to generate CMAC authentication code using  EVP_aes_128_ccm
mode. The CMAC_Final function returning the single byte hash code which
suppose to return 16-byte hash code.

We tried same algorithm with EVP_aes_128_cbc mode which is returning
16-byte hash code but we have specific requirement for EVP_aes_128_ccm mode.

Here is the sample code snippet for CMAC generation:
{{{
ctx = CMAC_CTX_new();

CMAC_Init(ctx, key, key_len, EVP_aes_128_ccm(), NULL);


CMAC_Update(ctx, d, n);

CMAC_Final(ctx, md, _len);

CMAC_CTX_free(ctx);
}}}

Kindly provide us inputs on this issue.

Thanks,
~Prashant.

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4157] Download Documentation

[Hubert Kario]

On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote:
> 3. Some kind of useful examples of common usages
> of OpenSSL would be appreciated. I'm still trawling through the
> documentation trying to figure out how to do what I want to do and am
> relying heaving on 3rd party guides to figure out what I want to do.

https://wiki.openssl.org/index.php/Main_Page

If you have specific use cases missing from there, please tell, but be 
precise

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4157] Download Documentation

[Hubert Kario via RT]

On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote:
> 3. Some kind of useful examples of common usages
> of OpenSSL would be appreciated. I'm still trawling through the
> documentation trying to figure out how to do what I want to do and am
> relying heaving on 3rd party guides to figure out what I want to do.

https://wiki.openssl.org/index.php/Main_Page

If you have specific use cases missing from there, please tell, but be 
precise

-- 
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


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Forthcoming OpenSSL releases

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2e, 1.0.1q, 1.0.0t and 0.9.8zh.

These releases will be made available on 3rd December between approx.
1pm and 5pm (UTC). They will fix a number of security defects, the
highest of which is classified as "moderate" severity.

Please note that the OpenSSL project has recently revised its severity
definitions by introducing a new "critical" level, i.e. the severity
levels are now: critical, high, moderate and low. Please see the
following page for further details:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, the 1.0.0 and
0.9.8 releases will no longer be receiving security updates after the
end of this year. This means that, barring any unexpected significant
security issues between now and 31st December 2015, it is likely that
these releases will be the last ones for 1.0.0 and 0.9.8.

Yours

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

iQEcBAEBCAAGBQJWXG1kAAoJENnE0m0OYESR3vgH/0R7GCsN4moof7ezQIbZbxxN
qeiwH2SGj0a5KXM/J9Ee4jcQWA2n0SfUeFbgLSvqBO8BQdz3oTJMF45Z+gXjWFqZ
OiEQ+ZFayNm/Tb46OFhglbRBhfb7Je4sy4i8cSW6wGQ2EdWz3JN/xWC0q9KMqQpi
k8IwitBK3WxZ/Je+rHZvsDzABWd3Jf2+QlDjwHXxSfrW9UBc5Wr7e+d5XMQk2KML
FGJtkucAFs+AiOWvfsJ2WzFYy373M7pYQT38ODOuvT9HxMHzDY89kj2BsFjr8pZY
yIk9fAE1BTKRoNoUPETVuYi0Wq+xFHgV5urFQztxglWymcxAILHOZ+PZDyT/m5Q=
=QGvN
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4155] In function int_thread_del_item, when hash == int_thread_hash, one is passed to free and the other is used in a comparison

[Kaduk, Ben via RT]

On 11/24/2015 05:06 AM, Pascal Cuoq via RT wrote:
> This issue is similar in nature to 4151 
> (http://www.mail-archive.com/openssl-dev@openssl.org/msg40950.html ): it is 
> about a dangling pointer being used, but not used for dereferencing, so it's 
> not a memory error. The dangling pointer is used in a comparison.
>
> The function int_thread_del_item can reach the point were it calls 
> “lh_ERR_STATE_free(int_thread_hash);” with hash == int_thread_hash. That 
> attached patch prints a message like “hash == int_thread_hash == 0xb2a6d0” 
> when this happens. Just after the call to lh_ERR_STATE_free, both hash and 
> int_thread_hash contain dangling pointers. The variable int_thread_hash is 
> immediately set to NULL.
>
> The problem that I am reporting is that just afterwards,  is passed to 
> the function int_thread_release:
>
> https://github.com/openssl/openssl/blob/079a1a9014b89661f0a612a5a9724ad9c77f21a3/crypto/err/err.c#L412
>
>

Note that per J.2 of C99 (n1256.pdf page 503, document-internal
numbering), using the value of a pointer that refers to space
deallocated by a call to free is undefined behavior, even for just
comparison.  (This is covered in passing at
http://web.torek.net/torek/c/numbers2.html)

-Ben


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

[openssl-dev] [openssl.org #4161] Bug : aes-128-ccm cipher mode not working

[Rich Salz via RT]

Wrong crypto being used, not an OpenSSL error.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

[Jeremy Farrell via RT]

On Mon Jul 20 13:03:05 UTC 2015 Andy Polyakov wrote:
 >
 >> I applied the patch you sent and configured/compiled using
 >> "solaris-sparcv9-gcc" and the program completes normally.
 >> As I am unable to use patched/unofficial code for our operational ...
 >
 >What is criteria for being "official"? Explicitly released as tar-ball
 >or just commit to repository?

Unless I'm missing it, this patch doesn't appear to have been committed
to the repository yet. Any chance you could get this into 1.0.2e?

Regards,
jjf

-- 
J. J. Farrell


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

Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

[Puckett, Rick via RT]

Jeremy,

Are you asking me? I don't have commit access to the repository.  Obviously, I 
would endorse adding this patch as we have Sun T-3 systems. :-)  As the patch 
wasn't incorporated into an official release, I worked around this issue by 
using the configure parameter  "solaris-sparcv7".

- Rick

-Original Message-
From: Jeremy Farrell via RT [mailto:r...@openssl.org] 
Sent: Monday, November 30, 2015 12:37 PM
To: Puckett, Rick (IS)
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) 
hangs on Sun T3 in OPENSSL_cpuid_setup()

On Mon Jul 20 13:03:05 UTC 2015 Andy Polyakov wrote:
 >
 >> I applied the patch you sent and configured/compiled using  >> 
 >> "solaris-sparcv9-gcc" and the program completes normally.
 >> As I am unable to use patched/unofficial code for our operational ...
 >
 >What is criteria for being "official"? Explicitly released as tar-ball  >or 
 >just commit to repository?

Unless I'm missing it, this patch doesn't appear to have been committed to the 
repository yet. Any chance you could get this into 1.0.2e?

Regards,
jjf

--
J. J. Farrell



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

Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

[Jeremy Farrell via RT]

Sorry Rick, no, I was asking openssl-dev. I sent the email solely to 
r...@openssl.org as recommended on the web site, and it looks like it 
rewrote it 'To' you and 'Cc' to openssl-dev. Sorry for the confusion.

Regards,
   jjf

On 30/11/2015 17:57, Puckett, Rick via RT wrote:
> Jeremy,  > > Are you asking me? I don't have commit access to the repository. 
> > 
Obviously, I would endorse adding this patch as we have Sun T-3 > 
systems. :-)  As the patch wasn't incorporated into an official > 
release, I worked around this issue by using the configure parameter > 
"solaris-sparcv7". > > - Rick > > -Original Message-
 >From: Jeremy Farrell via RT [mailto:r...@openssl.org]
 >To: Puckett, Rick (IS)
 >Cc: openssl-dev@openssl.org > > On Mon Jul 20 13:03:05 UTC 2015 Andy 
Polyakov wrote: >> >>> I applied the patch you sent and 
configured/compiled using  >> >>> "solaris-sparcv9-gcc" and the program 
completes normally. As I am >>> unable to use patched/unofficial code 
for our operational ... >> >> What is criteria for being "official"? 
Explicitly released as >> tar-ball  >or just commit to repository? > > 
Unless I'm missing it, this patch doesn't appear to have been > 
committed to the repository yet. Any chance you could get this into > 
1.0.2e?

-- 
J. J. Farrell


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

[openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store

[Leonidas Da Silva Barbosa via RT]

Access to VRSAVE have a high cost in performance.
Since ABI was update we don't need to save what
vector register we are using. Removing VRSAVE access
can improve a bit more our performance.

Signed-off-by: Leonidas S. Barbosa 
Signed-off-by: Paulo Flabiano Smorigo 
---
 crypto/aes/asm/aesp8-ppc.pl | 20 
 crypto/modes/asm/ghashp8-ppc.pl | 11 ---
 2 files changed, 31 deletions(-)

diff --git a/crypto/aes/asm/aesp8-ppc.pl b/crypto/aes/asm/aesp8-ppc.pl
index a1891cc..35f36ef 100755
--- a/crypto/aes/asm/aesp8-ppc.pl
+++ b/crypto/aes/asm/aesp8-ppc.pl
@@ -104,10 +104,6 @@ Lset_encrypt_key:
andi.   r0,$bits,0x3f
bne-Lenc_key_abort
 
-   lis r0,0xfff0
-   mfspr   $vrsave,256
-   mtspr   256,r0
-
bl  Lconsts
mtlrr11
 
@@ -336,7 +332,6 @@ Ldone:
vsel$in1,$outhead,$in1,$outmask
stvx$in1,0,$inp
li  $ptr,0
-   mtspr   256,$vrsave
stw $rounds,0($out)
 
 Lenc_key_abort:
@@ -408,10 +403,7 @@ $code.=<<___;
 .align 5
 .${prefix}_${dir}crypt:
lwz $rounds,240($key)
-   lis r0,0xfc00
-   mfspr   $vrsave,256
li  $idx,15 # 15 is not typo
-   mtspr   256,r0
 
lvx v0,0,$inp
neg r11,$out
@@ -465,7 +457,6 @@ Loop_${dir}c:
vselv0,v0,v4,v2
stvxv0,$idx,$out
 
-   mtspr   256,$vrsave
blr
.long   0
.byte   0,12,0x14,0,0,0,3,0
@@ -490,9 +481,6 @@ $code.=<<___;
bltlr-
 
cmpwi   $enc,0  # test direction
-   lis r0,0xffe0
-   mfspr   $vrsave,256
-   mtspr   256,r0
 
li  $idx,15
vxor$rndkey0,$rndkey0,$rndkey0
@@ -638,7 +626,6 @@ Lcbc_done:
vsel$inout,$ivec,$inptail,$outmask
stvx$inout,$idx,$ivp
 
-   mtspr   256,$vrsave
blr
.long   0
.byte   0,12,0x14,0,0,0,6,0
@@ -1196,7 +1183,6 @@ Lcbc_dec8x_done:
stvx$inpperm,r11,$sp
addir11,r11,32
 
-   mtspr   256,$vrsave
lvx v20,r10,$sp # ABI says so
addir10,r10,32
lvx v21,r11,$sp
@@ -1249,10 +1235,6 @@ $code.=<<___;
${UCMP}i$len,1
bltlr-
 
-   lis r0,0xfff0
-   mfspr   $vrsave,256
-   mtspr   256,r0
-
li  $idx,15
vxor$rndkey0,$rndkey0,$rndkey0
le?vspltisb $tmp,0x0f
@@ -1344,7 +1326,6 @@ Loop_ctr32_enc:
vsel$inout,$outhead,$inout,$outmask
stvx$inout,0,$out
 
-   mtspr   256,$vrsave
blr
.long   0
.byte   0,12,0x14,0,0,0,6,0
@@ -1849,7 +1830,6 @@ Lctr32_enc8x_done:
stvx$inpperm,r11,$sp
addir11,r11,32
 
-   mtspr   256,$vrsave
lvx v20,r10,$sp # ABI says so
addir10,r10,32
lvx v21,r11,$sp
diff --git a/crypto/modes/asm/ghashp8-ppc.pl b/crypto/modes/asm/ghashp8-ppc.pl
index e76a58c..63e46fa 100755
--- a/crypto/modes/asm/ghashp8-ppc.pl
+++ b/crypto/modes/asm/ghashp8-ppc.pl
@@ -46,7 +46,6 @@ my ($Xip,$Htbl,$inp,$len)=map("r$_",(3..6));  # argument block
 
 my ($Xl,$Xm,$Xh,$IN)=map("v$_",(0..3));
 my ($zero,$t0,$t1,$t2,$xC2,$H,$Hh,$Hl,$lemask)=map("v$_",(4..12));
-my $vrsave="r12";
 
 $code=<<___;
 .machine   "any"
@@ -56,11 +55,8 @@ $code=<<___;
 .globl .gcm_init_p8
 .align 5
 .gcm_init_p8:
-   lis r0,0xfff0
li  r8,0x10
-   mfspr   $vrsave,256
li  r9,0x20
-   mtspr   256,r0
li  r10,0x30
lvx_u   $H,0,r4 # load H
 
@@ -90,7 +86,6 @@ $code=<<___;
stvx_u  $H, r9,r3
stvx_u  $Hh,r10,r3
 
-   mtspr   256,$vrsave
blr
.long   0
.byte   0,12,0x14,0,0,0,2,0
@@ -102,9 +97,7 @@ $code=<<___;
 .gcm_gmult_p8:
lis r0,0xfff8
li  r8,0x10
-   mfspr   $vrsave,256
li  r9,0x20
-   mtspr   256,r0
li  r10,0x30
lvx_u   $IN,0,$Xip  # load Xi
 
@@ -140,7 +133,6 @@ $code=<<___;
le?vperm$Xl,$Xl,$Xl,$lemask
stvx_u  $Xl,0,$Xip  # write out Xi
 
-   mtspr   256,$vrsave
blr
.long   0
.byte   0,12,0x14,0,0,0,2,0
@@ -152,9 +144,7 @@ 

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Peter Waltenberg]

 I'd suggest checking where the bottlenecks are before making major structural changes. I'll admit we have made a few changes to the basic OpenSSL sources but I don't see unacceptable amounts of locking even on large machines (100's of processing units) with thousands of threads.Blinding and the RNG's were the hot spots and relatively easy to address. Also, you use TRNG's for things like blinding where a PRNG will do, fixing that also helps performance.Peter-"openssl-dev"  wrote: -To: paul.d...@oracle.com, openssl-dev@openssl.orgFrom: Nico Williams Sent by: "openssl-dev" Date: 12/01/2015 10:16AMSubject: Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthreadOn Tue, Dec 01, 2015 at 09:21:34AM +1000, Paul Dale wrote:> However, the obstacle preventing 100% CPU utilisation for both stacks> is lock contention.  The NSS folks apparently spent a lot of effort> addressing this and they have a far more scalable locking model than> OpenSSL: one lock per context for all the different kinds of context> versus a small number of global locks.I prefer APIs which state that they are "thread-safe provided theapplication accesses each XYZ context from only one thread at a time".Leave it to the application to do locking, as much as possible.  Manythreaded applications won't need locking here because they may naturallyhave only one thread using a given context.Also, for something like a TLS context, ideally it should be naturallypossible to have two threads active, as long as one thread only readsand the other thread only writes.  There can be some dragons here withrespect to fatal events and deletion of a context, but the simplestthing to do is to use atomics for manipulating state like "had a fatalalert", and use reference counts to defer deletion (then if theapplication developer wants it this way, each of the reader and writerthreads can have a reference and the last one to stop using the contextdeletes it).> There is definitely scope for improvement here.  My atomic operation> suggestion is one approach which was quick and easy to validate,> better might be more locks since it doesn't introduce a new paradigm> and is more widely supported (C11 notwithstanding).A platform compatibility atomics library would be simple enough (plentyexist, I believe).  For platforms where no suitable implementationexists you can use a single global lock, and if there's not even that,then you can use non-atomic implementations and pretend it's all OK orfail to build (users of such platforms will quickly provide realimplementations).(Most compilers have pre-C11 atomics intrinsics and many OSes haveatomics libraries.)Nico-- ___openssl-dev mailing listTo unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Nico Williams]

On Tue, Dec 01, 2015 at 09:21:34AM +1000, Paul Dale wrote:
> However, the obstacle preventing 100% CPU utilisation for both stacks
> is lock contention.  The NSS folks apparently spent a lot of effort
> addressing this and they have a far more scalable locking model than
> OpenSSL: one lock per context for all the different kinds of context
> versus a small number of global locks.

I prefer APIs which state that they are "thread-safe provided the
application accesses each XYZ context from only one thread at a time".

Leave it to the application to do locking, as much as possible.  Many
threaded applications won't need locking here because they may naturally
have only one thread using a given context.

Also, for something like a TLS context, ideally it should be naturally
possible to have two threads active, as long as one thread only reads
and the other thread only writes.  There can be some dragons here with
respect to fatal events and deletion of a context, but the simplest
thing to do is to use atomics for manipulating state like "had a fatal
alert", and use reference counts to defer deletion (then if the
application developer wants it this way, each of the reader and writer
threads can have a reference and the last one to stop using the context
deletes it).

> There is definitely scope for improvement here.  My atomic operation
> suggestion is one approach which was quick and easy to validate,
> better might be more locks since it doesn't introduce a new paradigm
> and is more widely supported (C11 notwithstanding).

A platform compatibility atomics library would be simple enough (plenty
exist, I believe).  For platforms where no suitable implementation
exists you can use a single global lock, and if there's not even that,
then you can use non-atomic implementations and pretend it's all OK or
fail to build (users of such platforms will quickly provide real
implementations).

(Most compilers have pre-C11 atomics intrinsics and many OSes have
atomics libraries.)

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

[openssl-dev] [openssl.org #4157] Download Documentation

[Rich Salz via RT]

Did you see the INSTALL and README files in whatever version you downloaded?
On the download page, I added a link to the release strategy which explains the
release numbering.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Hubert Kario]

On Tuesday 24 November 2015 10:49:26 Paul Dale wrote:
> On Mon, 23 Nov 2015 11:11:37 PM Alessandro Ghedini wrote:
> > Is this TLS connections?
> 
> Yes, this is just measuring the TLS handshake.  Renegotiations
> predominately. We deliberately didn't test the bulk symmetric crypto
> phase of the connection.
> > I'd like to know more...
> 
> The data are a bit rough and ready but I've included what I can.  I
> wasn't directly involved in taking these measurements, so Chinese
> whispers are entirely possible.  I've been tasked with trying to find
> some performance enhancements.
> 
> The TLS stack results are:
> 
> stack CPU %  connections/s
> OpenSSL 85  11,935
> atomic patch22  16,465proof of concept only, the stack
> is broken elsewhere 
> NSS 47  46,507!

are you sure that the negotiated cipher suite is the same and that the 
NSS is not configured to reuse the server key share if you're using DHE 
or ECDHE?

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev