Re: [openssl-dev] [openssl.org #4548] s390x build problem

[Sebastian Andrzej Siewior via RT]

On 2016-06-02 13:29:35 [+], Andy Polyakov via RT wrote:
> Thanks!!! There is couple of problems with suggested modifications
> though. First general comment. While 31-bit is arguably not very
> fashionable, bugs are still reported at occasions. Important to keep in
> mind that 31-bit build still requires z/Arch processor *and* highgprs
> kernel feature, i.e. target is not s390 systems (note lack of x), but
> 64-bit processor running 64-bit OS, just running legacy *process*. Goal
> also is to minimize deviations and "parametrize", so that most of the
> code is constantly "exposed" to assembler. That's what are those ${g}
> things are and that's why #if clauses are limited to clearing most
> significant 32 bits of registers. This means that suggestion to
> introduce big #if in CRYPTO_memcmp is not considered favourable.
> Adhering to non-extension instructions is. Another problem is with
> suggested ltgr in chacha-s390x. It has to be "parametrized", i.e. look
> as lt${g}r. Because in 31-bit build there is no guarantee that most
> significant 32-bit of $len register are actually zero-ed. In other words
> could you double-check attached patch instead?

Thanks. Just tested and it compiles and the testsuite passes.

Sebastian


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

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

Re: [openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

[Sebastian Andrzej Siewior via RT]

On 2016-05-30 21:28:06 [+], Andy Polyakov via RT wrote:
> For what it's worth I can't reproduce problem on Fedora or RedHat.

The test
|…
|# The following symbols are missing in libcrypto.so:
|#   _shadow_DES_check_key
|not ok 2 - check that there are no missing symbols in libcrypto.so
|…

So it is about DES_check_key which is the only variable using
OPENSSL_IMPLEMENT_GLOBAL (and I don't see it beeing used).

On x86-64 :
| $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key
| _shadow_DES_check_key B  0004

and on powerpc I get:
| $ nm -Pg crypto/des/set_key.o|grep _shadow_DES_check_key
| _shadow_DES_check_key S  0004

and this fixes it:

--- a/test/recipes/01-test_symbol_presence.t
+++ b/test/recipes/01-test_symbol_presence.t
@@ -57,7 +57,7 @@ foreach my $libname (@libnames) {
 note "Number of lines in \@def_lines before massaging: ", scalar 
@def_lines;
 
 # Massage the nm output to only contain defined symbols
-@nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDT] .*|, @nm_lines);
+@nm_lines = sort map { s| .*||; $_ } grep(m|.* [BCDST] .*|, @nm_lines);
 
 # Massage the mkdef.pl output to only contain global symbols
 # The output we got is in Unix .map format, which has a global

I make a proper pull req later…

Sebastian


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

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

Re: [openssl-dev] [openssl.org #4548] s390x build problem

[Sebastian Andrzej Siewior via RT]

On 2016-05-30 20:23:35 [+], Andy Polyakov via RT wrote:
> > I'm getting:
> > crypto/chacha/chacha-s390x.S: Assembler messages:
> > crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
> > 
> > 
> > A full build log is available on:
> > https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754
> 
> It's overly easy to get carried away if you have access to single
> system. Double-check attached.

I made this while I did not notice this earlier:
  https://github.com/openssl/openssl/pull/1146

It fixes the chacha thing + memcpy.

Sebastian


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

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

[openssl-dev] [openssl.org #4496] [PATCH] ssl_cert: use the recommended minimum hash from RFC 5480 for EC

[Sebastian Andrzej Siewior via RT]

A TLS1.2 connetion with openssl server and gnutls-cli using a SECP384R1
key ends up with SHA256 as the hash algorithm for signing the key exchange.
This is because gnutls sends the hash algorithms from weak to strong
and by default client's preference is used.

gnutls complains about this situation:
|<1>| The hash size used in signature (32) is less than the expected (48)

The complaint is based on the recommendation in RFC 5480, section 4.
Security Considerations. There two ways to fix it:
- Using
  -sigalgs "ECDSA+SHA384:ECDSA+SHA512:ECDSA+SHA256:ECDSA+SHA224:ECDSA+SHA1"
  -serverpref
 The weaker algorithms

- The following patch which eliminates SHA256+SHA224 from the list of
  possible candidates. SHA1 is still available if left out in -sigalgs
  and nothing else matches.

Signed-off-by: Sebastian Andrzej Siewior 
---
 ssl/ssl_cert.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c
index 4081ebe4ffbd..7d00ad3182f5 100644
--- a/ssl/ssl_cert.c
+++ b/ssl/ssl_cert.c
@@ -1135,6 +1135,25 @@ static int ssl_security_default_callback(const SSL *s, 
const SSL_CTX *ctx, int o
 if (level >= 3)
 return 0;
 break;
+#ifndef OPENSSL_NO_EC
+case SSL_SECOP_SIGALG_SHARED:
+   if (s && s->cert && s->cert->key && s->cert->key->privatekey) {
+   EVP_PKEY *skey = s->cert->key->privatekey;
+
+   /*
+* RFC 5480 Section 4, Security Considerations.
+* For a curve with keysize of 384 bits (secp384r1) we
+* allow SHA-384 and higher
+*/
+   if (EVP_PKEY_id(skey) == EVP_PKEY_EC) {
+   if (EVP_PKEY_bits(skey) > (bits * 2))
+   return 0;
+   }
+   }
+   if (bits < minbits)
+   return 0;
+   break;
+#endif
 default:
 if (bits < minbits)
 return 0;
-- 
2.8.0.rc3


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

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

[openssl.org #2787] [PATCH] enc: compress before compress/base64 is applied

[Sebastian Andrzej Siewior via RT]

The command
|openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -base64  file  
file.enc.b64

first performs the encryption followed by base64 encoding. That means the output
is base64 encoded as requests.

The command
|openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -z  file  file.enc.z

first performs the encryption followed by compression. That means the encrypted
data is compressed which should not give any improvement because a good
encryption algorithm should not produce anything that can be compressed.

The command
| openssl enc -pass pass:pass -iv 0 -K 0 -S 0 -aes-256-cbc -z -base64  file   
file.enc.z.base64

first performs the encryption, followed by base64 encoding followed by
compression. The output is no longer base64 encoded as requests but compressed
by zlib.

This patch changes the order of the individual steps to
- compress the input
- encrypt the content
- encode is as base64

the -d step is in reverse order.
That means the last command will produce a base64 encoded file which was
compressed before encrypted.

The *now* created files are no longer compatible with the files created with
an earlier version of openssl if the -z option was involved.

To get the old content with new binary the following step is required:
|   openssl enc -d -z  file.old | \
|   openssl enc -d -aes-256-cbc  file

where the first step simply decompresses the content and the second performs the
decryption.

Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
 apps/enc.c |   32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/apps/enc.c b/apps/enc.c
index 719acc3..a6fd07e 100644
--- a/apps/enc.c
+++ b/apps/enc.c
@@ -475,19 +475,6 @@ bad:
rbio=in;
wbio=out;
 
-#ifdef ZLIB
-
-   if (do_zlib)
-   {
-   if ((bzl=BIO_new(BIO_f_zlib())) == NULL)
-   goto end;
-   if (enc)
-   wbio=BIO_push(bzl,wbio);
-   else
-   rbio=BIO_push(bzl,rbio);
-   }
-#endif
-
if (base64)
{
if ((b64=BIO_new(BIO_f_base64())) == NULL)
@@ -653,9 +640,24 @@ bad:
}
}
 
-   /* Only encrypt/decrypt as we write the file */
if (benc != NULL)
-   wbio=BIO_push(benc,wbio);
+   {
+   if (!enc)
+   rbio=BIO_push(benc,rbio);
+   else
+   wbio=BIO_push(benc,wbio);
+   }
+#ifdef ZLIB
+   if (do_zlib)
+   {
+   if ((bzl=BIO_new(BIO_f_zlib())) == NULL)
+   goto end;
+   if (enc)
+   wbio=BIO_push(bzl,wbio);
+   else
+   rbio=BIO_push(bzl,rbio);
+   }
+#endif
 
for (;;)
{
-- 
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 #2438] [PATCH] ecrypto/ecdsa: fix a zero change in the test suite

[Sebastian Andrzej Siewior via RT]

* Stephen Henson via RT | 2012-03-03 14:41:51 [+0100]:

 [sebast...@breakpoint.cc - Fri Mar 02 08:55:25 2012]:
 
 * Stephen Henson via RT | 2012-02-27 17:43:48 [+0100]:
 
 According to our records, your request has been resolved. If you have any
 further questions or concerns, please respond to this message.
 
 Is there a commit id or patch somewhere where I can look at the fix?
 

Yes, see:

http://cvs.openssl.org/chngview?cn=21780
Thanks.

This changes the testcases but the ASN1 parses still accepts idefinite
length prmitive encodings? I remember someone suggested to change this
as well.

Steve.

Sebastian


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

Re: [openssl.org #2438] Resolved: [PATCH] ecrypto/ecdsa: fix a zero change in the test suite

[Sebastian Andrzej Siewior via RT]

* Stephen Henson via RT | 2012-02-27 17:43:48 [+0100]:

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

Is there a commit id or patch somewhere where I can look at the fix?

Sebastian


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

[openssl.org #2438] [PATCH] ecrypto/ecdsa: fix a zero change in the test suite

[Sebastian Andrzej Siewior via RT]

At the end of the testsuite in test_builtin() happens the following:
- a previously created signature gets modified at a random spot
- this signaure is compared against the data which was used to create the
  signature.

Now, in theory this should always fail in reality is passed sometimes. The
modifcation algorith did the following:
|   offset = sig[10] % 66;
|   dirt = sig[11];
|   dirt = dirt ? dirt : 1;
|   sig[offset] ^= dirt;

If sig[10] is 0xa7 and sig[11] is 0x9e the last line envolves to:
|   sig[35] ^= 0x9e;

The signature consists of to BIGNUMs encoded as ASN1 string. sig[34] and
sig[35] is the begin of the second and last number. sig[35] contains the
length of this number and its content is 0x1e. Now, 0x9e ^ 0x1e = 0x80
and this is a special value. It means that the length of the value is
infinite i.e. everything until the end of the stream. So the ASN1 parser
considers the remaining data as the last element. Since there is nothing
after it, it succeeds. This random modification was a zero change.

This change ensures that something like this does not happen again. If we
do a zero change by accident (R and S are unchanged) we make a third
change and hope that something will change now.

This bug has been reported as a Debian #440538 against 0.9.8e. I could
reproduce it on current 0.9 series, 1.0 looks affected as well.

Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
 crypto/ecdsa/ecdsatest.c |   87 +++---
 1 files changed, 82 insertions(+), 5 deletions(-)

diff --git a/crypto/ecdsa/ecdsatest.c b/crypto/ecdsa/ecdsatest.c
index aa4e148..67db141 100644
--- a/crypto/ecdsa/ecdsatest.c
+++ b/crypto/ecdsa/ecdsatest.c
@@ -281,6 +281,85 @@ x962_err:
return ret;
}
 
+static int compare_sig(unsigned char *osig, unsigned int sig_len, ECDSA_SIG 
*old_sig)
+{
+   unsigned char *signature = osig;
+   ECDSA_SIG *new_sig = NULL;
+   char *org_r = NULL, *org_s = NULL;
+   char *new_r = NULL, *new_s = NULL;
+   int ret = -1;
+
+   org_r = BN_bn2hex(old_sig-r);
+   org_s = BN_bn2hex(old_sig-s);
+   if (!org_r || !org_s)
+   goto out;
+
+   new_sig = ECDSA_SIG_new();
+   if (!new_sig)
+   goto out;
+   if (!d2i_ECDSA_SIG(new_sig, (const unsigned char **)signature, 
sig_len))
+   goto out;
+
+   new_r = BN_bn2hex(new_sig-r);
+   new_s = BN_bn2hex(new_sig-s);
+   if (!new_r || !new_s)
+   goto out;
+   if ((!strcmp(org_r, new_r)) 
+   !strcmp(org_s, new_s))
+   /* the signature did not change */
+   ret = 1;
+   else
+   ret = 0;
+out:
+   if (new_sig)
+   ECDSA_SIG_free(new_sig);
+   if (new_r)
+   OPENSSL_free(new_r);
+   if (new_s)
+   OPENSSL_free(new_s);
+   if (org_r)
+   OPENSSL_free(org_r);
+   if (org_s)
+   OPENSSL_free(org_s);
+   return ret;
+}
+
+static void modify_signature(unsigned char *osig, unsigned int sig_len, BIO 
*out)
+{
+   unsigned char dirt, offset;
+   unsigned char *signature = osig;
+   ECDSA_SIG *org_sig;
+   int ret;
+
+   org_sig = ECDSA_SIG_new();
+   if (!org_sig)
+   return;
+
+   if (!d2i_ECDSA_SIG(org_sig, (const unsigned char **)signature, 
sig_len))
+   goto out;
+
+   signature = osig;
+   offset = signature[10] % sig_len;
+   dirt = signature[11];
+   dirt = dirt ? dirt : 1;
+   signature[offset] ^= dirt;
+
+   ret = compare_sig(osig, sig_len, org_sig);
+   if (ret = 0)
+   goto out;
+
+   signature[offset] = ~signature[offset];
+   ret = compare_sig(osig, sig_len, org_sig);
+   if (ret = 0)
+   goto out;
+   BIO_printf(out, Failed to modify signature. Tried: %02x = %02x = 
%02x\n,
+   (unsigned char) (~osig[offset] ^ dirt),
+   (unsigned char)~osig[offset], osig[offset]);
+   BIO_printf(out, at offset 0x%02x and it was always equal.\n, offset);
+out:
+   ECDSA_SIG_free(org_sig);
+}
+
 int test_builtin(BIO *out)
{
EC_builtin_curve *curves = NULL;
@@ -325,8 +404,6 @@ int test_builtin(BIO *out)
/* now create and verify a signature for every curve */
for (n = 0; n  crv_len; n++)
{
-   unsigned char dirt, offset;
-
nid = curves[n].nid;
if (nid == NID_ipsec4)
continue;
@@ -416,9 +493,9 @@ int test_builtin(BIO *out)
BIO_printf(out, .);
(void)BIO_flush(out);
/* modify a single byte of the signature */
-   offset = signature[10] % sig_len;
-   dirt   = signature[11];
-   signature[offset] ^= dirt ? dirt : 1; 
+
+   modify_signature(signature, sig_len, out);
+