Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

2016-01-15 Thread Hubert Kario
On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 13:56 , "Hubert Kario" wrote: > >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: > >> If you already know what Dr. Henson explained in the quoted emails > >> - >

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

2016-01-15 Thread Blumenthal, Uri - 0553 - MITLL
Yes, and I can live with this update.  I still think it would be nice to inform the user of ‎what to expect in the (unlikely but possible) case when his data is not an output of some cryptographic hash function.  Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.  

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

2016-01-15 Thread Hubert Kario
On Friday 15 January 2016 14:03:33 Blumenthal, Uri - 0553 - MITLL wrote: > Yes, and I can live with this update. Submitted as https://github.com/openssl/openssl/pull/554 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o.,

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

2016-01-15 Thread Blumenthal, Uri - 0553 - MITLL
Yes you are correct. But... For RSA ‎the max size cannot be greater than the modulus, and while I agree that usually it would be less, in general it doesn't have to be, with no negative impact on security when data to be signed is large enough to leave no room for padding. For ECDSA truncating

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

2016-01-15 Thread Albe Laurenz via RT
Hubert Kario wrote: > The bug is still present in version tagged as OpenSSL_1_1_0-pre1 > > Moreover I've verified that the miTLS implementation[1] shows expected > behaviour - it accepts the interleaved application data everywhere but > between CCS and Finished. I don't know if that is feasible,

[openssl-dev] [openssl.org #4241] OpenSSL accepting curve coordinates outside mod p

2016-01-15 Thread Hanno Boeck via RT
I wanted to report a behavior of the OpenSSL API that I find at least highly unusual and unexpected and I suggest to change. It's regarding these functions to set curve coordinates: EC_POINT_set_affine_coordinates_GFp EC_POINT_set_compressed_coordinates_GFp It is possible to pass them a

[openssl-dev] [openssl.org #4240] Document some of the speed options

2016-01-15 Thread Tomas Mraz via RT
The attached patch provides documentation of some of the currently undocumented speed options. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) diff

Re: [openssl-dev] Behavior of OpenSSL EC API regarding point setting

2016-01-15 Thread Hanno Böck
On Wed, 16 Dec 2015 16:01:02 + "Salz, Rich" wrote: > > I would recommend and find it generally a cleaner approach if the > > curve point setting functions would reject both invalid points and > > point coordinates larger than p. > > Certainly out-of-range. Not sure

Re: [openssl-dev] [openssl-users] OPenssl and dependencies such as openssh

2016-01-15 Thread Salz, Rich
> All right, can the above be committed and any other source-backwards- > compatible behaviour ? > > This will help API developers a lot. It was done and is part of the yesterday's alpha release. ___ openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #4244] dhparam -check should

2016-01-15 Thread Eric Mumpower via RT
Code inspection suggests that when running "openssl dhparam -check -out foo 2048", the safety of the generated prime is only indicated via stdout. I suggest one of three safety improvements here, in order of what I believe to be decreasing safety: (1) Regardless of whether the "-check" flag is

[openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque

2016-01-15 Thread Richard Levitte via RT
This is according to our interpretation of "type opacity", meaning that the type name is available but not its content. "Data hiding" is another way to put it. This means that there will be a need to adapt, stack allocated EVP_CIPHER_CTX is no longer allowed, but there are functions to allocate

[openssl-dev] [openssl.org #4238] DTLS v1.2 not supported

2016-01-15 Thread Anupam Datta via RT
Hi, My openssl version is OpenSSL 1.1.0-pre2-dev xx XXX But when calling DTLSv1_2_client_method() , it shows compiler error as undefined reference to DTLSv1_2_client_method() Can you please look at this matter ? ___ openssl-bugs-mod mailing list

[openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains

2016-01-15 Thread Zi Lin via RT
Hi OpenSSL Devs, I have this bug fix for a broken wildcard matching on punycode domain in OpenSSL. Specifically, the current implementation actually can't match "www.xn--foobar.com" against a certificate using SAN "*.xn--foobar.com". I filed a issue on github too.

[openssl-dev] [openssl.org #4242] OpenSSL ECC coordinate functions accept invalid curve points

2016-01-15 Thread Hanno Boeck via RT
The EC_POINT_* API functions accept invalid curve points and don't do point verification. Invalid curve points are one of the major implementation pitfalls in ECC and can lead to attacks [1]. OpenSSL properly validates points in the _oct2point functions, but I still find this risky. This looks

[openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque

2016-01-15 Thread baldu...@units.it via RT
hello, apologies if I am missing something here. There seems to be an inconsistency in 1.1.0-pre2 (didn't check -pre1). EVP_CIPHER_CTX is typedef'd in ossl_typ.h like this: typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX; but struct evp_cipher_ctx_st isn't exposed any longer (it used to

Re: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains

2016-01-15 Thread Viktor Dukhovni via RT
> On Jan 15, 2016, at 10:32 AM, Zi Lin via RT wrote: > > Yes, this will get fixed. Thanks. -- Viktor. smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Richard Levitte
In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25 +0100, Rainer Jung said: rainer.jung> Hi, rainer.jung> rainer.jung> the list of downloadable files on http://openssl.org/source/ contains rainer.jung> pre1 *and* pre2 files for 1.1. Furthermore

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Blumenthal, Uri - 0553 - MITLL
On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte" wrote: >In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25 >+0100, Rainer Jung said: > >rainer.jung> In addition one

[openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Rainer Jung
Hi, the list of downloadable files on http://openssl.org/source/ contains pre1 *and* pre2 files for 1.1. Furthermore pre1 is listed above pre2. IMHO pre2 is what people should test and pre1 is no longer entitled to be listed on that page. So I suggest to remove pre1 from the list. I don't

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

2016-01-15 Thread Richard Levitte
In message on Fri, 15 Jan 2016 18:38:32 +, "Blumenthal, Uri - 0553 - MITLL" said: uri> On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte" uri> wrote: uri> uri>

Re: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque

2016-01-15 Thread Viktor Dukhovni
> On Jan 15, 2016, at 10:32 AM, baldu...@units.it via RT > wrote: > > This seems to be the reason why trying to build openssh-7.1p2 (with > -DOPENSSL_API_COMPAT=0x1000L) fails with: > >In file included from ssh_api.h:26:0, > from ssh_api.c:21: >

Re: [openssl-dev] [openssl.org #4243] 1.1.0-pre2: bug: EVP_CIPHER_CTX isn't completely opaque

2016-01-15 Thread Viktor Dukhovni via RT
> On Jan 15, 2016, at 10:32 AM, baldu...@units.it via RT > wrote: > > This seems to be the reason why trying to build openssh-7.1p2 (with > -DOPENSSL_API_COMPAT=0x1000L) fails with: > >In file included from ssh_api.h:26:0, > from ssh_api.c:21: >

[openssl-dev] [openssl.org #4245] OpenSSL-1.1-pre2 e_oss.h and inline conflicts

2016-01-15 Thread Salz, Rich via RT
e_os.2 line 327:: # if !defined(inline) && !defined(__cplusplus) Should this be: # if !defined(ossl_inline) && !defined(__cplusplus) The purpose of this section is to end up with a good definition for ossl_inline If some preceding header file (and I have run across this) does a #define

Re: [openssl-dev] [openssl.org #4239] [PATCH] fixing wildcard matching on punycode domains

2016-01-15 Thread Viktor Dukhovni
On Fri, Jan 15, 2016 at 03:32:12PM +, Zi Lin via RT wrote: > I have this bug fix for a broken wildcard matching on punycode domain > in OpenSSL. Specifically, the current implementation actually can't > match "www.xn--foobar.com" against a certificate using SAN > "*.xn--foobar.com". I filed a

[openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine

2016-01-15 Thread deeng...@gmail.com via RT
req.c (and many of the other apps) appear to have lost the ability to use an engine. The attached diff is against the github.com verison using Tag OpenSSL_1_1-pre2 In the req_options[] table: OPT_KEY is set to "S" so pre- checking of the parameters does not drop the string passed to the

[openssl-dev] [openssl.org #4247] 1.1.0-pre2 on Sparc: incomplete adjustments for EVP_CIPHER_CTX opaqueness

2016-01-15 Thread Rainer Jung via RT
Building 1.1.0-pre2 on Solaris Sparc I get compilation errors, e.g. e_des.c: In function 'des_init_key': e_des.c:250:23: error: dereferencing pointer to incomplete type int mode = ctx->cipher->flags & EVP_CIPH_MODE; The following patch fixes them: Index: crypto/evp/e_camellia.c ---

Re: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine

2016-01-15 Thread Blumenthal, Uri - 0553 - MITLL via RT
Doug, could you please take a look at PR #548 (or is it #549)? It also addresses this KEY_FORM issue. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: deeng...@gmail.com via RT Sent: Friday, January 15, 2016 17:10 Reply To: r...@openssl.org

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published

2016-01-15 Thread Jouni Malinen
On Thu, Jan 14, 2016 at 03:35:48PM -0500, Viktor Dukhovni wrote: > Thanks for the prompt error report. If you're willing to share your > test chains, and if it is likely to be not too difficult to include > them with the OpenSSL bundled tests, that might be worth looking into. All the test case