Re: [openssl-dev] [Bug] OpenSSL does not send short messages

2016-04-25 Thread Viktor Dukhovni
[ This question belongs on openssl-users, not openssl-dev. Please reply only to openssl-users. ] On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote: > SSL_write followed by SSL_shutdown does not actually send the data passed > to SSL_write if the total data size sent is less than

[openssl-dev] SSL transfer connection (SSL_dup, SSL_up_ref, SSL_free)

2016-04-25 Thread Alex Hultman
Hi Benjamin, Thanks for the answer. I actually found a working solution just a couple of minutes after I posted but I still wanted to hear what you recommended. I just did ssl->references++; and also the same on the attached BIO's before SSL_set_fd. This works perfectly and I'm able to take over

[openssl-dev] [Bug] OpenSSL does not send short messages

2016-04-25 Thread Alex Hultman
Hi, I've found a very central bug that affects all my OpenSSL applications including the official server example code, the vanilla Node.js HTTPs server and my (arguably non-correct) own server project. https://github.com/openssl/openssl/issues/992 SSL_write followed by SSL_shutdown does not

Re: [openssl-dev] [openssl.org #4521] openssl GCM ordering

2016-04-25 Thread Brian Smith
Praveen Kariyanahalli via RT wrote: > Is there is a reason why openssl has restriction of auth before encrypt > order ? I dont believe there is an algo restriction, was wondering why > openssl has this. > It *is* inherent in the algorithm. The authentication tag for the AAD is

Re: [openssl-dev] [openssl.org #4521] openssl GCM ordering

2016-04-25 Thread Salz, Rich via RT
Why do you want GCM then? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4521 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 #4521] openssl GCM ordering

2016-04-25 Thread Praveen Kariyanahalli via RT
Is there is a reason why openssl has restriction of auth before encrypt order ? I dont believe there is an algo restriction, was wondering why openssl has this. *int CRYPTO_gcm128_aad(GCM128_CONTEXT *ctx, const unsigned char *aad,* * size_t len)* *{* *[snip]* *if

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Richard Levitte via RT
So, listening to what everyone had to say, perhaps this PR is better then: https://github.com/openssl/openssl/pull/995 In message on Mon, 25 Apr 2016 17:45:05 +, "Salz, Rich" said: rsalz> rsalz> >

[openssl-dev] [openssl.org #4520] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

2016-04-25 Thread Rainer Jung via RT
The change https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed introduced a typo in the last line of file crypto/camellia/build.info. The fix is: --- crypto/camellia/build.info2016-03-16 19:18:09.0 +0100 +++ crypto/camellia/build.info2016-04-19

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Viktor Dukhovni
On Mon, Apr 25, 2016 at 05:45:05PM +, Salz, Rich wrote: > After a "set0" call, set your pointer to NULL, it's no longer yours :) That half of the ruleset. The other half is: You must "own" any object passed to a set0 call that takes ownership of its argument (we have a few that don't

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Salz, Rich
> The 3-slot function is I think cleaner. > > I'll leave the decision of whether and when to support NULL parameters to > the folks working on that code, but it is pretty clear that one must not pass > an > object one does not "own", such as one returned from a "get0" function, to a > function

[openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Salz, Rich via RT
> Yes, but this difference adds convenience, IMHO. My preference is this: > RSA_set0_key(rsa, n, e, d); with any parameter (except for rsa :) potentially > NULL. This defeats a main point: partial construction is a bad thing. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4518

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Viktor Dukhovni
On Mon, Apr 25, 2016 at 07:21:56PM +0200, Richard Levitte wrote: > openssl-users> Perhaps the documentation can be made more clear. If users > really > openssl-users> need an interface for modifying a subset of the components of > an > openssl-users> already initialized key, then (if we don't

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Blumenthal, Uri - 0553 - MITLL
>There isn't much difference between this: > >RSA_set0_key(rsa, n, NULL, NULL); >RSA_set0_key(rsa, NULL, e, NULL); >RSA_set0_key(rsa, NULL, NULL, d); > >and something like this: > >RSA_set0_n(rsa, n); >RSA_set0_e(rsa, e); >RSA_set0_d(rsa, d); The attractiveness of

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Richard Levitte
In message <20160425141410.gx26...@mournblade.imrryr.org> on Mon, 25 Apr 2016 14:14:10 +, Viktor Dukhovni said: openssl-users> Perhaps the documentation can be made more clear. If users really openssl-users> need an interface for modifying a subset of the

Re: [openssl-dev] SSL transfer connection (SSL_dup, SSL_up_ref, SSL_free)

2016-04-25 Thread Benjamin Kaduk
On 04/23/2016 12:26 AM, Alex Hultman wrote: > Hi, > > I'm having trouble "duping" an SSL connection. I have an SSL *pointer > that is going to be SSL_free'd, so I need to clone it or up the ref > count or somehow make it stay alive. I see that in OpenSSL 1.1.0 it > seems you added the SSL_up_ref -

Re: [openssl-dev] [openssl.org #4519] [openssl.org bug #993] New bug report

2016-04-25 Thread Salz, Rich
> Should I make similar in https://rt.openssl.org/ or it is enough to have in > github.com? We prefer bug reports in RT, not as issues. PR's on GitHub are fine. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4519] [openssl.org bug #993] New bug report

2016-04-25 Thread Salz, Rich via RT
> Should I make similar in https://rt.openssl.org/ or it is enough to have in > github.com? We prefer bug reports in RT, not as issues. PR's on GitHub are fine. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4519 Please log in as guest with password guest if prompted --

[openssl-dev] [openssl.org #4519] [openssl.org bug #993] New bug report

2016-04-25 Thread Jaan Murumets via RT
Hello. We have made new bug report https://github.com/openssl/openssl/issues/993 Should I make similar in https://rt.openssl.org/ or it is enough to have in github.com? Jaan Murumets Estonian ID-Software product manager -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4519

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Viktor Dukhovni
On Mon, Apr 25, 2016 at 02:08:09PM +, Richard Levitte via RT wrote: > I'm not sure how I'd change the following: > > Calling this function transfers the memory management of the values to the > RSA object, and therefore the values that have been passed in should not > be freed by

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Viktor Dukhovni
On Mon, Apr 25, 2016 at 01:39:09PM +, Richard Levitte via RT wrote: > rt> I agree it shouldn't happen, but do we want to protect against that? I > could be convinced either way. > > Ah ok... sorry, I misread the intention. > > Agreed that we could make sure not to free the pointers in

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Richard Levitte via RT
In message on Mon, 25 Apr 2016 14:04:27 +, Tomas Mraz via RT said: rt> On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote: rt> > In message on rt> >

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Tomas Mraz via RT
On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote: > In message on > Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT" > said: > > rt> No, he means setting the same value twice.  For example, making > this

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Tomas Mraz
On Po, 2016-04-25 at 13:39 +, Richard Levitte via RT wrote: > In message on > Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT" > said: > > rt> No, he means setting the same value twice.  For example, making > this

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Richard Levitte via RT
I believe this PR fixes the issue for RSA, DSA and DH (they all share the same concept). https://github.com/openssl/openssl/pull/994 Cheers, Richard In message on Mon, 25 Apr 2016 13:39:09 +, Richard Levitte via RT

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Richard Levitte via RT
In message on Mon, 25 Apr 2016 13:19:38 +, "Salz, Rich via RT" said: rt> No, he means setting the same value twice. For example, making this change: rt> If (r=->n != n) BN_free(r->n); rt> If(r->e != e)

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Douglas E Engert
Freeing of the values by the caller is not the issue. The issue is RSA_set0_key requires n and e to be none NULL. It the caller use RSA_get0_key to find the n and e then calculates a new d, than calls RSA_set0_key with the the same n and e pointers and the new d. RSA_set0_key will free n and e,

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread deeng...@gmail.com via RT
Freeing of the values by the caller is not the issue. The issue is RSA_set0_key requires n and e to be none NULL. It the caller use RSA_get0_key to find the n and e then calculates a new d, than calls RSA_set0_key with the the same n and e pointers and the new d. RSA_set0_key will free n and e,

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Tomas Mraz
On Po, 2016-04-25 at 13:08 +, Richard Levitte via RT wrote: >  > rsalz> > If nothing else, all the RSA_set0 routines should test if > the same pointer > rsalz> > value is being replaced if so do not free it. > rsalz> >  > rsalz> > The same logic need to be done for all the RSA_set0_* >

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Tomas Mraz via RT
On Po, 2016-04-25 at 13:08 +, Richard Levitte via RT wrote: >  > rsalz> > If nothing else, all the RSA_set0 routines should test if > the same pointer > rsalz> > value is being replaced if so do not free it. > rsalz> >  > rsalz> > The same logic need to be done for all the RSA_set0_* >

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Salz, Rich via RT
No, he means setting the same value twice. For example, making this change: If (r=->n != n) BN_free(r->n); If(r->e != e) BN_free(r->e); If (r->d != d) BN_free(r->d); I agree it shouldn't happen, but do we want to protect against that? I could be convinced either way. -- Ticket

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Salz, Rich
No, he means setting the same value twice. For example, making this change: If (r=->n != n) BN_free(r->n); If(r->e != e) BN_free(r->e); If (r->d != d) BN_free(r->d); I agree it shouldn't happen, but do we want to protect against that? I could be convinced either way. --

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Richard Levitte via RT
In message <6b097acbe9d94724ac545f2529e45...@usma1ex-dag1mb1.msg.corp.akamai.com> on Mon, 25 Apr 2016 11:38:47 +, "Salz, Rich" said: rsalz> > If nothing else, all the RSA_set0 routines should test if the same pointer rsalz> > value is being replaced if so do not free it.

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Salz, Rich
> Would not a set of routines like: > BIGNUM* RSA_get0_key_n(RSA *rsa); > int RSA_set0_key_n(RSA *rsa, BIGNUM *n); (A set for: n, e, d, p, q, idmp1, > idmq1, iqmp) be much more backward compatible? We had discussed this in the team, and decided that it was better to have a single API that took

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

2016-04-25 Thread Salz, Rich via RT
> Would not a set of routines like: > BIGNUM* RSA_get0_key_n(RSA *rsa); > int RSA_set0_key_n(RSA *rsa, BIGNUM *n); (A set for: n, e, d, p, q, idmp1, > idmq1, iqmp) be much more backward compatible? We had discussed this in the team, and decided that it was better to have a single API that took