Henrik Grindal Bakken | 1 Nov 08:55 2011
Picon
Picon

Re: FIPS tests not being built

"Dr. Stephen Henson" <steve <at> openssl.org> writes:

> This is a deliberate change to separate the module building from the test
> utility building. Now you need an explicit command:
>
> make build_tests
>
> The README.FIPS file was updated to mention this.

It would be handy to have an 'install_tests' make target as well.
Something like the attached patch.

Also, do all the tests have to be that big?  (We need to run them on
target, with limited space available.)

Attachment (installfips.patch): text/x-patch, 656 bytes

--

-- 
Henrik Grindal Bakken <hgb <at> ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52
Emmanuel Azencot via RT | 2 Nov 11:55 2011
Picon

Re: [openssl.org #2632] Resolved: ec_GF2m_simple_is_on_curve may BN_CTX_end without start if not Z_is_one ec_GF2m_simple_is_on_curve may BN_CTX_end without start if not Z_is_one ec_GF2m_simple_is_on_curve may BN_CTX_end without start

Thank's to you and to all openssl team.

best regards
Emmanuel

-----"Stephen Henson via RT" <rt <at> openssl.org> a écrit : -----
A : emmanuel.azencot <at> bull.net
De : "Stephen Henson via RT" <rt <at> openssl.org>
Date : 27/10/2011 17:37
Objet : [openssl.org #2632] Resolved: ec_GF2m_simple_is_on_curve may BN_CTX_end without start if not
Z_is_one ec_GF2m_simple_is_on_curve may BN_CTX_end without start if not Z_is_one
ec_GF2m_simple_is_on_curve may BN_CTX_end without start

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.

Thank's to you and to all openssl team.

best regards
Emmanuel

-----"Stephen Henson via RT" <rt <at> openssl.org> a ?crit : -----
A : emmanuel.azencot <at> bull.net
De : "Stephen Henson via RT" <rt <at> openssl.org>
Date : 27/10/2011 17:37
Objet : [openssl.org #2632] Resolved: ec_GF2m_simple_is_on_curve may BN_CTX_end without start if not Z_is_one ec_GF2m_simple_is_on_curve may BN_CTX_end without start if not Z_is_one ec_GF2m_simple_is_on_curve may BN_CTX_end without start

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
Charles Bryant via RT | 2 Nov 17:47 2011
Picon

[openssl.org #2636] bug in ppc asm version of bn_mul_comba4

The ppc version of bn_mul_comba4 produces an incorrect result because
one of the products added into r[5] is wrong. Instead of adding a[3]*b[2],
a[3]*a[2] is added because r4 is used instead of r5:

diff -N -ru bad/crypto/bn/asm/ppc.pl good/crypto/bn/asm/ppc.pl
--- bad/crypto/bn/asm/ppc.pl 2008-09-12 15:45:53.000000000 +0100
+++ good/crypto/bn/asm/ppc.pl   2011-10-28 12:57:59.000000000 +0100
 <at>  <at>  -949,7 +949,7  <at>  <at> 
        addze   r11,r0
                                        #mul_add_c(a[3],b[2],c3,c1,c2);
        $LD     r6,`3*$BNSZ`(r4)
-       $LD     r7,`2*$BNSZ`(r4)
+       $LD     r7,`2*$BNSZ`(r5)
        $UMULL  r8,r6,r7
        $UMULH  r9,r6,r7
        addc    r12,r8,r12

--

-- 
Charles Bryant - ch <at> chch.demon.co.uk

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Tayade, Nilesh | 2 Nov 19:26 2011

About openssl versions mismatch - aes256 decryption.

Hi,

I am testing a dummy code for AES256_SHA decryption. Please see the
attached server private key and the C code.
The same code works for "OpenSSL 0.9.8r" and "OpenSSL 0.9.8k".
But it produces junk after decryption on machine with OpenSSL version
"OpenSSL 1.0.0b".

Could someone please comment why this happens? Shouldn't the recent
version be compatible with older ones?

P.S. : I re-sent the email, as I saw failure while forwarding message.

--
Thanks,
Nilesh
Attachment (server.key): application/octet-stream, 1232 bytes
Attachment (aes_cav_dec.c): application/octet-stream, 13 KiB
Robert Dugal | 3 Nov 13:41 2011

ENGINE_set_default() and ciphers/digests

I have an ENGINE that implements many of the same algorithms that OpenSSL 
already supports. It supports asymmetric key algorithms like RSA, DSA, ECDSA. 
It supports symmetric key algorithms like AES, DES, RC2, RC4. It supports 
digest algorithms like MD5, SHA1, SHA256, etc.

If I register my engine with ENGINE_add() but do not use ENGINE_set_default() 
then I had expected that the OpenSSL builtin implementations would be used and 
not my engine implementations. This appears to be the case for the asymmetric 
key algorithms. However, the digests and symmetric key algorithms of my engine 
are always being used even though they are not enabled as default. As soon as I 
register my engine with ENGINE_add() then my digests and symmetric key 
algorithms become the default. This seems very odd to me. I would have expected 
that my digests and symmetric key algorithms would only be enabled as default 
by using ENGINE_set_default() with ENGINE_METHOD_CIPHERS|ENGINE_METHOD_DIGESTS.

Is what I am observing the correct behavior of OpenSSL?

FYI: I have been testing with OpenSSL 1.0.0d & 1.0.0e

--

-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
		      4701 Tahoe Blvd., Building A
		      Mississauga, ON
		      L4W 0B5

rdugal <at> certicom.com
direct       	+1.289.261.4148
mobile      	+1.416.276.8062
main         	+1.905.507.4220
(Continue reading)

Steve Marquess | 3 Nov 14:44 2011

OpenSSL FIPS Module 2.0 status update

The FIPS 140-2 validation effort for the OpenSSL FIPS Object Module 2.0
has reached an important milestone.  We have declared "code freeze", a
little later than originally planned, and have submitted formal software
distributions to the accredited testing laboratory.

Those distributions can be found at

    http://opensslfoundation.com/testing/validation-2.0/source/

There are two separate versions because some sponsors have requested
testing with a module that contains only prime curve EC.  The "1.9"
notation accommodates a test lab versioning scheme.  Please note
that these source code distributions *cannot* be used to generate
validated modules for two reasons.  First, nothing has been validated
yet, and secondly the distributions still deliberately identify the contents
as suitable for testing purposes only.  After the test lab has finished its
review we will with their oversight and approval generate new final
distributions of production code.

Also note that we have already been requested to make some changes to
the test suite utilities used by the test lab for their test and review
activities.  Those interested parties wishing to examine the software as
it is being tested are encouraged to reference the
OpenSSL-fips-2_0-stable branch in the OpenSSL CVS repository.

-Steve M.

--

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
(Continue reading)

Mark.Trinh | 2 Nov 22:13 2011

64 bit OpenSSL FIPS 1.2.3 with asm slow performance problems on AES

I’ve been having consistent performance problems with the 64 bit openssl FIPS 1.2.3 with asm on AES.  The assembly code on 64 bit architectures is much slower than without assembly.  Running the same tests on a 32 bit machine results with ASM being faster than no-asm, which is expected.

 

Does anyone have any ideas on why the 64 bit fips with asm is slower for AES encryption?

 

machine:  OpenSUSE 11.4, using gcc 4.1.2

 

With ASM:

./Configure fipscanisterbuild linux-x86_64 no-shared

./openssl64-asm speed aes

Doing aes-128 cbc for 3s on 16 size blocks: 12313812 aes-128 cbc's in 2.99s

Doing aes-128 cbc for 3s on 64 size blocks: 3315028 aes-128 cbc's in 2.99s

Doing aes-128 cbc for 3s on 256 size blocks: 847171 aes-128 cbc's in 3.00s

Doing aes-128 cbc for 3s on 1024 size blocks: 213565 aes-128 cbc's in 2.99s

Doing aes-128 cbc for 3s on 8192 size blocks: 26741 aes-128 cbc's in 2.99s

Doing aes-192 cbc for 3s on 16 size blocks: 10425560 aes-192 cbc's in 2.99s

Doing aes-192 cbc for 3s on 64 size blocks: 2783434 aes-192 cbc's in 3.00s

Doing aes-192 cbc for 3s on 256 size blocks: 703868 aes-192 cbc's in 2.99s

Doing aes-192 cbc for 3s on 1024 size blocks: 177705 aes-192 cbc's in 2.99s

Doing aes-192 cbc for 3s on 8192 size blocks: 22269 aes-192 cbc's in 3.00s

Doing aes-256 cbc for 3s on 16 size blocks: 9044428 aes-256 cbc's in 2.99s

Doing aes-256 cbc for 3s on 64 size blocks: 2400974 aes-256 cbc's in 2.99s

Doing aes-256 cbc for 3s on 256 size blocks: 609267 aes-256 cbc's in 3.00s

Doing aes-256 cbc for 3s on 1024 size blocks: 152920 aes-256 cbc's in 2.99s

Doing aes-256 cbc for 3s on 8192 size blocks: 19111 aes-256 cbc's in 2.99s

OpenSSL FIPS Object Module v1.2

built on: Wed Nov  2 13:54:41 PDT 2011

options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(ptr2)

compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM

available timing options: TIMES TIMEB HZ=100 [sysconf value]

timing function used: times

The 'numbers' are in 1000s of bytes per second processed.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes

aes-128 cbc      65893.31k    70957.12k    72291.93k    73140.66k    73264.97k

aes-192 cbc      55788.95k    59379.93k    60264.28k    60859.51k    60809.22k

aes-256 cbc      48398.28k    51392.09k    51990.78k    52371.26k    52360.31k

 

Without ASM:

./Configure fipscanisterbuild linux-x86_64 no-shared no-asm

./openssl64-no-asm speed aes

Doing aes-128 cbc for 3s on 16 size blocks: 23150575 aes-128 cbc's in 2.99s

Doing aes-128 cbc for 3s on 64 size blocks: 5947419 aes-128 cbc's in 2.99s

Doing aes-128 cbc for 3s on 256 size blocks: 1515978 aes-128 cbc's in 2.99s

Doing aes-128 cbc for 3s on 1024 size blocks: 379077 aes-128 cbc's in 3.00s

Doing aes-128 cbc for 3s on 8192 size blocks: 47520 aes-128 cbc's in 2.99s

Doing aes-192 cbc for 3s on 16 size blocks: 20160858 aes-192 cbc's in 3.00s

Doing aes-192 cbc for 3s on 64 size blocks: 5197254 aes-192 cbc's in 2.99s

Doing aes-192 cbc for 3s on 256 size blocks: 1325367 aes-192 cbc's in 2.99s

Doing aes-192 cbc for 3s on 1024 size blocks: 331725 aes-192 cbc's in 2.99s

Doing aes-192 cbc for 3s on 8192 size blocks: 41579 aes-192 cbc's in 3.00s

Doing aes-256 cbc for 3s on 16 size blocks: 18043804 aes-256 cbc's in 2.99s

Doing aes-256 cbc for 3s on 64 size blocks: 4656304 aes-256 cbc's in 3.00s

Doing aes-256 cbc for 3s on 256 size blocks: 1171525 aes-256 cbc's in 2.99s

Doing aes-256 cbc for 3s on 1024 size blocks: 292807 aes-256 cbc's in 2.99s

Doing aes-256 cbc for 3s on 8192 size blocks: 36675 aes-256 cbc's in 3.00s

OpenSSL FIPS Object Module v1.2

built on: Wed Nov  2 13:58:02 PDT 2011

options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(ptr2)

compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64  -DTERMIO -O3 -Wall -DMD32_REG_T=int

available timing options: TIMES TIMEB HZ=100 [sysconf value]

timing function used: times

The 'numbers' are in 1000s of bytes per second processed.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes

aes-128 cbc     123882.68k   127302.61k   129796.11k   129391.62k   130195.26k

aes-192 cbc     107524.58k   111245.57k   113476.24k   113607.49k   113538.39k

aes-256 cbc      96555.47k    99334.49k   100304.48k   100279.05k   100147.20k

 

Thanks,

Mark

Tomas Mraz via RT | 3 Nov 15:33 2011
Picon

[openssl.org #2637] Missing documentation for -no_ign_eof option

The attached patch adds missing documentation for the -no_ign_eof
option.
--

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

Olivier Mehani via RT | 4 Nov 10:46 2011
Picon

[openssl.org #2638] s_client -servername BLAH not honoured with -starttls xmpp

Hi,

Problem
=======

I'm trying to obtain the certificate of an XMPP server using
  openssl s_client -connect server.domain.tld:5222 -starttls xmpp

However, the name of the server within the XMPP realm is only domain.tld
rather than server.domain.tld. The above command tries to start the TLS
connection as follows.
  <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'
to='server.domain.tld' version='1.0'>
But gets rejected with the following message.
  <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'
id='3729850247' from='domain.tld' xml:lang='en'>
    <stream:error>
      <host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
    </stream:error>
Note that the message is sent to server.domain.tld, but the error comes
from domain.tld.

The solution to this problem seems to be the -servername option to
s_client:
  openssl s_client  -connect server.domain.tld:5222 -starttls xmpp -servername domain.tld
This however doesn't make any difference, and the stream is started by
OpenSSL the same as before:
  <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client'
to='server.domain.tld' version='1.0'>

Cause
=====

Looking in apps/s_client.c (line 1181 for openssl-1.0.0e), there is
        if (starttls_proto == PROTO_XMPP)
                {
                int seen = 0;
                BIO_printf(sbio,"<stream:stream "
                    "xmlns:stream='http://etherx.jabber.org/streams' "
                    "xmlns='jabber:client' to='%s' version='1.0'>", host);

[Note: I believe this should be an else if rather than an if statement
(or maybe the whole conditionnal should be replaced by a switch
statement), though I don't think it would change anything to the
behaviour of the program either way.]

The string which is sent to the XMPP server uses host, which contains the
argument to -connect (from line 494), rather than that to -servername (the
aptly named servername variable, line 712).

Proposed Solution
=================

On line 429, servername is initialised to NULL. The problem could then
be solved quickly, but perhaps not very elegantly, by changing the
BIO_printf() above with
                BIO_printf(sbio,"<stream:stream "
                    "xmlns:stream='http://etherx.jabber.org/streams' "
                    "xmlns='jabber:client' to='%s' version='1.0'>", servername?servername:host);
(note the servername?servername:host towards the very end). See attached patch.

Variable servername is defined within an OPENSSL_NO_TLSEXT conditionnal block,
but, logically, so is the full starttls logic, so it shouldn't be a problem.

I have compiled and tested a version patched with this proposal. It works as I
would expect (i.e., it solves the very problem described above). This is such a
trivial change that I don't believe it introduces anything unintended).

Hope this helps.

-- 
Olivier Mehani <shtrom <at> ssji.net>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655

Index: openssl-1.0.0e/apps/s_client.c
===================================================================
--- openssl-1.0.0e.orig/apps/s_client.c
+++ openssl-1.0.0e/apps/s_client.c
 <at>  <at>  -1183,7 +1183,7  <at>  <at>  SSL_set_tlsext_status_ids(con, ids);
 		int seen = 0;
 		BIO_printf(sbio,"<stream:stream "
 		    "xmlns:stream='http://etherx.jabber.org/streams' "
-		    "xmlns='jabber:client' to='%s' version='1.0'>", host);
+		    "xmlns='jabber:client' to='%s' version='1.0'>", servername?servername:host);
 		seen = BIO_read(sbio,mbuf,BUFSIZZ);
 		mbuf[seen] = 0;
 		while (!strstr(mbuf, "<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'"))
Jan Steemann | 4 Nov 14:13 2011

Disabling client side renegotiaton?

Hi,

a few weeks ago, some vulnerability concerning SSL renegotiation was disclosed:
http://www.thc.org/thc-ssl-dos
http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html
http://blog.ivanristic.com/2011/10/tls-renegotiation-and-denial-of-service-attacks.html

I use a web server whose SSL implementation is based on openssl. The web server was checked and found to be
affected by the issue.
I checked the openssl source code for an option to disable client-side renegotiation but I could not find one.

I patched ssl/t1_lib.c in the openssl source and removed the client-renegotiation code in the
*clienthello_tlsext* functions.
That seems to have fixed the issue, at least the SSL security check tools did not report the vulnerability
after that.

However, I think simply removing client-side renegotiation code is not a good idea. Furthermore, it might
have broken something else.

While researching the issue I read MS IIS does not allow client-side renegotiation at all and Apache
doesn't any more. Therefore it should be ok to turn it off at least in some environments. As far as I can see
openssl users currently have no choice to turn it on or off because it's always activated.   

>From my point of view, it should be made configurable, ideally by using SSL_CTX_set_options() and friends.

Does anyone know if this is planned for a future release and does anyone consider this to be a sensible solution?

Thank you and best regards
Jan
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org


Gmane