Re: [openssl-dev] Multithreading performance patches

[Andrey Kulikov]

Hi!

> The reason is that so far it was
> reserved for occasion like this, i.e. when somebody requests it and puts
> effort into testing it in real-life application:-) Can we do that?

I did it.
Added to crypto/cryptlib.c:

#  ifndef OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL
int OPENSSL_atomic_add(int *, int, int, const char *, int);
#  endif

and insert at the end of void OPENSSL_cpuid_setup(void)

#  ifndef OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL
CRYPTO_set_add_lock_callback(OPENSSL_atomic_add);
#  endif

So one could disable this feature by defining
OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL macro at compile time.
Tested on Linux x86 and x64 during last 4 years on different high-load
SSL-servers.
Tested on Linux x86 and x64, Windows x86 and x64 in different SSL-client
applications.

No issues observed.

Cheers,
Andrey.

On 12 October 2012 at 18:19, Andy Polyakov  wrote:

> > I'm working on fast multithreaded TLS server for node.js, and I've
> > encountered few problems with openssl threading support which I would
> > like to address with attached patches.
> >
> > Please ask me if you have any questions or comments.
>
> As for 1st patch. Note that the section in question is guarded by 'if
> (add_lock_callback)'. add_lock_callback can be set by application and
> perform operation to its liking. In addition, on platforms with
> OPENSSL_CPUID_OBJ defined there is OPENSSL_atomic_add that can be used
> as callback, so that all you need to do then is
> CRYPTO_set_add_lock_callback(OPENSSL_atomic_add) in application code.
> Well, you'll surely get into trouble compiling this line, because
> OPENSSL_atomic_add is not declared. The reason is that so far it was
> reserved for occasion like this, i.e. when somebody requests it and puts
> effort into testing it in real-life application:-) Can we do that?
> Original idea behind OPENSSL_atomic_add was even to enable it
> automatically. On related note one can also add pointer manipulation
> subroutines so that one can maintain linked lists in lock-free manner...
>
> I'll have closer look at second patch and comment later on.
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

[Andrey Kulikov]

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

Re: [openssl-dev] License compatibility: OpenSSL and Apache v2

[Andrey Kulikov]

This is something I would like to be contributed to OpenSSL.
Sure, I'm talking about new engine and new files.

And I agree that using the same license as OpenSSL itself would be the best
solution.
But, if for some reasons licensing of it will be possible under Apache v2
only - what issues could it cause?

On 10 December 2014 at 05:54, Salz, Rich  wrote:

> > Let's imagine someone develop extension module to OpenSSL, and release
> it under Apache v2 license.
> > Do you see any possible issues with using this extension module as a
> part of OpenSSL?
>
> Are you writing an extension that you are going to distribute, or is it
> something you want to contribute to OpenSSL?
>
> You cannot change the license on openssl files, and any work derived from
> them such as modifications to those source files, must have the same
> license. And if you want to to contribute it to the project, it is easiest
> for us if the license is the same.
>
> But if it is your own code, and you are distributing it, then you can do
> anything you want :)
> ___
> openssl-dev mailing list
> openssl-dev@openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

[openssl-dev] License compatibility: OpenSSL and Apache v2

[Andrey Kulikov]

Hello,

Let's imagine someone develop extension module to OpenSSL, and release it
under Apache v2 license.
Do you see any possible issues with using this extension module as a part
of OpenSSL?
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/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

Re: [openssl.org #3533] [PATCH] Ensures that EVP encryption & decryption operations check the encrypt flag on the context.

[Andrey Kulikov]

Patch visible.
Thanks for contribution.

As to actual content - it is up to OpenSSL team.
But as to the style: comments of // type is not in OpenSSL code conventions.
If you redo them to /**/ way - it could speed-up processing.

On 13 November 2014 20:54, Alok Menghrajani via RT  wrote:

> Hi,
>
> I didn't get any response to my previous email regarding checking the
> encrypt flag when doing EVP encryption or decryption operations, nor did I
> get any comments on the patch. I have the feeling I incorrectly formatted
> my patch, so I'm re-doing it.
>
> Alok
>
>

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

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

[Andrey Kulikov]

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

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

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  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 #1372] default config should diable idea

[Andrey Kulikov]

The last patents for IDEA expired in 2012. Now it's free to use.


On 3 July 2014 21:24, Rich Salz via RT  wrote:

> As the changelog says for 0.9.8,
> (IDEA remains enabled despite being patented. This is because IDEA
> is frequently required for interoperability, and there is no license
> fee for non-commercial use. As before, "no-idea" can be used to
> avoid this algorithm.)
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: [openssl.org #3430] ssltest fails when using -DTEMP_GOST_TLS

[Andrey Kulikov]

> when I compile using the -DTEMP_GOST_TLS flag

What the reason to do it?
GOST TLS (at least that one what works) do not require this to be defined.

Re: [RFC] Cleanup contexts in tls1_P_hash

[Andrey Kulikov]

Creating MD context could be HEAVY when using crypto-devices.
And then you set a key to it, what is also could be heavy operation.

Thus, you'll get severe performance degradation in general case.

See [openssl.org #2937] for references.
For some reasons (other than performance) I give away from cleaning up
context every loop - had an impression there where a crash at some point.


On 19 June 2014 17:59, Joel Fernandes  wrote:

> When using OpenSSL SSL/TLS with cryptodev or OCF engines, it appears
> that some sessions are not closed. Since cryptodev (and I think OCF too)
> maintain a list of open sessions in the kernel, such lists keep growing
> to a point where the CPU usage goes up in the kernel finally making things
> unresponsive.
>
> This patch fixes the issue, however I'm not sure if its the right
> approach or may be introducing another issue. It appears to fix the high
> CPU usage and everything works fine, however a customer is now reporting
> a error from the SSL library when used from a Java application. Please
> take a look at the patch and let me know if there's anything I'm doing
> wrong or if there's a better fix. This applies for OpenSSL version 1.0.1g.
>
> Here's the trace back from the Java application:
>
> 2014-06-18 13:43:24,147 ERROR [synchr] WebConnection - error in post
> attempt #1, dt=2080
> javax.net.ssl.SSLProtocolException: Read error: ssl=0x429afa88: Failure
> in
> SSL library, usually a protocol error
> at com.apogee.openssl.jsse.NativeCrypto.SSL_read(Native Method)
> at
> com.apogee.openssl.jsse.OpenSSLSocketImpl$SSLInputStream.
> read(OpenSSLSocketImpl.java:923)
> at java.io.InputStream.read(InputStream.java:101)
> at
> com.att.dlc.xail.WebConnection.readResponse(WebConnection.java:3167)
> at
> com.att.dlc.xail.WebConnection.sendPost(WebConnection.java:3030)
> at
> com.att.dlc.xail.WebConnection.sendCommandsSync(WebConnection.java:2750)
> at
> com.att.dlc.xail.WebConnection.sendCommandsSync(WebConnection.java:2699)
> at
> com.att.dlc.xail.WebConnection.access$2200(WebConnection.java:117)
> at
> com.att.dlc.xail.WebConnection$ManagedObjectSynchronizer.update
>(WebConnection.java:4519)
> at
> com.att.dlc.xail.WebConnection$ManagedObjectSynchronizer.run
>(WebConnection.java:4496)
> at java.lang.Thread.run(Thread.java:857)
>
> Cc: Dr. Stephen Henson 
> Cc: Ralf S. Engelschall 
> Cc: Andy Polyakov 
> Signed-off-by: Joel Fernandes 
> ---
>  ssl/t1_enc.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/ssl/t1_enc.c b/ssl/t1_enc.c
> index 809ad2e..2135f1b 100644
> --- a/ssl/t1_enc.c
> +++ b/ssl/t1_enc.c
> @@ -195,6 +195,8 @@ static int tls1_P_hash(const EVP_MD *md, const
> unsigned char *sec,
>
> for (;;)
> {
> +   EVP_MD_CTX_cleanup(&ctx);
> +   EVP_MD_CTX_cleanup(&ctx_tmp);
> /* Reinit mac contexts */
> if (!EVP_DigestSignInit(&ctx,NULL,md, NULL, mac_key))
> goto err;
> --
> 1.7.9.5
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: [openssl.org #3328] [PATCH] Support for GOST R 34.10-2012 digital signature algorithm

[Andrey Kulikov]

Дмитрий, а есть ли у вас планы по внедрению  TLS, основанного на новых
ГОСТах, в OpenSSL ?
Сам собирался занятся этим в начале лета, после отпуска.
С вашей помощью, теперь, это совсем тривиально должно получиться.

Можно скооперироваться как-нибудь.
Если вы, конечно, всё сами не сделаете до этого. :-)

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  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 #3310] Can't execute make command

[Andrey Kulikov]

What platform you are using, and what is the config parameters?
Can happens due to accidental editing of source file?

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

Re: [openssl.org #3311] [PATCH] Introduce GOST R 34.11-2012 hash function

[Andrey Kulikov]

Hello Dmitry,

Thanks a lot for your commitment!

It would be good idea to add test cases for new functionality as well.



On 14 April 2014 23:52, Dmitry Olshansky via RT  wrote:

> It's been a bit over 2 years since the new Russian cryptography standard
> is out.
> RFCs 6986 and 7091 been out there for a while[1,2]. Other toolkits are
> adding support, e.g. Libgcrypt introduced GOST 34.11-2012 in 1.6.0 [3].
>
> Keeping in mind that OpenSSL provides GOST reference engine it seems
> natural to revise it in the light of the new standard.
>
> To summarize the full set of changes for the new standard:
>  - New hash function GOST R 34.11-2012 (Stribog) takes place of GOST
> R 34.11-94. After 2018 usage of 34.11-94 is basically prohibited.
>
>  - Digital signature algorithm GOST 34.10-2001 is extended to
> support both 256bit and 512bit keys. The hash function to use is GOST R
> 34.11-2012. 256bit version is exactly the same modulo the hashing.
>
>  - 2 new parameter sets (curves) for 512bit GOST 34.10-2012 are
> listed as recommended. Older ones stay as is for 256-bit version.
>
>  - Symmetric cipher stays the same, one new S-box set was defined.
>
>  - Key Exchange (VKO) is the same algorithm but with different hash
> function (HMAC of GOST 34.11-2012).
>
> This patch adds support for hash algorithm GOST R 34.11-2012 _only_ .
> The source code was initially tested on x86, PowerPC and ARMv4.
> New digests have short names "md_gost12_256" and "md_gost12_512"
> respectively.
>
> See attached patch or browse it on github:
> https://github.com/openssl/openssl/pull/68
>
> Next steps towards full support are far less involved and consist mostly
> of minor changes such as adding paramsets and/or removing artificial
> limitations.
>
> 1. GOST R 34.11-2012: Hash Function http://tools.ietf.org/html/rfc6986
> 2. GOST R 34.10-2012: Digital Signature Algorithm
> http://tools.ietf.org/html/rfc7091
> 3. http://lists.gnupg.org/pipermail/gnupg-announce/2013q4/000336.html
>
> --
> Dmitry Olshansky
>
>
>

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

Re: [openssl.org #3235] Re: AES256-SHA256 test failed on OpenSSL-1.0.1f ARM64( compiled with -O3 optimization)

[Andrey Kulikov]

Got the same error on Linux, both  x86 and x64, when tried to add following
lines to ./ssl/t1_enc.c@tls1_change_cipher_state:

ssl3_cleanup_key_block(s);
OPENSSL_cleanse(s->s3->read_mac_secret,
sizeof(s->s3->read_mac_secret));
OPENSSL_cleanse(s->s3->write_mac_secret,
sizeof(s->s3->write_mac_secret));


at the very end.
Just before

return(1);
err:
SSLerr(SSL_F_TLS1_CHANGE_CIPHER_STATE,ERR_R_MALLOC_FAILURE);

Error appears both for TLS 1.2 AES128-SHA256 and AES256-SHA256 ciphersuites.
And do NOT appears for any other ciphersuites.



On 13 January 2014 20:26, Shawn via RT  wrote:

> hey OpenSSL community maintainers,
>
> Compiled OpenSSL with GCC -O3 optimization on ARM64 might cause
> AES256-SHA256 testing fails:
>
> -
> [ 3022s] Testing AES256-SHA256
> [ 3024s] Available compression methods:
> [ 3024s]   NONE
> [ 3024s] ERROR in SERVER
> [ 3024s] 274890758944:error:1408F119:
> SSL
> routines:SSL3_GET_RECORD:decryption failed or bad record
> mac:s3_pkt.c:484:
> [ 3024s] TLSv1.2, cipher TLSv1/SSLv3 AES256-SHA256, 2048 bit RSA
> [ 3024s] 1 handshakes of 256 bytes done
> [ 3024s] Failed AES256-SHA256
> [ 3024s] make[1]: *** [test_ssl] Error 1
> [ 3024s] make[1]: Leaving directory
> `/home/abuild/rpmbuild/BUILD/openssl-1.0.1f/test'
>
> ---
>
> I'm not sure if this is an issue of OpenSSL. -O3 works for previous
> release( 1.0.1e). Plz check the fully log which was attached! Thanks!
>
>
> --
> GNU powered it...
> GPL protect it...
> God blessing it...
>
> regards
> Shawn
>
>

Re: [openssl.org #3201] EVP_DigestUpdate crashes because of a NULL pointer

[Andrey Kulikov]

EVP_MD_CTX_copy() also can fail due to external engine usage (including HW
engine).
In this case underlying work can be more complicated that memory allocation.
Descriptors shortage, amount of simultaneous contexts constraints, etc. Or
just bugs in engine code.

On 27 December 2013 21:39, Misaki.Miyashita via RT  wrote:

> >>
> > I agree that the return value should be checked but I'd like to know the
> > underlying cause. EVP_MD_CTX_copy() shouldn't normally fail unless
> something is
> > seriously wrong, e.g. memory allocation failures.
> >
>

Re: [openssl.org #3117] [PATCH] A fast vectorized implementation of binary elliptic curves on x86-64 processors

[Andrey Kulikov]

Dear Manuel,

Exciting news!
While your paper still unpublished, could you please advice, it there
anything even nearly similar possible for curves over primary fields?
(e.g. curves secp* )

Best regards,
Andrey


On 28 August 2013 09:06, Manuel Bluhm via RT  wrote:

> Hello all,
>
> This patch is a contribution to OpenSSL.
>
> It offers an efficient and constant-time implementation of the elliptic
> curve point multiplication, for the following standard NIST/SECG binary
> elliptic curves:
> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1,
> sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1,
> sect571k1, and sect571r1.
>
> The patch implements several improvements at the algorithmic and the
> coding levels (using SSE/AVX and PCLMULQDQ instructions).
>
> Depending on the curve and architecture, this patch offers a speedup of
> between 4x to 10x for ECDH and ECDSA, compared to the current
> implementation of OpenSSL 1.0.1e.
> Additionally, it adds side channel protection to avoid (cache) timing
> attacks using a number of mechanisms.
>
> The code is written in C and uses compiler intrinsics, for simplicity
> and portability. The following results were obtained with gcc 4.8.1.
>
> For detailed explanations of the rationale and algorithms of this code
> refer to [1].
>
>
> ECDH performance
> --
>
> The performance was measured by using openssl speed utility as follows:
>
> $ openssl speed ecdh
>
>
> The results for a Core i7-4770 CPU @ 3.40GHz (Haswell) in ECDH op/s:
>
> Curve   || OpenSSL 1.0.1e || This patch  || Speedup  ||
> ||||-||--||
> |||| ||  ||
> (nistk163)  ||6586.9  ||  67029.6||  10.18   ||
> (nistk233)  ||5121.9  ||  39441.3||   7.70   ||
> (nistk283)  ||2825.7  ||  27718.5||   9.81   ||
> (nistk409)  ||1745.8  ||  11634.2||   6.66   ||
> (nistk571)  || 763.2  ||   5930.9||   7.77   ||
> (nistb163)  ||6382.5  ||  60729.6||   9.52   ||
> (nistb233)  ||4881.9  ||  35230.4||   7.22   ||
> (nistb283)  ||2651.6  ||  24456.4||   9.22   ||
> (nistb409)  ||1640.3  ||  10228.6||   6.24   ||
> (nistb571)  || 693.8  ||   5172.1||   7.45   ||
> |||| ||  ||
> ||||-||--||
>
>
> The results for a Core i5-3210M @ 2.50 GHz (Ivy Bridge) in ECDH op/s:
>
> Curve   || OpenSSL 1.0.1e || This patch  || Speedup  ||
> ||||-||--||
> |||| ||  ||
> (nistk163)  ||3271.5  ||  28087.3||   8.59   ||
> (nistk233)  ||2504.9  ||  15106.0||   6.03   ||
> (nistk283)  ||1317.0  ||   9030.5||   6.86   ||
> (nistk409)  || 772.1  ||   3880.8||   5.03   ||
> (nistk571)  || 327.3  ||   1821.1||   5.56   ||
> (nistb163)  ||3067.9  ||  24357.1||   7.94   ||
> (nistb233)  ||2424.9  ||   3147.3||   5.42   ||
> (nistb283)  ||1227.0  ||   7765.1||   6.33   ||
> (nistb409)  || 709.7  ||   3319.9||   4.68   ||
> (nistb571)  || 296.2  ||   1563.9||   5.28   ||
> |||| ||  ||
> ||||-||--||
>
>
>
> ECDSA performance
> --
>
> The performance was measured by using openssl speed utility as follows:
>
> $ openssl speed ecdsa
>
>
> The results for a Core i7-4770 CPU @ 3.40GHz (Haswell):
>
> Curve  ||  OpenSSL 1.0.1e ||This patch || Speedup ||
> ---||-||---||-||
>|| sign/s verify/s || sign/s  verify/s  || sign/s verify/s ||
>||-||---||-||
> (nistk163) || 6,465.3 3,159.5 || 36,872.6 26,508.4 ||  5.708.39   ||
> (nistk233) || 3,259.2 2,419.8 || 22,998.4 15,557.1 ||  7.066.43   ||
> (nistk283) || 2,204.7 1,355.7 || 16,884.9 11,003.2 ||  7.668.12   ||
> (nistk409) ||   977.0   839.1 ||  8,150.0  4,845.0 ||  8.345.77   ||
> (nistk571) ||   466.4   368.3 ||  4,424.1  2,533.6 ||  9.496.88   ||
> (nistb163) || 6,487.3 3,043.9 || 35,110.0 24,904.8 ||  5.418.18   ||
> (nistb233) || 3,279.2 2,348.0 || 21,468.8 14,095.6 ||  6.556.00   ||
> (nistb283) || 2,196.4 1,283.5 || 15,602.7  9,888.5 ||  7.107.70   ||
> (nistb409) ||   976.3   786.9 ||  7,423.1  4,361.9 ||  7.605.54   ||
> (nistb571) ||   466.6   341.0 ||  3,977.0  2,251.6 ||  8.526.60   ||
>|| ||   || ||
> ---||-||---||--

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 

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

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

[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: ssl3_get_cert_verify performance

[Andrey Kulikov]

I'm affraid flamegraphs for two different servers with two different
OpenSSL libraries without information about type of load it was collected
with and without any information other than "smth. started spending much
more time than it was" can not give much information about root cause for
the issue.

You may start with:
1. Describing you test procedure. (what are you measuring? Handshakes? Data
transfer? Multithreaded?)
2. Describing test environment (type of certificates, key length, used
chiphersuites, etc)
3. Measure performance differences in absolute values (ms, handshakes per
second, etc)
4. Measure nginx perfromance with two different OpenSSL versions.
5. Measure your server performance with two different OpenSSL versions.
6. Share your findings.

On 5 January 2013 13:14, Fedor Indutny  wrote:

> Hello devs,
>
> Right now I'm doing a lot of benchmarks, trying to figure out how to make
> my https server as fast as are others (for example, nginx). I've found that
> somewhere between 0.9.8 and 1.0.1c ssl3_get_cert_verify has started
> spending much more time than it was.
>
> I wonder if you're aware of it, or if this thing can depend on some
> SSL_CTX mode/flag.
>
> Here are flamegraphs for you to make it more clearer what I'm talking
> about:
>
> * My server (openssl1.0.1c) - http://blog.indutny.com/f/tlsnappy-x64.svg
> * Nginx (openssl0.9.8) - http://blog.indutny.com/f/nginx.svg
>
> And here are sources of my server, just in case if you need them to figure
> something out:
> https://github.com/indutny/tlsnappy/blob/master/src/tlsnappy.cc
>
> Thank you,
> Fedor.
>

Re: [openssl.org #2951] [PATCH] Fix speed.c to fork N threads

[Andrey Kulikov]

> -   for(n=0 ; n < multi ; ++n)
> +   for(n=0 ; n <= multi ; ++n)

Isn't
|[0..n)| = n
and
|[0..n]| = n +1
?

I.e this patch will do one more iteration than expected?
Assume multi = 1, for example.

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

[Andrey Kulikov]

> In my case, handshake rate drops down to 5-6% on the same hardware in 1.0.1c
in comparison to 1.0.0i.
I was wrong. Handshake performance degradation is about 10%.

First guilty function is EVP_DigestSignFinal what is perform copying of
supplied context.

When I replaces in tls1_P_hash() EVP_DigestSignFinal()  by it's dull
equvivalent, not performing context copying i got these numbers:

OpenSSL 1.0.1c - EVP_DigestSignFinalNoCopy
Digest init called 105 times.
Digest copy called 70 times.
Digest cleanup called 174 times.

And  get 5% performance improvement in comparison to original OpenSSL 1.0.1c
(Still, 5% worth than 1.0.0)

Second suspect is re-initialization of MAC context in tls1_P_hash()'s loop.
While it was real re-initialization when there was HMAC_Init_ex(), what
performed initialization of internal i_ctx and o_ctx only when necessary,
with EVP_DigestSignInit it is full re-creating, and internal i_ctx and
o_ctx is always initialized.

This is why we see 3 times more 'digest init' calls.
Also, there could be other reasons for what is still hidden from me.


Eliminating EVP_DigestSignFinal overhead in tls1_P_hash() by replasing it
with calls, what do not perform context copying is trivial.
But how can we properly perfrom MAC true re-initialization instead of
creation from very beggining?




> 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.
>
>
>
> Is there any way to reduce hash objects usage, while keeping TLS 1.1/1.2
> features?
>
>

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

[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 #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 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?

Re: OpenSSL and CRIME

[Andrey Kulikov]

Hi,

> OpenSSL enables zlib by default.

Could you please advice for what version and platform this is true?

openssl-1.0.1c for linux-elf
has no-zlib configured by default.

Re: Multithreading performance patches

[Andrey Kulikov]

Hi Fedor,

Thanks for valuable contribution!
About your "second" patch: could you please advice, what the intended way
to use BIO_TYPE_NO_EX_DATA in real-life applications?
For example TSL-server. Do you have any numbers on performance gain when
using this approach?

Re: Why x509 displays ECDSA pub. key size two times less than actual?

[Andrey Kulikov]

> As I said before it is convention when talking about a _key size_ to mean
the
> number of bits in the order (i.e. the size of the private key).

If we talking about just 'key size', then yes, we assume private key size.
But I've never heard of convention to assume that for ECC public key size
is equal to private key size.
If this convention defined, or at least mentioned somewhere, it would be
wonderful to have a reference to this document.

Re: Why x509 displays ECDSA pub. key size two times less than actual?

[Andrey Kulikov]

> Talking about the bit-length of the public key data is not particularly
> helpful because it depends on whether it is in compressed format or not.

Sorry, but size of public key does not depends on size of it's
representation.
It can be compressed, Base64 encoded, etc., but it does not change size of
original data.

x509 command output was mentioned only for example.
The aim was is to understand, why OpenSSL (and not only) consider size of
something as twice as less of actual size, while displaying data itself on
next line of proper size.

Title for this data is 'Public key', not 'Size of private key, public key
in this certificate related to'.
What trows my programmer's ming into cognitive dissonance.

Is it bug, feature, or [yet] hidden convention?

Re: Why x509 displays ECDSA pub. key size two times less than actual?

[Andrey Kulikov]

> For ECC the key size is stated to be "size of n in bits" (where n is the
order).

'n' is an order of base point 'G' on EC - i.e. size of private key (what
should be in range [1; n-1]), not public.
Thus, I understand that it is a size of EC private key 'd', what shown in
table 3 in SEC 1.

Re: Why x509 displays ECDSA pub. key size two times less than actual?

[Andrey Kulikov]

> By convention the key size for ECC is given as the number of bits in the
order.
> E.g. see table 3 in SEC 1.

Could you please provide a reference to document, defining this convention?
Unfortunatelly table 3 in section B.2.1 of SEC 1 (both v1 and v2) shows
only comparison of "security level" of diffefent algorithmsm and not
related to the questions.




>

Why x509 displays ECDSA pub. key size two times less than actual?

[Andrey Kulikov]

Hello,

Let's generate certificate with ECDSA key over 256 bit field:

openssl ecparam -out key.pem -name prime256v1 -genkey
openssl req -newkey ec:key.pem -x509 -nodes -days 365 -keyout pkey.pem -out
cert.pem

Then part of output of
openssl x509 -text -in  cert.pem
will be:

Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:89:9e:f7:b0:fa:69:b7:e3:1b:62:e8:a5:97:56:
68:4b:36:74:fe:df:e7:f8:fe:a8:a2:0b:a8:2b:a3:
2c:80:d1:6f:4e:00:b8:70:92:b1:2b:20:e9:ff:c4:
f2:10:76:72:4c:34:80:30:a3:37:b5:60:e1:a4:a7:
07:e0:f8:2a:9e
ASN1 OID: prime256v1


Why it states that pub. key is only 256 bits long?
By definition public key consists of two coordinates on EC curve, each 256
bits (for selected curve) long. I.e. 512 bits in total.
Moreover, pub. key dump contains 512 bits too... (04 in first byte
indicates that uncompressed points representation used)


Code in ec_ameth.c::do_EC_KEY_print() calculates public key size as order
of curve used.
What gives us half of real ECDSA pub. key size.

Does this behavior a bug, or somewhere documented convention?
I've studied FIPS 180-3, SP 800-57 and SEC 1: "Elliptic Curve Cryptography"
but didn't find any indications of such conventions.

Maybe I overlooked something?


P.S. Interesting, but Windows displays size of pub. key in this certificate
also as 256 bits long.

Re: [Q] OpenSSL memory usage per connection

[Andrey Kulikov]

Using SSL_MODE_RELEASE_BUFFERS option can drop memory footprint from 50K to
around 5K per connection.
It is useful when we'll have big number of connections.
Also it may prevent excessive swapping.

On 7 April 2012 08:22, eric wang  wrote:

> Dear OpenSSL developers
>
> We got a question on OpenSSL (0.9.8 or later) and hope to get help from
> the community.
>
> What is the memory usage per connection for OpenSSL 0.9.8 or 1.0.1?  What
> factors affect the memory usage, e.g. build options, authentication method?
>
> Really appreicate it if you can help
>
> Thanks
>

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

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

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

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

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

On 14 December 2011 01:45, Andrey Kulikov via RT  wrote:
> 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  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?
>>
>>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

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

[Andrey Kulikov]

The same for SNAP-20111213

On 14 December 2011 19:54, Andrey Kulikov via RT  wrote:
>        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.
__
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]

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

libGL17.10

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

[Andrey Kulikov]

> Where is it caught?
Addentum: programm caught in different functions: I saw
OPENSSL_Cleanse(), EVP_DigestUpdate(), sha1_ and others.

I provided   'thread apply 1 info reg'  only if it get caugth in
sha1_block_data_order_ssse3 ().


>
> 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
>  8    Thread 8820.0x2280 0x77b2f861 in ntdll!RtlUpdateClonedSRWLock
> () from /cygdrive/c/Windows/system32/ntdll.dll
>  7    Thread 8820.0x19bc 0x77b2fd21 in ntdll!RtlFindSetBits () from
> /cygdrive/c/Windows/system32/ntdll.dll
>  6    Thread 8820.0x2bd0 0x77b2fd9d in ntdll!RtlFindSetBits () from
> /cygdrive/c/Windows/system32/ntdll.dll
>  5    Thread 8820.0x2b40 0x77b2f861 in ntdll!RtlUpdateClonedSRWLock
> () from /cygdrive/c/Windows/system32/ntdll.dll
>  4    Thread 8820.0x1634 0x77b300ed in
> ntdll!RtlEnableEarlyCriticalSectionEventCreation () from
> /cygdrive/c/Windows/system32/ntdll.dll
>  2    Thread 8820.0x1f18 0x77b2f895 in ntdll!RtlUpdateClonedSRWLock
> () from /cygdrive/c/Windows/system32/ntdll.dll
>  1    Thread 8820.0x272c _sha1_block_data_order_ssse3 () at sha1-586.s:1689
> (gdb) thread apply 1 info reg
>
__
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   

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

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

Re: [openssl.org #2650] major ssl read/ write performance improvement - updated

[Andrey Kulikov]

Hello Michael,

I have tested youe patch.
It is working stable at least with ccgost engine (and without any
engine too, of cource).
Thanks for contribution!

Could you please describe, what was your test environmnet and test methodology?
How did you measure that doubling read/write speed? What tool/profiler
do you use?
How it depends from SSL record size?
What the overall speed improvement if we'll count OS IO?

I'm asking because I'm trying to measure performance improvement your
changes can give with my crypto-accelerator, and my results not even
close to doube read/write speed.
But my test resources are limited for the moment, and it is possible
it is due to these limitations.

In any case, I guess comunity will be grateful if your share your expirience.

WBR,
Andrey

On 5 December 2011 14:33, Deng Michael via RT  wrote:
> Hi,
>  I have changed the mac code which gives substantial improvement for both 
> read and write (not handshake)
>
>  The saving is fairly major, on cpu with cryto acceleration, the change
> can more than double the overall ssl read /write speed for 1K record
> excluding OS IO time.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[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: major ssl read/ write performance improvement

[Andrey Kulikov]

Hello,

Thanks for interesting contribution!

Unfortunately when I apply the patch s_server failed with SEGFAULT,
when using ccgost engine (and possibly others) here:

EVP_DigestSignFinal
if (sctx)
> r = md_ctx_ptr->pctx->pmeth->signctx(md_ctx_ptr->pctx,
   sigret, siglen, 
md_ctx_ptr);
else

because of
pmeth->signctx == 0x08
(or something like this)

When I use RSA certificate segfault didn't occur, as pmeth->signctx
points to some valid place.

Stacktrace is:

EVP_DigestSignFinal (ctx=0x87802b0, sigret=0xbfd5f6dc
\"\\b\\002x\\b\\001\", siglen=0xbfd5f698)
tls1_mac (ssl=0x877a088, md=0xbfd5f6dc \"\\b\\002x\\b\\001\", send=0)
ssl3_get_record (s=0x877a088)
ssl3_read_bytes (s=0x877a088, type=22, buf=0x8788d50 \"\\020\", len=4, peek=0)
ssl3_get_message (s=0x877a088, st1=8608, stn=8609, mt=-1, max=514,
ok=0xbfd5f8b8)
ssl3_get_cert_verify (s=0x877a088)
ssl3_accept (s=0x877a088)
ssl3_read_bytes (s=0x877a088, type=23, buf=0x877e7e8 \"\", len=4096, peek=0)
ssl3_read_internal (s=0x877a088, buf=0x877e7e8, len=4096, peek=0)
ssl3_read (s=0x877a088, buf=0x877e7e8, len=4096)
SSL_read (s=0x877a088, buf=0x877e7e8, num=4096)
ssl_read (b=0x8779370, out=0x877e7e8 \"\", outl=4096)
BIO_read (b=0x8779370, out=0x877e7e8, outl=4096)
buffer_gets (b=0x8777e00, buf=0x877a7e0 \"\", size=16382)
BIO_gets (b=0x8777e00, in=0x877a7e0 \"\", inl=16383)
www_body (hostname=0x0, s=6, context=0x0)
do_server (port=443, type=1, ret=0x8248ac8, cb=0x8072d24 ,
context=0x0)
s_server_main (argc=0, argv=0xbfd602b8)
do_cmd (prog=0x8770868, argc=16, argv=0xbfd60278)
main (Argc=16, Argv=0xbfd60278)


Could you please advice, what going wrong with your code???

Go check it you need:
1. Adjust your openssl.cnf file, bu adding there:

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
default_algorithms = ALL

somewhhere before "[ new_oids ]" (if we talking about sample config
file from OpenSSL distribution).

2. Generate private key:
./apps/openssl genpkey -engine gost -algorithm gost2001 -pkeyopt
paramset:A -out botkey.p8

3. Create self-sign certificate
./apps/openssl req -x509 -days 1095 -subj
'/C=US/CN=ccgost_srv/O=sam...@mail.com' -engine gost -new -key
botkey.p8 -out botcert.cer

4. Run s_server
./apps/openssl s_server  -engine gost  -tls1 -www -accept 443  -state
 -cert botcert.cer  -key botkey.p8 -cipher "aGOST01"

5. Run s_client
./apps/openssl s_client -tls1 -connect 192.168.10.103:443 -msg

Well Here s_client will crash with segfault... But if you'll
connect via browser - s_server will crash.


Please let me know if you'll have any questions.

Andrey.


On 30 November 2011 05:56, Deng Michael  wrote:
> Thanks Steve for the comment.
>
>
> I guess there are other ways to do similar things, since I was not sure about 
> the intentions of the original code I was trying to make the change in a way 
> such that when checkpoint is not call it should behave like before. Adding a 
> new field for me is less likely to interfere with other code. It seems to me 
> the three evp_md_ctxs contained within the hmac_md_ctx has the data for 
> restoring the state but I was not sure. Also the new field serves as a flag 
> to tell if it has checkpoint data (I could have used an existing flag). My 
> patch also contains some hacking I would think.
>
>
> anyway the real saving comes from redo of state preserving of the evp_md_ctx 
> that contains evp_pkey_ctx which in turn contains hmac_ctx which again 
> contains three evp_md_ctx's. the dup of these are called in
>
> tls1_mac() similar place for ssl3
> and
> EVP_DigestSignFinal()
>
> these two are the super expensive ones (real super)
>
> the copy of ctx in
> HMAC_Final() --- this one is not too bad
>
>
> can be simplified.
>
>
> I would think the saving is so much that is worth changing maybe in future 
> releases.
>
> regards,
> Michael
>
>
>
> - Original Message -
> From: Dr. Stephen Henson 
> To: openssl-dev@openssl.org
> Cc:
> Sent: Tuesday, November 29, 2011 1:21 PM
> Subject: Re: major ssl read/ write performance improvement
>
> On Mon, Nov 28, 2011, Deng Michael wrote:
>
>> Hi,
>>
>> I have changed the mac code which gives substantial improvement for both 
>> read and write (not handshake)
>>
>> The saving is fairly major, on cpu with cryto acceleration, the change can 
>> more than double the overall ssl read /write speed for 1K record excluding 
>> OS IO time. this implies the change removed majority of the code overhead 
>> for read and write.
>>
>> The basic idea is to remove all the EVP_MD_CTX duplications (which is very 
>> cpu intensive) during read and write. the original code involves numerous 
>> memory allocations and frees for each read or write all due to the ctx's 
>> deep copy.
>>
>> the new way of keeping the ctx is to make it do state checkpoint and restore 
>> instead of deep copy, after this chan

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

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

[Andrey Kulikov via RT]

Now it is not possible to disable sending renegotiation_info extension from
server.
The only way to do it - is to disable TLS extension completelly, what may
not be considered as acceptable.

But this is required for compatibility with clients, which can't understand
this extension
(but do require other extensions).
Among others, it is Windows clients, which do not support KB980436 correctly
(KB980436 is a Windows Update, implemented RFC5746 (
http://tools.ietf.org/html/rfc5746)
"TLS Renegotiation Indication Extension"
http://support.microsoft.com/kb/980436

When this update is not installed, and server do send renegotiation_info
extension - they works.
But if this update is installed - they crash/not works when received
renegotiation_info extension. :(

Supplied patch introduces new option SSL_OP_DO_NOT_SEND_RI.
When it set to context, renegotiation_info extension will not be sent.
Please note, this will not disable secure renegotiation, but just disable
sending renegotiation_info extension.
(which may be considered as equal).

This is enabled bu specifying option
-not_send_ri
to s_server and s_client


In additional, patch introduced option -handle_cpro_bug to s_server, which
explicitly enables option SSL_OP_CRYPTOPRO_TLSEXT_BUG.
Yes, it also possible by specifying -bugs option to s_server, but presence
of SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER in SSL_OP_ALL prevents server from
parsing ClientHello at all:

SSL_accept:error in SSLv3 read client hello B
3066799772:error:1408F044:SSL routines:SSL3_GET_RECORD:internal
error:s3_pkt.c:308:



In order to apply patch go to OpenSSL working directory and execute follwing
command:

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


Please let me know if you have any questions.

Andrey.

P.S. There is no more slots for new SSL_OP_* - I used the last available
one! :(

Now it is not possible to disable sending renegotiation_info extension from server.The only way to do it - is to disable TLS extension completelly, what may not be considered as acceptable.But this is required for compatibility with clients, which can't understand this extension 
(but do require other extensions).Among others, it is Windows clients, which do not support KB980436 correctly(KB980436 is a Windows Update, implemented RFC5746 (http://tools.ietf.org/html/rfc5746) 
"TLS Renegotiation Indication Extension"http://support.microsoft.com/kb/980436When this update is not installed, and server do send renegotiation_info extension - they works.
But if this update is installed - they crash/not works when received renegotiation_info extension. :(Supplied patch introduces new option SSL_OP_DO_NOT_SEND_RI.When it set to context, renegotiation_info extension will not be sent.
Please note, this will not disable secure renegotiation, but just disable sending renegotiation_info extension.(which may be considered as equal).This is enabled bu specifying option-not_send_rito s_server and s_client
In additional, patch introduced option -handle_cpro_bug to s_server, which explicitly enables option SSL_OP_CRYPTOPRO_TLSEXT_BUG.Yes, it also possible by specifying -bugs option to s_server, but presence of SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER in SSL_OP_ALL prevents server from parsing ClientHello at all:
SSL_accept:error in SSLv3 read client hello B3066799772:error:1408F044:SSL routines:SSL3_GET_RECORD:internal error:s3_pkt.c:308:In order to apply patch go to OpenSSL working directory and execute follwing command:
patch -p1 -l -u -b -i not_send_reneg_info.patch Please let me know if you have any questions.Andrey.P.S. There is no more slots for new SSL_OP_* - I used the last available one! :(


not_send_reneg_info.patch
Description: Binary data

Re: What the resons to use SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION may be?

[Andrey Kulikov]

Sorry,

Some explanations available in sources ssl/t1_lib.c:
==
   - Applications must  use SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
 if they provide for changing an explicit servername context for the
session,
 i.e. when the session has been established with a servername extension.

==

So this option must be used if server use server_name extension.

But what will happens if server do use server_name extension, but not set
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION?
What the security consequences will be?
I understand there is some, but can't figure out what exactly...

The only thing I was able to find is this:
http://mail-archives.apache.org/mod_mbox/httpd-bugs/200409.mbox/%3c20041001143012.6555.qm...@nagoya.betaversion.org%3E
If two virtual servers configured to use different ciphersuites, there is a
possiblility for malicious client to establish session with one server with
it's ciphersuite, and then renegotiate connection with other server.
And ciphersuie remains unchanged.
I can't say for sure is it security or compatibility issue.

Would be really appreciated for any comments.

Best wishes,
Andrey


On 18 June 2011 15:58, Andrey Kulikov  wrote:

> Hello,
>
> There is an option available:
> SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
> Descroption laconicaly states:
> "When performing renegotiation as a server, always start a new session
> (i.e., session resumption requests are only accepted in the initial
> handshake). This option is not needed for clients. "
>
> But I can't find any information WHY and WHEN I should (or should not) use
> this option.
> Could anyone explain, what the purpose of this option?
>
> I.e. what the drawback of allowing session resumption during renegotiation?
> Is it for compatibility with buggy clients?
> Or is it some security countermeasure?
>
> Would be really appreciated for any comments.
>
> Best wishes,
> Andrey
>

What the resons to use SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION may be?

[Andrey Kulikov]

Hello,

There is an option available:
SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
Descroption laconicaly states:
"When performing renegotiation as a server, always start a new session
(i.e., session resumption requests are only accepted in the initial
handshake). This option is not needed for clients. "

But I can't find any information WHY and WHEN I should (or should not) use
this option.
Could anyone explain, what the purpose of this option?

I.e. what the drawback of allowing session resumption during renegotiation?
Is it for compatibility with buggy clients?
Or is it some security countermeasure?

Would be really appreciated for any comments.

Best wishes,
Andrey

Re: s_client -reconnect with DTLS

[Andrey Kulikov]

Hello,

I'm sure you'll get help faster, if you describe:
1. What are you doing exactly.
2. What do you see.
3. What do you expect to see.

This is absolutelly necessary steps, as all telepathist is on vacation now.

On 22 April 2011 15:50, N. J.  wrote:

> Hi again,
>
>
> I am not sure if someone can help confirming that the "-reconnect" option
> is broken with the dtls implementation? Please refer to my email below.
> Looking forward for your support.
>
> Regards,
> Nadhem
>
> --
> **
> Hi there,
>
> I have been trying to get the s_client "-reconnect" option working with my
> s_server but had no luck when using DTLS, "-dtls1".
> I could not find any information why it is not working so I wonder if this
> is broken in openssl 1.0.0a. If so, is there any fix?
>
> Thanks in advance,
> Nadhem
>

Re: [openssl.org #2496] [PATCH] Fix compile problems when various ciphers are disabled

[Andrey Kulikov]

Tim,

Seems that you miss to attach a file with actual patch...

On 12 April 2011 11:13, Tim Jackson via RT  wrote:

> When turning off various ciphers, OpenSSL doesn't always compile. The
> attached patches fix various issues with OpenSSL when ciphers (particularly
> RSA or DSA) are turned off. These patches were requested in the attached
> thread
>

Re: [openssl.org #2494] [SEC FIX]: Add premaster cleaning for GOST ciphersuites: All platforms, 1.0.0d

[Andrey Kulikov via RT]

O-o...

Wrong file attached!
Sorry for this - please find correct file attached.

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

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


On 8 April 2011 17:18, Andrey Kulikov via RT  wrote:

> Hello,
>
> There is a patches made in the past to cleanse sensitive data, such as
> premaster sectes for DH ciphersuites, in pemory.
> But is missed for GOST ones.
>
> Please find attached a patch which solve this issue.
>
> Both for server and client.
> Also it shorten the distance between premaster generation and cleaing to
> decrease possible exposure time.
>
> To apply patch use following command in root of current OpenSSL development
> tree:
>
> patch -p1 -l -u -b -i
>
> Andrey
>
>
> Hello,
>
> There is a patches made in the past to cleanse sensitive data, such as
> premaster sectes for DH ciphersuites, in pemory.
> But is missed for GOST ones.
>
> Please find attached a patch which solve this issue.
>
> Both for server and client.
> Also it shorten the distance between premaster generation and cleaing to
> decrease possible exposure time.
>
> To apply patch use following command in root of current OpenSSL development
> tree:
>
> patch -p1 -l -u -b -i
>
> Andrey
>
>

O-o...Wrong file attached!Sorry for this - please find correct file attached.
To apply patch use following command in root of current OpenSSL development
tree:

patch -p1 -l -u -b -i prem_cleanup_gost.patch On 8 April 2011 17:18, Andrey Kulikov via RT <r...@openssl.org> wrote:
Hello,

There is a patches made in the past to cleanse sensitive data, such as
premaster sectes for DH ciphersuites, in pemory.
But is missed for GOST ones.

Please find attached a patch which solve this issue.

Both for server and client.
Also it shorten the distance between premaster generation and cleaing to
decrease possible exposure time.

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

patch -p1 -l -u -b -i

Andrey

Hello,There is a patches made in the past to cleanse sensitive data, such as premaster sectes for DH ciphersuites, in pemory.But is missed for GOST ones.Please find attached a patch which solve this issue.

Both for server and client.Also it shorten the distance between premaster generation and cleaing to decrease possible exposure time.To apply patch use following command in root of current OpenSSL development tree:

patch -p1 -l -u -b -i Andrey



prem_cleanup_gost.patch
Description: Binary data

Re: [openssl.org #2494] [SEC FIX]: Add premaster cleaning for GOST ciphersuites: All platforms, 1.0.0d

[Andrey Kulikov]

O-o...

Wrong file attached!
Sorry for this - please find correct file attached.

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

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


On 8 April 2011 17:18, Andrey Kulikov via RT  wrote:

> Hello,
>
> There is a patches made in the past to cleanse sensitive data, such as
> premaster sectes for DH ciphersuites, in pemory.
> But is missed for GOST ones.
>
> Please find attached a patch which solve this issue.
>
> Both for server and client.
> Also it shorten the distance between premaster generation and cleaing to
> decrease possible exposure time.
>
> To apply patch use following command in root of current OpenSSL development
> tree:
>
> patch -p1 -l -u -b -i
>
> Andrey
>
>
> Hello,
>
> There is a patches made in the past to cleanse sensitive data, such as
> premaster sectes for DH ciphersuites, in pemory.
> But is missed for GOST ones.
>
> Please find attached a patch which solve this issue.
>
> Both for server and client.
> Also it shorten the distance between premaster generation and cleaing to
> decrease possible exposure time.
>
> To apply patch use following command in root of current OpenSSL development
> tree:
>
> patch -p1 -l -u -b -i
>
> Andrey
>
>


prem_cleanup_gost.patch
Description: Binary data

[openssl.org #2494] [SEC FIX]: Add premaster cleaning for GOST ciphersuites: All platforms, 1.0.0d

[Andrey Kulikov via RT]

Hello,

There is a patches made in the past to cleanse sensitive data, such as
premaster sectes for DH ciphersuites, in pemory.
But is missed for GOST ones.

Please find attached a patch which solve this issue.

Both for server and client.
Also it shorten the distance between premaster generation and cleaing to
decrease possible exposure time.

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

patch -p1 -l -u -b -i

Andrey

Hello,There is a patches made in the past to cleanse sensitive data, such as premaster sectes for DH ciphersuites, in pemory.But is missed for GOST ones.Please find attached a patch which solve this issue.
Both for server and client.Also it shorten the distance between premaster generation and cleaing to decrease possible exposure time.To apply patch use following command in root of current OpenSSL development tree:
patch -p1 -l -u -b -i Andrey


server_cert_from_engine4.patch
Description: Binary data

[openssl.org #2476] [PATCH] Underinitialized array ssl_cipher_methods: 1.0.0d-1.0.1-stable-SNAP-20110321: All platforms.

[Andrey Kulikov via RT]

In file "ssl/ssl_ciph.c" static array ssl_cipher_methods declared as having
SSL_ENC_NUM_IDX elements.
SSL_ENC_NUM_IDX = 12, but only 11 elements initialized.

Although it may be not critical, it defenitely a bad practice.

Please find attached file: underinit_ssl_chip_array.patch
It add one more NULL to array initialization.

Patch created using this command:
diff -rupN openssl-1.0.0d/ openssl-1.0.0d-patched/ >
underinit_ssl_chip_array.patch

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

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


Patch created against 1.0.0d, but the same issue is in
1.0.1-stable-SNAP-20110321

Andrey.

In file "ssl/ssl_ciph.c" static array ssl_cipher_methods declared as having SSL_ENC_NUM_IDX elements.SSL_ENC_NUM_IDX = 12, but only 11 elements initialized.Although it may be not critical, it defenitely a bad practice.
Please find attached file: underinit_ssl_chip_array.patch It add one more NULL to array initialization.Patch created using this command:diff -rupN openssl-1.0.0d/ openssl-1.0.0d-patched/ > underinit_ssl_chip_array.patch 
To apply pach use follwing command in current OpenSSL root dev. directory:patch -p1 -l -u -b -i underinit_ssl_chip_array.patchPatch created against 1.0.0d, but the same issue is in 1.0.1-stable-SNAP-20110321
Andrey. 


underinit_ssl_chip_array.patch
Description: Binary data

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

[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

HowTo: Engine-specific TLS master secret generation?

[Andrey Kulikov]

Hello,

Now OpenSSL generates master secret and read/write keys inside the library,
left only premaster secret decryption to the engine.

In case of hardware-based TLS engine it could be not an option, as there may
be no possibility to set read/write keys from outside (or it may be
restricted according to some rules of such hardware usage).

If someone would needed to implement such device support in OpenSSL:
1. How would you estimate required effort?
2. What is the best base OpenSSL version to start with?
3. What is necessary to take into account, but may be not visible from the
beginning?

Would be really appreciated for any answer.

Andrey.

Re: adding new encryption algorithm to OpenSSL

[Andrey Kulikov]

This explanation may help you to add new algorithms to OpenSSL:

http://www.mail-archive.com/openssl-users@openssl.org/msg59630.html

On 18 January 2011 08:59, M. V.  wrote:

> hi,
>
> for a project, i have to add my own encryption algorithm to racoon (part of
> ipsec-tools) in freebsd. i realized racoon uses openssl libraries for
> encryption algorithms. so, i wanted to know , does anyone have any
> experience in doing such thing? does anyone have any suggestions for me?
>
> 1- what's the best and easiest way? adding my algorithm to racoon, openssl
> or else (as a dynamic library, etc)?
> 2- is there any example, code template or documentation which could help me
> doing this?
>
> thank you.
>
>

What the purpose of EVP_PKEY_derive() function?

[Andrey Kulikov]

Hello,

I'm exploring how to implement custom engine, and can't undestand the
purpose of EVP_PKEY_derive() function.
It is possible to set pointer to it's implementation using
EVP_PKEY_meth_set_derive() call.

But it used only in *pkeyutl* command.
It is not used in SSL handshake.

The only engine which set it is "ccgost", but as I understand in not used at
all.

According to pkeyutl command documentation it is used for "key derivation
(agreement) operations".

Could please anyone explain, what it is designed for, and according to which
standard it should be implemented in new engine?
Is it required at all?

Andrey.

Re: What is the REALLY proper way to use an ENGINE?

[Andrey Kulikov]

On 4 January 2011 16:54, Dr. Stephen Henson  wrote:

>
> I can't see how that would happen:
>
>
I find a way to reproduce it: just call ENGINE_load_builtin_engines() twice.
Or call ENGINE_load_builtin_engines() after OPENSSL_config() which calls it
too.

It happens because internal ccgost AMETH structures are static (which,
obviously, does matter).
First call of ENGINE_load_builtin_engines() creates new ENGINE structure and
store it in some list, etc.

Second call to ENGINE_load_builtin_engines() creates new engine structure
AGAIN, but AMETH part of it reffers to the same static variable
(ameth_GostR3410_2001).
But ENGINE_add() in second call fails, because engine with the same ID
already in the list.
So, reference count not increased, and just created engine released in the
very next line.
AMETH structures being destoryed, and it makes them invalid for originally
created engine too (because there is only one such structure).


Ways to avoid it:
1. Make ccgost engine allocates AMETH structures dynamically.
As there is no other engines, used this functionality (calls to
ENGINE_set_pkey_asn1_meths() ), I can't compare.
But from my point of view this is a bad idea, because it introduces
unnecessary complexity.
And, there is no clear reason to create them more that once.
Of cource we can imagine some engine which provides different NID_id's
depend on configuration. But ccgost is not the one.

2. Make ENGINE_load_builtin_engines() single-callable.
Just like OPENSSL_config().
I can't see any reason why it have to be called more that once.


Would be really appreciated if guru comment on that.

Andrey.

Re: What is the REALLY proper way to use an ENGINE?

[Andrey Kulikov]

Thanks for a explanations.

Let's consider following main, using ccgost engine:

main(){

OPENSSL_config(NULL);
ENGINE *e = ENGINE_by_id("gost");
ENGINE_init(e);
ENGINE_free(e);
ENGINE_set_default(e, ENGINE_METHOD_ALL);
OpenSSL_add_all_algorithms();

// emulating ENGINE_load_private_key()
EVP_PKEY *pkey = EVP_PKEY_new();
pkey->ameth = ENGINE_get_pkey_asn1_meth(e, NID_id_GostR3410_2001);
bla-bla-bla...
//end emulating


EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(pkey, e);
}

Result ctx is always NULL.
It happens because ENGINE_get_pkey_asn1_meth() returns pointer to corrupted
internall ccgost structure "ameth_GostR3410_2001".
It IS initialized, then being freed. And contains garbage. Specifically
pkey->ameth->pkey_id contains some random value instead of 811
(NID_id_GostR3410_2001).

Is this code contain some error or invalid engine API usage?

On 4 January 2011 06:23, Dr. Stephen Henson  wrote:

> On Tue, Jan 04, 2011, Andrey Kulikov wrote:
>
> > If we take a look at any ENGINE_load_XXX function, we find that they all
> has
> > similar structure:
> >
> > ENGINE *toadd = engine_XXX();
> > if(!toadd) return;
> > ENGINE_add(toadd);
> > ENGINE_free(toadd);
> > ERR_clear_error();
> >
> > My question is: why we need call ENGINE_free(toadd) ??
>
> To avoid a memory leak.
>
> When you call engine_XXX() you get a reference to the ENGINE. When it is
> added
> to the ENGINE list the reference count is incremented. When you call
> ENGINE_free() the count is decremented and the ENGINE is freed only if the
> reference count is zero.
>
> Steve.
>
>

Re: What is the REALLY proper way to use an ENGINE?

[Andrey Kulikov]

Update: adding
ENGINE_init(e)
after
e = ENGINE_by_id("XXX");

doesn't make any difference, as in my case functional reference count is
8(???) at the moment of ENGINE_init(e)  call, so engine is not
re-initialised. :(

On 4 January 2011 04:12, Andrey Kulikov  wrote:

> If we take a look at any ENGINE_load_XXX function, we find that they all
> has similar structure:
>
> ENGINE *toadd = engine_XXX();
> if(!toadd) return;
> ENGINE_add(toadd);
> ENGINE_free(toadd);
> ERR_clear_error();
>
> My question is: why we need call ENGINE_free(toadd) ??
> Somewhere inside it calls EVP_PKEY_asn1_free(), which besides everything
> else desroy all AMETH structures, created during engine initialization via
> EVP_PKEY_asn1_set_* .
>
> So, let's consider following example:
>
> CRYPTO_malloc_init();
> ERR_load_crypto_strings();
> ENGINE_load_builtin_engines();
>
> e = ENGINE_by_id("XXX");
> ENGINE_set_default(e, ENGINE_METHOD_ALL);
> OpenSSL_add_all_algorithms();
> OpenSSL_add_ssl_algorithms();
>
> EVP_PKEY *signing_key = ENGINE_load_private_key(e, NULL, NULL, NULL);
>
> // bla-bla-bla...
>
> And, if in engine load priv func we write something like
> EVP_PKEY *pkey = EVP_PKEY_new();
> pkey->ameth = ENGINE_get_pkey_asn1_meth(eng, NID_id_SOME_NID);
>
> it's not gonna work, because all ASN1 structures, carefully created by
> engine via calls to EVP_PKEY_asn1_set_* are invalid and possibly corrupted
> at this moment.
>
> Is it a design issue, or provided example is invalid (but it taken from
> openssl sources, hm...)?
>
>

What is the REALLY proper way to use an ENGINE?

[Andrey Kulikov]

If we take a look at any ENGINE_load_XXX function, we find that they all has
similar structure:

ENGINE *toadd = engine_XXX();
if(!toadd) return;
ENGINE_add(toadd);
ENGINE_free(toadd);
ERR_clear_error();

My question is: why we need call ENGINE_free(toadd) ??
Somewhere inside it calls EVP_PKEY_asn1_free(), which besides everything
else desroy all AMETH structures, created during engine initialization via
EVP_PKEY_asn1_set_* .

So, let's consider following example:

CRYPTO_malloc_init();
ERR_load_crypto_strings();
ENGINE_load_builtin_engines();

e = ENGINE_by_id("XXX");
ENGINE_set_default(e, ENGINE_METHOD_ALL);
OpenSSL_add_all_algorithms();
OpenSSL_add_ssl_algorithms();

EVP_PKEY *signing_key = ENGINE_load_private_key(e, NULL, NULL, NULL);

// bla-bla-bla...

And, if in engine load priv func we write something like
EVP_PKEY *pkey = EVP_PKEY_new();
pkey->ameth = ENGINE_get_pkey_asn1_meth(eng, NID_id_SOME_NID);

it's not gonna work, because all ASN1 structures, carefully created by
engine via calls to EVP_PKEY_asn1_set_* are invalid and possibly corrupted
at this moment.

Is it a design issue, or provided example is invalid (but it taken from
openssl sources, hm...)?

Re: s_client - debug arg make the difference

[Andrey Kulikov]

I had the same behaviour (different results in debug/not debug).
In my case answer was obvious: in debug environment I had different value
for OPENSSL_CONF env. variable, and that why in debug nothing works.

On 22 December 2010 16:58, Benjamin  wrote:

> Hello,
>
> Maybe a mistake, but on OpenSSL 1.0.0c (2 Dec 2010) the debug arg make a
> real difference in s_client usage, a difference that I can't explain ??
> Maybe a timing problem ??
>
> Edited for text visualisation :
>
>

Re: [openssl.org #2398] [PATCH] gost code cleanup

[Andrey Kulikov]

On 16 December 2010 16:31, Mark Andrews via RT  wrote:
> encountered a NULL pointer dereference in the gost code
> due to a undetected EVP_PKEY_assign() failure in pkey_gost01_paramgen().
>

Thnaks for report!

Could you please share a secret knowelege: why EVP_PKEY_assign() fails
in pkey_gost01_paramgen() in your case?
I eyeball their code, but can't find out why it can fails. (Except
passing incorrect pointers.)

Is it reproducible from command-line, or it happens in your specific code?

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

Re: 1.0.0a s_server with GOST certificate can't compute sha1 digest???

[Andrey Kulikov]

On 14 November 2010 06:10, Dr. Stephen Henson  wrote:
> On Sat, Nov 13, 2010, Andrey Kulikov wrote:
>
>>
>> Sorry to confuse you - I've mixed up versions and snapshot filenames.
>> I just re-check these snapshots of 1.0.0
>> ftp://ftp.openssl.org/snapshot/openssl-1.0.0-stable-SNAP-20101112.tar.gz
>> and 1.0.1
>> ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20101112.tar.gz
>>
>> I disable TSL in there:
>> ./config no-tls
>>
>> I add "-ssl3" parameter to s_server and s_client commands.
>>
>> ./apps/openssl s_server -ssl3  -www -engine gost -accept 4333  -state
>> -cert botcert.pem -key botkey.p8
>> ./apps/openssl s_client -ssl3 -engine gost  -connect localhost:4333
>>
>> And both of these versions are not working in the same way.
>>
>
> Sorry I missed the -ssl3 command option in your other messages. The GOST
> ciphersuites don't work with SSLv3 but OpenSSL shouldn't be giving that error
> message: it should just disable GOST ciphersuites if SSLv3 is negotiated.
>
> Steve.

Thanks for information!

When I specify -tls1 option both to s_server and s_client, everything
become work fine, even with 1.0.0a.


But, dear Guru, would you like be so kind to enlighten us, ignorami,
why GOST ciphersuites don't work with SSLv3?
Is it a OpenSSL feature, or it's according to some standard? Or there
is any other reasons?

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

Re: 1.0.0a s_server with GOST certificate can't compute sha1 digest???

[Andrey Kulikov]

Hello,

On 13 November 2010 03:33, Dr. Stephen Henson  wrote:
>
> I've just tried 1.0.1 and it does have a problem with GOST and TLS v1.1 which
> is the default for OpenSSL 1.0.1. If you include -no_tls1_1 in the command
> line it should work or if you try a recent 1.0.0 snapshot (OpenSSL 1.0.0
> doesn't support TLS v1.1).
>
> I'll look into the TLS v1.1 issue.
>
> Steve.


Sorry to confuse you - I've mixed up versions and snapshot filenames.
I just re-check these snapshots of 1.0.0
ftp://ftp.openssl.org/snapshot/openssl-1.0.0-stable-SNAP-20101112.tar.gz
and 1.0.1
ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20101112.tar.gz

I disable TSL in there:
./config no-tls

I add "-ssl3" parameter to s_server and s_client commands.

./apps/openssl s_server -ssl3  -www -engine gost -accept 4333  -state
-cert botcert.pem -key botkey.p8
./apps/openssl s_client -ssl3 -engine gost  -connect localhost:4333

And both of these versions are not working in the same way.

s_server
=
SSL3 alert write:fatal:bad record mac
SSL_accept:error in SSLv3 read certificate verify A
3076736652:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:668:
=

s_client
=
verify return:1
3076413068:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:668:
=

So, the problem not in TLS1.1

BTW: 1.0.1 s_server doesn't accept -no_tls1_1 option, while have it in
help option list.
s_client does accept this option.


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

Re: 1.0.0a s_server with GOST certificate can't compute sha1 digest???

[Andrey Kulikov]

Sorry, previous email is about 1.0.1 latest snapshot.

I just checked with 1.0.1
ftp://ftp.openssl.org/snapshot/openssl-1.0.0-stable-SNAP-20101112.tar.gz

Results exactly the same.
If you'll need any details - please let me know.

Andrey

On 13 November 2010 00:43, Andrey Kulikov  wrote:
> On 12 November 2010 15:20, Dr. Stephen Henson  wrote:
>> On Fri, Nov 12, 2010, Andrey Kulikov wrote:
>>
>>> Hello,
>>>
>>> I'm trying to make s_server and s_client work with GOST encryption
>>> using ccgost engine and certificates with GOST algos.
>>> But it unable to work, complaining to bad mac computing.
>>> (If I use RSA-based certificates, everything works just fine.)
>>>
>>
>> Please try a recent 1.0.0 snapshot and see if you still have this problem.
>>
>> Steve.
>
> I check with
> ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20101112.tar.gz
>
> Visible behaviour is the same.
> Commands output is the same.
>
> Test procedure the same as described in original message:
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: 1.0.0a s_server with GOST certificate can't compute sha1 digest???

[Andrey Kulikov]

On 12 November 2010 15:20, Dr. Stephen Henson  wrote:
> On Fri, Nov 12, 2010, Andrey Kulikov wrote:
>
>> Hello,
>>
>> I'm trying to make s_server and s_client work with GOST encryption
>> using ccgost engine and certificates with GOST algos.
>> But it unable to work, complaining to bad mac computing.
>> (If I use RSA-based certificates, everything works just fine.)
>>
>
> Please try a recent 1.0.0 snapshot and see if you still have this problem.
>
> Steve.

I check with
ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20101112.tar.gz

Visible behaviour is the same.
Commands output is the same.

Test procedure the same as described in original message:
Modify openssl.cnf

export OPENSSL_CONF=/openssl.cnf

./apps/openssl genpkey -engine gost -algorithm gost2001 -pkeyopt
paramset:A -out botkey.p8

./apps/openssl req -config ./apps/openssl.cnf -x509 -days 1095 -subj
'/C=RU/CN=csp_srv/o=lapu...@mail.ru' -engine gost -new -key botkey.p8
-out botcert.pem


./apps/openssl s_server -www -engine gost -accept 4333  -state -cert
botcert.pem -key botkey.p8

./apps/openssl s_client -engine gost -ssl3  -connect localhost:4333


s_client output (truncated):
==
~/comt_area/openssl-1.0.1-stable-SNAP-20101112# ./apps/openssl
s_client -engine gost -ssl3  -connect localhost:4333
engine "gost" set.
CONNECTED(0003)
depth=0 C = RU, CN = csp_srv, O = lapu...@mail.ru
verify error:num=18:self signed certificate
verify return:1
depth=0 C = RU, CN = csp_srv, O = lapu...@mail.ru
verify return:1
3076486796:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:668:
3076486796:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:668:
3076486796:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
record mac:s3_pkt.c:1212:SSL alert number 20
3076486796:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:591:
---
Certificate chain
 0 s:/C=RU/CN=csp_srv/o=lapu...@mail.ru
   i:/C=RU/CN=csp_srv/o=lapu...@mail.ru
---
==

s_server output (truncated)
==
:~/comt_area/openssl-1.0.1-stable-SNAP-20101112#  ./apps/openssl
s_server -www -engine gost -accept 4333  -state -cert botcert.pem -key
botkey.p8
engine "gost" set.
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL3 alert write:fatal:bad record mac
SSL_accept:error in SSLv3 read certificate verify A
SSL_accept:error in SSLv3 read certificate verify A
3076945548:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:668:
3076945548:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:668:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:8808C074:lib(136):GOST_IMIT_FINAL:mac key not
set:gost_crypt.c:564:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076945548:error:8808C074:lib(136):GOST_IMIT_FINAL:mac key not
set:gost_crypt.c:564:
3076945548:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac:s3_pkt.c:479:

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

Re: Is it really possible to generate gost-mac using ccgost engine?

[Andrey Kulikov]

On 12 November 2010 19:26, Valery Blazhnov  wrote:
>  This command works with ccgost engine:
> openssl dgst -mac gost-mac -binary -macopt
> hexkey:3132333435363738393031323334353637383930313233343536373839303132 -out
> mac.bin data.bin
>

What openssl version do you use?
I use 1.0.0a, and this command output is just "Algorithm gost-mac not found".

But this command works:

openssl dgst -engine gost -mac gost-mac -macopt
key: openssl.doxy
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Source level debug config for 1.0.0a?

[Andrey Kulikov]

As a quick hack I added to root Makefile following lines:

==
debug: CFLAG+= -ggdb3 -O0 -DDEBUG
debug: all

==
just before

all: Makefile build_all openssl.pc libssl.pc libcrypto.pc


Then
# make clean
# make debug

After that NetBeans can walk through source using gdb.

Linux i368.

It consumes about 3G of disk space.
And it's a good idea to exclude "test" from
DIRS=   crypto ssl engines apps test tools
in Makefile if you do not need them, as it's require enormous time to build.


Scott Cherf
Fri, 15 Oct 2010 15:22:45 -0700

Hello -

I'm trying to compile with source level debugging enabled using the 1.0.0a
distribution and I'm not having any luck at all.  I would appreciate a clue if
there is one.
...
I'm unable to build a version that gives me source level debug
using gdb and I can't figure out why. Anyone?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Is it really possible to generate gost-mac using ccgost engine?

[Andrey Kulikov]

Hello,

I've got a problem with calculating gost-mac using Openssl 1.0.0a
May be problem with cmd options, but I was unable to find out how to get it work

Trying to generate gost-mac.
Example from documentation (engines/ccgost/README.gost)

 Calculation of GOST 28147 MAC

 openssl dgst -mac gost-mac -macopt key:<32 bytes of key> datafile

 Note absense of an option that specifies digest algorithm. gost-mac
 algorithm supports only one digest (which is actually part of
 implementation of this mac) and OpenSSL is clever enough to find out
 this.


# ./apps/openssl dgst -mac gost-mac -macopt key:FF openssl.doxy
Algorithm gost-mac not found

Well, do it like this:
# ./apps/openssl dgst  -gost-mac -macopt key:ff openssl.doxy
Read Error in openssl.doxy
3076327052:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:

The reason is that key for this mac is not set.
The only place where it can be set is control function "gost_imit_ctrl"

engines/ccgost/gost_crypt.c:595

But this function "int gost_imit_ctrl(EVP_MD_CTX, int, int, void *)"
never called.
So length of "key" option is not a root cause.

As I understand, control functions for "dgst" called only if parameter
-mac is specified.
See apps/dgst.c:228   else if (!strcmp(*argv,"-mac"))
and
apps/dgst.c:362 if (mac_name)
But since there is no such parameter it not supposed to work.
But if we do specify it - openssl can't find an algorithms (see first
command line example).

So the question is: is it a bug or it is possible to specify some
valid parameter for -mac option in this case?
Or may be there is other way to get it work?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

1.0.0a s_server with GOST certificate can't compute sha1 digest???

[Andrey Kulikov]

Hello,

I'm trying to make s_server and s_client work with GOST encryption
using ccgost engine and certificates with GOST algos.
But it unable to work, complaining to bad mac computing.
(If I use RSA-based certificates, everything works just fine.)

Openssl 1.0.0a, Linux i386

I have ccgost statically linked in openssl.
I've add following lines to openssl config file:
=
openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
=

Then execute
export OPENSSL_CONF=/openssl.cnf

Generate key and self-signed certificate using GOST algos.

#Generate private key
./apps/openssl genpkey -engine gost -algorithm gost2001 -pkeyopt
paramset:A -out botkey.p8
# Create self-sign certificate
./apps/openssl req -config ./apps/openssl.cnf -x509 -days 1095 -subj
'/C=RU/CN=csp_srv/o=lapu...@mail.ru' -engine gost -new -key botkey.p8
-out botcert.pem

# Dump ASN format files to check that it what we expect
openssl asn1parse -in botkey.p8
openssl asn1parse -in botcert.pem


When start s_server

 ./apps/openssl s_server -www -engine gost -accept 4333  -state -cert
botcert.pem -key botkey.p8

./apps/openssl s_client -engine gost -ssl3  -connect localhost:4333

Client output (truncated):

.
3076867724:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:669:
3076867724:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:669:
3076867724:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad
record mac:s3_pkt.c:1193:SSL alert number 20
3076867724:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:590:
---
..
---
New, TLSv1/SSLv3, Cipher is GOST2001-GOST89-GOST89
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : SSLv3
Cipher: GOST2001-GOST89-GOST89
Session-ID: 214A3B31604763646B6E6A1DC0B793BC5979C454C25AE2ED2EE3947AA08078B0
Session-ID-ctx:
Master-Key:
93B1DB1A2B5A40CFB2E3328280FB200B044CF446E73353B735328253D690F88A01AEB9E004BC06085E4C81770269EBD7
Key-Arg   : None
PSK identity: None
PSK identity hint: None
Start Time: 1289516998
Timeout   : 7200 (sec)
Verify return code: 18 (self signed certificate)


Server output (truncated):

...
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL3 alert write:fatal:bad record mac
SSL_accept:error in SSLv3 read certificate verify A
SSL_accept:error in SSLv3 read certificate verify A
3076998796:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:669:
3076998796:error:1411D144:SSL routines:ssl3_handshake_mac:digest
requred for handshake isn't computed:s3_enc.c:669:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:8808C074:lib(136):GOST_IMIT_FINAL:mac key not
set:gost_crypt.c:564:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:
3076998796:error:8808C074:lib(136):GOST_IMIT_FINAL:mac key not
set:gost_crypt.c:564:
3076998796:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac:s3_pkt.c:478:
ACCEPT



The problem is in ssl3_final_finish_mac function (ssl/s3_enc.c:636),
called somewhere from ssl3_do_change_cipher_spec().
It try to compute  NID_md5 and NID_sha1 digests, but in
SSL->s3->handshake_dgst[] there is only one digest -
NID_id_GostR3411_94. So we got that errors.


Could please someone advice, what the root cause of this situation,
and how to deal with it?
How to get s_server and s_client working with GOST certificates?

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

Re: Source level debug config for 1.0.0a?

[Andrey Kulikov]

Thanks for pointing to this feature!

In context of original question

./Configure debug-rse

looks better than others, as it add "-ggdb3" switch, while just "-g"
(like in all others debugging targets) was not work well (for me).

On 10 November 2010 16:33, Martin Kaiser  wrote:
> Hello,
> there's a number of debugging targets in Configure. For OpenSSL-1.0.0a
> on Linux i386, you can simply do
>
> ./Configure debug-linux-elf-noefence
> make clean
> make
>
> and you have debug infos enabled
>   Martin
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Source level debug config for 1.0.0a?

[Andrey Kulikov]

As a quick hack I added to root Makefile following lines:

==
debug: CFLAG+= -ggdb3 -O0 -DDEBUG
debug: all

==
just before

all: Makefile build_all openssl.pc libssl.pc libcrypto.pc


Then
# make clean
# make debug

After that NetBeans can walk through source using gdb.

Linux i368.

It consumes about 3G of disk space.
And it's a good idea to exclude "test" from
DIRS=   crypto ssl engines apps test tools
in Makefile if you do not need them, as it's require enormous time to build.


Scott Cherf
Fri, 15 Oct 2010 15:22:45 -0700

Hello -

I'm trying to compile with source level debugging enabled using the 1.0.0a
distribution and I'm not having any luck at all.  I would appreciate a clue if
there is one.
...
I'm unable to build a version that gives me source level debug
using gdb and I can't figure out why. Anyone?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

How to generate gost-mac using ccgost engine?

[Andrey Kulikov]

Hello,

I've got a problem with calculating gost-mac using Openssl 1.0.0a
May be problem with cmd options, but I was unable to find out how to get it work

Trying to generate gost-mac.
Example from documentation (engines/ccgost/README.gost)

 Calculation of GOST 28147 MAC

 openssl dgst -mac gost-mac -macopt key:<32 bytes of key> datafile

 Note absense of an option that specifies digest algorithm. gost-mac
 algorithm supports only one digest (which is actually part of
 implementation of this mac) and OpenSSL is clever enough to find out
 this.


# ./apps/openssl dgst -mac gost-mac -macopt key:FF openssl.doxy
Algorithm gost-mac not found

Well, do it like this:
# ./apps/openssl dgst  -gost-mac -macopt key:ff openssl.doxy
Read Error in openssl.doxy
3076327052:error:88073074:lib(136):GOST_IMIT_UPDATE:mac key not
set:gost_crypt.c:527:

The reason is that key for this mac is not set.
The only place where it can be set is control function "gost_imit_ctrl"

engines/ccgost/gost_crypt.c:595

But this function "int gost_imit_ctrl(EVP_MD_CTX, int, int, void *)"
never called.
So length of "key" option is not a root cause.

As I understand, control functions for "dgst" called only if parameter
-mac is specified.
See apps/dgst.c:228   else if (!strcmp(*argv,"-mac"))
and
apps/dgst.c:362         if (mac_name)
But since there is no such parameter it not supposed to work.
But if we do specify it - openssl can't find an algorithms (see first
command line example).

So the question is: is it a bug or it is possible to specify some
valid parameter for -mac option in this case?
Or may be there is other way to get it work?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org