Re: [openssl-dev] [openssl.org #4073] Segfault in engine processing

[Andrey Kulikov via RT]

On 12 October 2015 at 12:08, Matt Caswell via RT  wrote:

> Are you using your new GOST
> engine or the one currently in master?
>


Sorry to come in in the middle, but where to get that new GOST engine, that
is not on master now?
Is it on some other branch?

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

[openssl.org #3613] Patch: Fix warning in Nginx logs on every connect when GOST TLS used.

[Andrey Kulikov via RT]

Hello,

As noted here:
https://groups.google.com/forum/#!topic/mailing.openssl.dev/Ng3xI7-xZ0E

all version of OpenSSL produce scary warning in nginx logs on every
connect, if GOST TLS used:

[alert] 25532#0: *28 ignoring stale global SSL error (SSL:
error:140DD112:SSL routines:SSL_CERT_DUP:library bug) while SSL handshaking

All trivial fixes are in ssl_cert_dup() function.

Please find patch attached.
It can be applied using git apply command.



0001-Update-ssl_cert_dup-for-GOST-key.-Nginx-warning-in-l.patch
Description: Binary data

Fwd: [openssl.org #3538] 1.0.1h make test fails on test_verify - Debian x64

[Andrey Kulikov via RT]

Strange, but now on the same machine everything works fine.
Seems it was fluctuations of world ether...

On 21 September 2014 15:08, Andrey Kulikov via RT r...@openssl.org wrote:

 # uname -a
 Linux deb7 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
 # gcc --version
 gcc-4.7.real (Debian 4.7.2-5) 4.7.2

 ./config  make  make test
 fails with following:
 ...
 make[1]: *** [test_verify] Error 2
 make: *** [tests] Error 2
 make[1]: Leaving directory `openssl-1.0.1h/test'

 All other versions perform make test Ok, including 1.0.1i


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3538] 1.0.1h make test fails on test_verify - Debian x64

[Andrey Kulikov via RT]

# uname -a
Linux deb7 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
# gcc --version
gcc-4.7.real (Debian 4.7.2-5) 4.7.2

./config  make  make test
fails with following:

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
47536097586952:error:0B06E06B:x509 certificate
routines:X509_get_pubkey_parameters:unable to find parameters in
chain:x509_vfy.c:1814:
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd,
CN = Test CA (1024 bit)
error 20 at 0 depth lookup:unable to get local issuer certificate
../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits Pty
Ltd, CN = CA
error 20 at 0 depth lookup:unable to get local issuer certificate
../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits
Pty Ltd, CN = PCA
error 18 at 0 depth lookup:self signed certificate
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 18 at 0 depth lookup:self signed certificate
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
make[1]: *** [test_verify] Error 2
make: *** [tests] Error 2
make[1]: Leaving directory `openssl-1.0.1h/test'

All other versions perform make test Ok, including 1.0.1i

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2938] [PATCH] Severe resource leak in tls_P_hash() (v1.0.1 and up)

[Andrey Kulikov via RT]

Indeed,

Improved version of the patch are in:
[openssl.org #2937] Handshake performance degradation in 1.0.1 and up.

On 9 September 2014 21:16, Rich Salz via RT r...@openssl.org wrote:

 From an internal review of the patch:
 Contexts are meant to be reused and (for example) reusing the same context
 and
 digest avoids having to reallocate a buffer for the internal context
 structure.

 I think this might actually be a problem in the ENGINE not handling reuse
 properly, or the EVP API not having a way to signal reuse properly.

 Either way I don't think this is the correct fix.
 --
 Rich Salz, OpenSSL dev team; rs...@openssl.org



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3322] [PATCH] ccgost to use configured params for 28147-89 in CNT and IMIT mode

[Andrey Kulikov via RT]

Dmitriy,

Thanks for noticing!
I do not see it either - correcting myself. :-)

You are right - according to
http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04
CryptoProParamSetA is required in GOST TLS.
But only for content encryption.
Premaster secret encryption could use any other parameters.

Also, OpenSSL usage is not limited to TLS only - for some other protocols
(IPSec, for instance) other parameters can be used.
This patch is for them.


On 22 April 2014 12:24, Dmitry Belyavsky beld...@gmail.com wrote:

 Hello Andrey,

 Thank you for your work, but I do not see the patch :-(

 I should say that in practice the CNT mode is used in TLS where usage of
 the Gost28147_CryptoProParamSetA is required.





ccgost_CNT_use_params.patch
Description: Binary data

[openssl.org #3322] [PATCH] ccgost to use configured params for 28147-89 in CNT and IMIT mode

[Andrey Kulikov via RT]

Currently ccgost engine use configured params (s-boxes) when it works in
CFB mode only.
For CNT and IMITO parameters are hardcoded to Gost28147_CryptoProParamSetA

Supplied patch allow ccgost engine to really use parameters, specified
either in config file, or via engine API.

When nothing is configured, parameters selection fails back to default -
i.e. Gost28147_CryptoProParamSetA.
So regression behavior persists.

*WARNING: *Some interoperability issues possible, with SSL for example
(uses 28147-CNT by default), if some previously configured parameters start
to be used, while previously they where ignored.

Patch created using this command:
 \diff -rupN openssl-1.0.1g/engines/ccgost/
openssl-1.0.1g-debug/engines/ccgost/  ccgost_CNT_use_params.patch

To apply patch use following command in current OpenSSL root dev. directory:

patch -p1 -l -u -b -i ccgost_CNT_use_params.patch

Patch created against 1.0.1g.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3308] Re: Return missed NULL-check in CMS_add0_cert back

[Andrey Kulikov via RT]

  Well...
  With this check 'make test' fails with:
 
  CMS = PKCS#7 compatibility tests
  signed content DER format, RSA key: generation error
  make[1]: *** [test_cms] Error 1
 
 

 Can't reproduce that here. Anyone else seeing this?

I saw it on Debian 7 x64, gcc  4.7.2

But anyway, as *pcerts can be NULL legitimately, this seems to be not
important.
Sorry for wasting your time. :(

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3307] Return missed NULL-check in CMS_add0_cert back

[Andrey Kulikov via RT]

In 1.0.1g duplicated check for (!pcerts) where removed.

Had an impression that second appearance was check for (!*pcerts) (as in
all other functions).

Return it back.
Patch applied.



0001-Check-pcerts-for-NULL.patch
Description: Binary data

[openssl.org #3308] Re: Return missed NULL-check in CMS_add0_cert back

[Andrey Kulikov via RT]

Well...
With this check 'make test' fails with:

CMS = PKCS#7 compatibility tests
signed content DER format, RSA key: generation error
make[1]: *** [test_cms] Error 1




On 14 April 2014 00:16, Andrey Kulikov amde...@gmail.com wrote:

 In 1.0.1g duplicated check for (!pcerts) where removed.

 Had an impression that second appearance was check for (!*pcerts) (as in
 all other functions).

 Return it back.
 Patch applied.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2953] s_server to show connection duration and transfer speed

[Andrey Kulikov via RT]

Please find attached patch, introducing two new options for s_server:
one specify maximum number of connections s_server will accept. It will
exit clearly after completing last connection
the other tells s_server to show each completed connection duration and
data transfer rate.

These options exceptionally usable for profiling, debugging and test
automation.

Patch correctly applied to openssl-1.0.2-stable-SNAP-20130108

In order to apply patch you may use command:
 patch -p0 -l -u -b -i s_server_limit_show_speed_long.patch
and
 patch -p1 -l -u -b -i s_server_limit_show_speed_doc.patch

Please let me know if you have any questions.

Andrey.



s_server_limit_show_speed_long.patch
Description: Binary data


s_server_limit_show_speed_doc.patch
Description: Binary data

Re: [openssl.org #2937] Handshake performance degradation in 1.0.1 and up.

[Andrey Kulikov via RT]

On 11 December 2012 04:00, Stephen Henson via RT r...@openssl.org wrote:



 I also notice that even the original HMAC version initialises two HMAC
 contexts with the same key. That could be improved by initialising one
 and copying the context across.


This kind of optimization can be also applied P_hash implementation via to
EVP_DigestSign*.
HMAC contexts being re-initialized in inner loop every time it executed.
It is possible to improve it here by initializing only once in the
beginning of function, save to some temporary variables, and restore
restore from them when needed.
It would solve original issue with re-initialilization excessive overhead.
BUT:
1. It gives only miserable performance benefits in normal case (i.e.
software-only) (  1%). Hashing of few more bytes is almost nothing in
comparison to BN-manipulations.
2. In case of external hardware usage it may lead to the same result: in my
case cost of MAC copying call is the same as cost of MAC calculation call.
And only way to improve performance is to reduce total amount of remote
calls.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2937] Handshake performance degradation in 1.0.1 and up.

[Andrey Kulikov via RT]

Please find attached two patches, together implementing proper HMAC context
re-initialization instead of full re-creation.
In comparison to openssl-1.0.1c it gives ~10% handshake performance
improvements when some engine-specific MAC are used.

In order to apply patches use command
patch -p1 -i filename

Patches checked to applied to:
openssl-1.0.1c
openssl-1.0.2-stable-SNAP-20130108

make test report Ok. for both versions (Linux, x86[_64])

Please let me know if you have any questions.



TLS_P_hash-HMAC_reinit.patch
Description: Binary data


TLS_P_hash-HMAC_reinit2.patch
Description: Binary data

[openssl.org #2937] Handshake performance degradation in 1.0.1 and up.

[Andrey Kulikov via RT]

In comparison to 1.0.0, in 1.0.1 the implementation of PRF have been
changed.
In order to supporf TLS 1.1/1.2 features, in file ssl/t1_enc.c, in function
tls_P_hash() calls to HMAC_Init/HMAC_Update/HMAC_Final where replaced by
EVP_DigestSignInit/EVP_DigestSignUpdate/EVP_DigestSignFinal.

As a drawback, keyblock setup for a chiphersuites with 256-bit encryption and
MAC key require about 3 times more intensive usage of hash objects.
For example, in order to perform one handshake,
in OpenSSL 1.0.0i
Digest init called 30 times.
Digest copy called 69 times.
Digest cleanup called 98 times.

OpenSSL 1.0.1c
Digest init called 105 times.
Digest copy called 160 times.
Digest cleanup called 264 times.

~3 times more intensive hashes objects usage definitely not good for
performance.
In my case, handshake rate drops down to 5-6% on the same hardware in 1.0.1c
in comparison to 1.0.0i.

Also, more intense malloc usage leads to faster head fragmentation. But I
didn't able to measure impact of that factor yet.

Is there any way to reduce hash objects usage, while keeping TLS 1.1/1.2
features?

In comparison to 1.0.0, in 1.0.1 the implementation of PRF have been changed.In order to supporf TLS 1.1/1.2 features, in file ssl/t1_enc.c, in function tls_P_hash() calls to HMAC_Init/HMAC_Update/HMAC_Final where replaced by EVP_DigestSignInit/EVP_DigestSignUpdate/EVP_DigestSignFinal.
As a drawback, keyblock setup for a chiphersuites with 256-bit encryption and MAC key require about 3 times more intensive usage of hash objects.For example, in order to perform one handshake,
in OpenSSL 1.0.0iDigest init called 30 times.Digest copy called 69 times.Digest cleanup called 98 times.




OpenSSL 1.0.1c

Digest init called 105 times.

Digest copy called 160 times.Digest cleanup called 264 times.




~3 times more intensive hashes objects usage definitely not good for performance.In my case, handshake rate drops down to 5-6% on the same hardware in 1.0.1c in comparison to 1.0.0i.
Also, more intense malloc usage leads to faster head fragmentation. But I didnt able to measure impact of that factor yet.Is there any way to reduce hash objects usage, while keeping TLS 1.1/1.2 features?

[openssl.org #2938] [PATCH] Severe resource leak in tls_P_hash() (v1.0.1 and up)

[Andrey Kulikov via RT]

Hello,

In v1.0.1 tls_P_hash() has been changed in comparison to early OpenSSL
versions.
Used hash objects is re-initializing during P_hash calculation.
It looks harmless, but only until we come to hash objects, holding
references to external objects.
E.g. engine-specific hashes, allocating handles to hardware device or some
external library.

Then re-initing these MACs does not result in memory loss, but  handlers to
external objects, stored in that memory being lost.
(this is why I call it resource leak, not memory).

In my case each handshake leads to 87 unfreed handles, and library,
interacting with hardware device starts to fail due to out of memory after
about 6000 handshakes.

Please find attached patch, correcting discovered issue.
It can be applied to 1.0.1, 1.0.2 and to latest source tarball.

make test
report success for 1.0.1c with this patch applied.

If anyone see any issues in supplied patch - please let me know.

Best wishes,
Andrey Kulikov.

Hello,In v1.0.1 tls_P_hash() has been changed in comparison to early OpenSSL versions.Used hash objects is re-initializing during P_hash calculation.It looks harmless, but only until we come to hash objects, holding references to external objects.
E.g. engine-specific hashes, allocating handles to hardware device or some external library.Then re-initing these MACs does not result in memory loss, but? handlers to external objects, stored in that memory being lost.
(this is why I call it resource leak, not memory).In my case each handshake leads to 87 unfreed handles, and library, interacting with hardware device starts to fail due to out of memory after about 6000 handshakes.
Please find attached patch, correcting discovered issue.It can be applied to 1.0.1, 1.0.2 and to latest source tarball.make testreport success for 1.0.1c with this patch applied.If anyone see any issues in supplied patch - please let me know.
Best wishes,Andrey Kulikov.


tls1_P_hash_resource_leak.patch
Description: Binary data

[openssl.org #2939] Re: [FIX] 1.0.0d: All platforms: GOST server MUST check correctness of shared UKM

[Andrey Kulikov via RT]

Just noticing the wrong goto label in case of EVP_PKEY_CTX_ctrl() failue.
Please find attached corrected patch (gost_server_to_check_ukm_v2.patch)

On 17 April 2011 17:54, Andrey Kulikov amde...@gmail.com wrote:

 According to this document:

 http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04#section-3.6

 Server, implementing GOST algost MUST check correctness of shared UKM,
 send by client.

 ==

  Server MUST verify, that keyBlob.transportParameters.ukm is equal to
GOSTR3411(client_random|server_random)[0..7], before decrypting the
premaster_secret.

 ==

 There is no such checks in 1.0.0d at all.
 Attachecd patch implements missing functionality.

 To apply patch use following command in root of current OpenSSL
 development tree:

 patch -p1 -l -u -b -i gost_server_to_check_ukm.patch

 Andrey.

 P.S. Checked to works fine with two CSP from different vendors, as well as
 openssl itself.


Just noticing the wrong goto label in case of EVP_PKEY_CTX_ctrl() failue.Please find attached corrected patch (gost_server_to_check_ukm_v2.patch)On 17 April 2011 17:54, Andrey Kulikov amde...@gmail.com wrote:
According to this document:http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04#section-3.6
Server, implementing GOST algost MUST check correctness of shared UKM, send by client.

== Server MUST verify, that keyBlob.transportParameters.ukm is equal to   GOSTR3411(client_random|server_random)[0..7], before decrypting the   premaster_secret.
==There is no such checks in 1.0.0d at all.Attachecd patch implements missing functionality.To apply patch use following command in root of current OpenSSL development tree:
patch -p1 -l -u -b -i gost_server_to_check_ukm.patchAndrey.P.S. Checked to works fine with two CSP from different vendors, as well as openssl itself.




gost_server_to_check_ukm_v2.patch
Description: Binary data

Re: [openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

On 16 December 2011 02:47, Andy Polyakov via RT r...@openssl.org wrote:
 Attached patch fix the problem on cygwin.
 Does it mean that you can in fact confirm that modified speed.c runs
 without hanging?

 Yes, modified speed.c, being compiled in the same Cygwin environment
 as before, runs without hanging for all hashes.

 Verify http://cvs.openssl.org/chngview?cn=21853.

Works!


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2657] Win32: fail to compile - 1.0.1 snapshot 20111211

[Andrey Kulikov via RT]

VisualStudio 2010

 perl Configure VC-WIN32
ms\do_ms.bat
nmake -f ms\nt.mak
..

ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32\vpaes-x86.obj
tmp32\vpaes-x86.asm
 Assembling: tmp32\vpaes-x86.asm
tmp32\vpaes-x86.asm(491) : error A2070:invalid instruction operands
tmp32\vpaes-x86.asm(527) : error A2070:invalid instruction operands
tmp32\vpaes-x86.asm(545) : error A2070:invalid instruction operands
tmp32\vpaes-x86.asm(572) : error A2070:invalid instruction operands
tmp32\vpaes-x86.asm(616) : error A2070:invalid instruction operands
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual
Studio 10.0\VC\BIN\ml.EXE' : return code '0x1'
Stop.


ml
Microsoft (R) Macro Assembler Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

 downloaded 8G file via s_server from 1.0.1 snapshot 20111213 - works fine.

Using RC4-SHA chipthersuite.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

Checked with 1.0.0e - the same problem.

speed hangs up with md4 md5 mdc2 and sha1, but works well with sha256
sha512 and whirlpool.


I downloaded 8G file via s_server from 1.0.1 snapshot 20111213 - works fine.
(using RC4-SHA chiphersuite)
Seems problem in speed' itself, or, as Andy mentioned - in time calculation.
As in addition, even if speed' do not hangs up, each group of block
calkulation MAY take significantly more than 3 sec...


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

 Compiler might be
 complaining about some small things, use your judgment to ignore
 warnings or to make it compile.

It does complain! :-)
Attached patch fix the problem on cygwin.
Back-ported to 1.0.0e was not break native Win32 (32 bit, VS10) compilation.



spped_cygwin.patch
Description: Binary data

Re: [openssl.org #2657] Win32: fail to compile - 1.0.1 snapshot 20111211

[Andrey Kulikov via RT]

Verify http://cvs.openssl.org/chngview?cn=21845.

This patch helps!
Thanks a lot!

 ml
 Microsoft (R) Macro Assembler Version 10.00.30319.01
 Copyright (C) Microsoft Corporation.  All rights reserved.

 Microsoft Assembler gets *very* limited testing and the official
 standpoint is to favor nasm. In other words in case of doubt, switch to
 nasm.


Eh...
Missed string in INSTALL.W32:
Note that NASM is now the only supported assembler.
:-)


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

 It does complain! :-)
 Attached patch fix the problem on cygwin.

 Does it mean that you can in fact confirm that modified speed.c runs
 without hanging?

Yes, modified speed.c, being compiled in the same Cygwin environment
as before, runs without hanging for all hashes.
Interesting, why we do not have such effect fo ciphers and for three
selected hashes

 BTW,
 do you get same KBps values?


Before patch:

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
sha256   32264.54k75889.08k   133579.66k   166999.63k   177915.57k
sha512   17319.36k69456.32k   103750.87k   144978.57k   166290.93k
whirlpool22616.29k51999.79k91632.37k   108593.83k99194.67k
rc4 423843.86k   533050.06k   558939.38k   597673.15k   604000.56k
idea cbc 64826.69k65397.38k67318.14k66839.71k66455.04k
aes-128 cbc  95172.64k   107472.19k   110012.39k   176664.53k   177304.57k
aes-256 cbc  69245.45k77572.27k79714.56k   128283.83k   128298.72k


After the patch:

The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes   64 bytes   256 bytes 1024
bytes   8192 bytes
sha256 32567.32k76673.55k   130986.27k   162825.57k   178479.48k
sha512 17374.95k70081.18k   105646.81k   143291.62k   164904.29k
whirlpool   22472.70k52594.12k91494.43k   109679.24k
100349.95k
rc4   435291.94k   548119.26k   579422.27k
597697.81k   608022.70k
idea cbc63872.42k66033.29k66642.98k68983.62k
 67100.26k
aes-128 cbc  96134.45k   106319.68k   110688.68k   178169.51k   179018.97k
aes-256 cbc  69849.36k79412.17k80094.75k   127889.70k   130016.22k


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

Tested on two computers.

Both native (i.e. non-VM) Windows7 x64 Professional (without SP1).
One has E8600 CPU, the other is laptop with i5 mobile CPU.
Both has 8G RAM.
Both working stable for a monthes.
No abnormalities, no BSODs.

gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Cygwin DLL version is 1.7.9-1

Package list (output of  cygcheck -cd )attached.

On 13 December 2011 13:28, Andy Polyakov via RT r...@openssl.org wrote:
 Program behavior appears to be sane,
 Is  it virtual machine? Which OS is it? What is the host? I.e. VMware, Xen,
 ...? Have you ever observed anomalies in ping output? Anomalies like
 it's reporting negative round-trip time?



Cygwin Package Information

Package   Version

_update-info-dir  01006-1

alternatives  1.3.30c-10

autoconf  10-1

autoconf2.1   2.13-10

autoconf2.5   2.68-1

automake  4-10

automake1.10  1.10.3-1

automake1.11  1.11.1-1

automake1.4   1.4p6-10

automake1.5   1.5-10

automake1.6   1.6.3-11

automake1.7   1.7.9-10

automake1.8   1.8.5-10

automake1.9   1.9.6-10

base-cygwin   3.0-1

base-files4.0-6

base-passwd   3.1-2

bash  4.1.10-4

bash-completion   1.3-1

binutils  2.22.51-1

bison 2.4.2-1

build-docbook-catalog 1.5-2

bzip2 1.0.6-2

ca-certificates   1.78-1

cmake 2.8.4-1

coreutils 8.14-1

cpio  2.11-1

crypt 1.1-1

csih  0.9.4-1

curl  7.22.0-2

cvs   1.12.13-10

cvsps 2.2b1-1

cygrunsrv 1.34-1

cygutils  1.4.6-1

cygwin1.7.9-1

cygwin-doc1.7-1

dash  0.5.7-1

dbus  1.4.16-1

diffutils 2.9-1

docbook-dsssl 1.79-2

docbook-sgml303.0-1

docbook-sgml313.1-1

docbook-sgml404.0-1

docbook-sgml414.1-1

docbook-sgml424.2-1

docbook-sgml434.3-1

docbook-sgml444.4-1

docbook-sgml454.5-1

docbook-utils 0.6.14-1

docbook-xml4124.1.2-2

docbook-xml42 4.2-4

docbook-xml43 4.3-2

docbook-xml44 4.4-2

docbook-xml45 4.5-1

docbook-xsl   1.76.1-1

dog   1.7-1

dos2unix  5.3.1-1

ed1.0-1

editrights1.01-2

file  5.09-1

findutils 4.5.9-2

flex  2.5.35-1

font-adobe-dpi75  1.0.2-1

font-alias1.0.3-1

font-bh-dpi1001.0.2-1

font-bh-dpi75 1.0.2-1

font-bitstream-dpi100 1.0.2-1

font-bitstream-dpi75  1.0.2-1

font-cursor-misc  1.0.2-1

font-encodings1.0.4-1

font-micro-misc   1.0.2-1

font-misc-cyrillic1.0.2-1

font-misc-misc1.1.1-1

font-screen-cyrillic  1.0.3-1

font-sun-misc 1.0.2-1

font-util 1.2.0-1

font-winitzki-cyrillic1.0.2-1

font-xfree86-type11.0.3-1

fontconfig2.8.0-1

gamin 0.1.10-11

gawk  4.0.0-1

gcc-core  3.4.4-999

gcc-g++   3.4.4-999

gcc-mingw-core20050522-3

gcc-mingw-g++ 20050522-3

gdb   7.3.50-3

geoip 1.3.14-1

gettext   0.18.1.1-2

git   1.7.5.1-1

git-completion1.7.5.1-1

git-gui   1.7.5.1-1

git-oodiff20080328-2

gitk  1.7.5.1-1

grep  2.6.3-1

groff 1.20.1-2

gsettings-desktop-schemas 3.2.0-1

gzip  1.4-1

hexedit   1.2.12-2

indent2.2.11-1

ipc-utils 1.0-1

jadetex   3.13-1

less  444-1

libapr1   1.4.5-1

libaprutil1   1.3.12-1

libattr1  2.4.43-1

libblkid1 2.17.2-1

libbz2_1  1.0.6-2

libcharset1   1.14-2

libcurl4  7.22.0-2

libdb4.5  4.5.20.2-2

libdbus1_31.4.16-1

libedit0  20090923-1

libexpat1 2.0.1-1

libfam0   0.1.10-11

libffi4   4.5.3-3

libfontconfig12.8.0-1

libfontenc1   1.1.0-1

libfreetype6  2.4.7-1

libgcc1   4.5.3-3

libgcrypt11   1.4.6-1

libgdbm4  1.8.3-20

libGL1 

[openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

OpenSSL 1.0.1 snaphot 20111211, compiled on Cygwin, no special config options.

gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
CPU Code2 Duo E8600

make tests shows:
../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.


Both
./apps/openssl speed sha1
and
./apps/openssl speed -evp sha1

MAY results in hangup on any stage.
Sometimes speed command complete successfylly.

$ ./apps/openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 2726540 sha1's in 2.51s
Doing sha1 for 3s on 64 size blocks: 2573136 sha1's in 2.73s
Doing sha1 for 3s on 256 size blocks: 1862928 sha1's in 2.61s
Doing sha1 for 3s on 1024 size blocks: 935145 sha1's in 2.64s
Doing sha1 for 3s on 8192 size blocks: 158296 sha1's in 2.65s
OpenSSL 1.0.1-dev xx XXX 
built on: Mon Dec 12 01:14:51 RST 2011
options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial)
idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS  -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS
-DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM
_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAE
S_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
sha1 17373.41k60322.60k   183004.44k   363273.32k   488974.67k

Sometimes it hang up on block calculation of any size.
At this time CPU load 100%, and nothing.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

The same behaviour is for other hashes: md4 md5 mdc2 and sha.

But not for sha256, sha512 and whirlpool - everything is ok with these hashes:

$ ./apps/openssl speed sha512 sha256 whirlpool

OpenSSL 1.0.1-dev xx XXX 
built on: Tue Dec 13 08:14:31 RST 2011
options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial)
idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS  -DDSO_DLFCN -DHAVE_DLFCN_H -g
-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
sha256   32216.74k75616.73k   132102.69k   165474.27k   179371.50k
sha512   17037.17k67636.17k   103818.78k   148730.56k   160855.87k
whirlpool21894.41k51207.20k87122.50k   105701.73k96333.88k

On 12 December 2011 19:08, Andy Polyakov via RT r...@openssl.org wrote:
 OpenSSL 1.0.1 snaphot 20111211, compiled on Cygwin, no special config 
 options.

 gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
 CPU Code2 Duo E8600

 Both
 ./apps/openssl speed sha1
 and
 ./apps/openssl speed -evp sha1

 MAY results in hangup on any stage.
 Sometimes speed command complete successfylly.



__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2655] speed sha1 hang up - 1.0.1 snapshot 20111211 - Cygwin

[Andrey Kulikov via RT]

 Can you reproduce it under cygwin gdb? I.e. 'gdb apps/openssl' and then
 at gdb prompt 'run speed sha1'. If yes, ctrl-C and 'info threads'. Then
 'cont', ctrl-C and 'info threads' few more times. Look at thread #1 at
 all occasions. Where is it caught? Does program counter varies? If  it's
 caught in sha1_block_data_order_ssse3, collect several 'thread apply 1
 info reg' outputs.



Disgusting gdb under sickening cygwin do not understand Crtl-C!
Fortunately workaround available:
http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt

openssl was compiled with ./config -g

(gdb) info threads
  Id   Target Id Frame
* 12   Thread 8820.0x1fc0 0x77b2000d in ntdll!LdrFindResource_U ()
from /cygdrive/c/Windows/system32/ntdll.dll
  8Thread 8820.0x2280 0x77b2f861 in ntdll!RtlUpdateClonedSRWLock
() from /cygdrive/c/Windows/system32/ntdll.dll
  7Thread 8820.0x19bc 0x77b2fd21 in ntdll!RtlFindSetBits () from
/cygdrive/c/Windows/system32/ntdll.dll
  6Thread 8820.0x2bd0 0x77b2fd9d in ntdll!RtlFindSetBits () from
/cygdrive/c/Windows/system32/ntdll.dll
  5Thread 8820.0x2b40 0x77b2f861 in ntdll!RtlUpdateClonedSRWLock
() from /cygdrive/c/Windows/system32/ntdll.dll
  4Thread 8820.0x1634 0x77b300ed in
ntdll!RtlEnableEarlyCriticalSectionEventCreation () from
/cygdrive/c/Windows/system32/ntdll.dll
  2Thread 8820.0x1f18 0x77b2f895 in ntdll!RtlUpdateClonedSRWLock
() from /cygdrive/c/Windows/system32/ntdll.dll
  1Thread 8820.0x272c _sha1_block_data_order_ssse3 () at sha1-586.s:1689
(gdb) thread apply 1 info reg

Thread 1 (Thread 8820.0x272c):
eax0xcc6ee5e214363742
ecx0xff2dbcf7   -13779721
edx0x47b21e88   1202855560
ebx0x3430f0e8   875622632
esp0x287e40 0x287e40
ebp0x41a18787   0x41a18787
esi0x47b31288   1202918024
edi0xb3a52001   -1281023999
eip0x555c3e 0x555c3e _sha1_block_data_order_ssse3+990
eflags 0x203[ CF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)

(gdb) thread apply 1 info reg

Thread 1 (Thread 8820.0x272c):
eax0x24f45c66   619994214
ecx0xcb1d6c20   -887264224
edx0x57307c2c   1462795308
ebx0x11f11a9f   301013663
esp0x287f1c 0x287f1c
ebp0x10082080x1008208
esi0xe85d345d   -396544931
edi0xf70aaf7d   -150294659
eip0x556710 0x556710 _sha1_block_data_order_ssse3+3760
eflags 0x202[ IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)

(gdb) thread apply 1 info reg

Thread 1 (Thread 8820.0x272c):
eax0x2cbb7e4d   750485069
ecx0x481a01575603989
edx0xe3e6332c   -471452884
ebx0xa7f4213a   -1477172934
esp0x287e40 0x287e40
ebp0xa2e42130   0xa2e42130
esi0x99405b26   -1723835610
edi0x280b64d3   671835347
eip0x556063 0x556063 _sha1_block_data_order_ssse3+2051
eflags 0x282[ SF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)

(gdb) thread apply 1 info reg

Thread 1 (Thread 8820.0x272c):
eax0xbc696264   -1133944220
ecx0xafee45bd   -1343339075
edx0x54158eaf   1410698927
ebx0x5e827d65   1585610085
esp0x287e40 0x287e40
ebp0x25e34b13   0x25e34b13
esi0xf16c38d8   -244565800
edi0xf72a45d5   -148224555
eip0x556049 0x556049 _sha1_block_data_order_ssse3+2025
eflags 0x206[ PF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)

(gdb) thread apply 1 info reg

Thread 1 (Thread 8820.0x272c):
eax0x348d035c   881656668
ecx0xac8d1c04   -1400038396
edx0x6d76965e   1836488286
ebx0xeed891a4   -287796828
esp0x287e40 0x287e40
ebp0x8b021ae9   0x8b021ae9
esi0xee991124   -291958492
edi0x60435d31   1615027505
eip0x555cb5 0x555cb5 _sha1_block_data_order_ssse3+1109
eflags 0x203[ CF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)

(gdb) thread apply 1 info reg

Thread 1 (Thread 8820.0x272c):
eax0xea86e973   -360257165
ecx0x409b7f15   1083932437
edx 

[openssl.org #2365] Limitations of ENGINE interface hamper performance on modern hardware

[Andrey Kulikov via RT]

 3) An accellerator device directly supports TLS/SSL record
 encryption/decryption and the handshake operation itself.

 We do many bus transactions to the accellerator (and
 possibly system calls into the OS kernel) where we
 could do one, doing every single basic cryptographic
 operation individually when we could actually amortize
 the cost over the entire record or handshake operation.

 This is the case for most modern accellerators used with
 general-purpose CPUs.


Application of such technique does not limited to hardware acselerator.
Yet another example of such devices is services, allowing to pass
the whole record plus encryption and MAC keys, and process it in
single call.
It is used when for some (security) reasons all
cryptography-manipulations performed in separate process/driver/VM,
and client operates only with handlers to keys.

I saw how it was implemented in extension to MS CryptoAPI.
Even without such extensions CryptEncrypt function is able to encrypt
and hash data at the same time.
Extension I'm taking about does add abbility to pass there pointer to
header, body and place where to put tail - i.e. MAC value.

Inabbility to process TLS record in single call results to necessity
to pass the same data over IPC twice.

Andrey.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #2551] [PATCH] All platforms: Option to disable sending renegotiation_info extension.

[Andrey Kulikov via RT]

First of all - it is not a Microsoft bug.
This is bug in some products, who act as a TLS clients.

Second: what should I describe to customers? :-)
Their programms works with other server, by not with mine.

Is the question still valid?
:-)

On 1 July 2011 12:20, Ben Laurie via RT r...@openssl.org wrote:

 Why are you modifying OpenSSL for this? This is a Microsoft bug - have
 you reported it to Microsoft?


 --
 http://www.apache-ssl.org/ben.html   http://www.links.org/

 There is no limit to what a man can do or how far he can go if he
 doesn't mind who gets the credit. - Robert Woodruff




First of all - it is not a Microsoft bug.This is bug in some products, who act as a TLS clients.Second: what should I describe to customers? :-)Their programms works with other server, by not with mine.
Is the question still valid?:-)On 1 July 2011 12:20, Ben Laurie via RT r...@openssl.org wrote:
Why are you modifying OpenSSL for this? This is a Microsoft bug - have
you reported it to Microsoft?


--
http://www.apache-ssl.org/ben.html ? ? ? ? ? http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesnt mind who gets the credit. - Robert Woodruff

[openssl.org #2463] [PATCH]: OpenSSL 1.0.0d: Add abbility to load server certificate by ENGINE.

[Andrey Kulikov via RT]

I prefer more generic method similar to ENGINE_load_ssl_client_cert, i.e. I
need EVP keys,
 corresponding certificates and the certificate chain.

Additional methods has server in it's names for the same reason why
ENGINE_load_ssl_client_cert has client in it.

ENGINE_load_server_certificate() intended to work in pair with
ENGINE_load_private_key() to allow engine to load certificate correspondent
to it's private key.
And present obtained certificate to client during SSL handshake. That it.

You can always get required EVP_PKEY keys from loaded X509 structure.
But I can't get why you may need certificate chain for your certificate if
you are server.

Andrey

I prefer more generic method similar to ENGINE_load_ssl_client_cert, i.e. I need EVP keys,  corresponding certificates and the certificate chain. 
Additional methods has server in its names for the same reason why ENGINE_load_ssl_client_cert has client in it.
ENGINE_load_server_certificate() intended to work in pair with ENGINE_load_private_key() to allow engine to load certificate correspondent to its private key.And present obtained certificate to client during SSL handshake. That it.

You can always get required EVP_PKEY keys from loaded X509 structure.But I cant get why you may need certificate chain for your certificate if you are server.
Andrey

[openssl.org #2463] [PATCH]: OpenSSL 1.0.0d: Add abbility to load server certificate by ENGINE.

[Andrey Kulikov via RT]

Hello,

Please find file attached: server_cert_from_engine4.patch
This is a patch to allow loading server SSL certificate by ENGINE.

Currently OpenSSL allows loading certificate only from a file.
Loading by specific engine is required for hardware-based engines, which
used their own certificate storages, as well as any Microsoft CAPI-based
CSP.

Although there is no such engines implemented for OpenSSL yet, sooner it
will.

Affected files:

apps/apps.c
apps/s_server.c
crypto/engine/engine.h
crypto/engine/eng_int.h
crypto/engine/eng_pkey.c

Patch created using this command:
diff -rupN openssl-1.0.0d/ openssl-1.0.0d-engine-srv-cert/ 
server_cert_from_engine4.patch



To apply pach use follwing command in current OpenSSL root dev. directory:

patch -p1 -l -u -b -i server_cert_from_engine4.patch


After applying this patch s_server will accept -certform ENGINE option.

This patch supplied by Stonesoft Corporation, who give me permission to
supply it to OpenSSL.

Feel free to contact with me with any related questions.

Andrey.

Hello,Please find file attached: server_cert_from_engine4.patch This is a patch to allow loading server SSL certificate by ENGINE.Currently OpenSSL allows loading certificate only from a file.Loading by specific engine is required for hardware-based engines, which used their own certificate storages, as well as any Microsoft CAPI-based CSP.
Although there is no such engines implemented for OpenSSL yet, sooner it will.Affected files:apps/apps.capps/s_server.ccrypto/engine/engine.hcrypto/engine/eng_int.hcrypto/engine/eng_pkey.c
Patch created using this command:diff -rupN openssl-1.0.0d/ openssl-1.0.0d-engine-srv-cert/  server_cert_from_engine4.patchTo apply pach use follwing command in current OpenSSL root dev. directory:
patch -p1 -l -u -b -i server_cert_from_engine4.patchAfter applying this patch s_server will accept -certform ENGINE option.This patch supplied by Stonesoft Corporation, who give me permission to supply it to OpenSSL.
Feel free to contact with me with any related questions.Andrey.


server_cert_from_engine4.patch
Description: Binary data