Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Benjamin Baratte]

Hi Cygwin team,

I would like to understand why the OpenSSL 1.1.1b package only includes the
NIST EC curves support ?
I'm basically try to use brainpool curves and I have noticed that the
package 1.1.1b does not includes these curves and more generally only
includes NIST curves

$ openssl version
OpenSSL 1.1.1b  26 Feb 2019

$ openssl ecparam -list_curves
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

Also, I have checked the OpenSSL package 1.0.2r and here is the list of
curve support :
$ openssl version
OpenSSL 1.0.2r  26 Feb 2019

$ openssl ecparam -list_curves
  secp112r1 : SECG/WTLS curve over a 112 bit prime field
  secp112r2 : SECG curve over a 112 bit prime field
  secp128r1 : SECG curve over a 128 bit prime field
  secp128r2 : SECG curve over a 128 bit prime field
  secp160k1 : SECG curve over a 160 bit prime field
  secp160r1 : SECG curve over a 160 bit prime field
  secp160r2 : SECG/WTLS curve over a 160 bit prime field
  secp192k1 : SECG curve over a 192 bit prime field
  secp224k1 : SECG curve over a 224 bit prime field
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
  prime192v2: X9.62 curve over a 192 bit prime field
  prime192v3: X9.62 curve over a 192 bit prime field
  prime239v1: X9.62 curve over a 239 bit prime field
  prime239v2: X9.62 curve over a 239 bit prime field
  prime239v3: X9.62 curve over a 239 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field
  sect113r1 : SECG curve over a 113 bit binary field
  sect113r2 : SECG curve over a 113 bit binary field
  sect131r1 : SECG/WTLS curve over a 131 bit binary field
  sect131r2 : SECG curve over a 131 bit binary field
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
  sect163r1 : SECG curve over a 163 bit binary field
  sect163r2 : NIST/SECG curve over a 163 bit binary field
  sect193r1 : SECG curve over a 193 bit binary field
  sect193r2 : SECG curve over a 193 bit binary field
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect239k1 : SECG curve over a 239 bit binary field
  sect283k1 : NIST/SECG curve over a 283 bit binary field
  sect283r1 : NIST/SECG curve over a 283 bit binary field
  sect409k1 : NIST/SECG curve over a 409 bit binary field
  sect409r1 : NIST/SECG curve over a 409 bit binary field
  sect571k1 : NIST/SECG curve over a 571 bit binary field
  sect571r1 : NIST/SECG curve over a 571 bit binary field
  c2pnb163v1: X9.62 curve over a 163 bit binary field
  c2pnb163v2: X9.62 curve over a 163 bit binary field
  c2pnb163v3: X9.62 curve over a 163 bit binary field
  c2pnb176v1: X9.62 curve over a 176 bit binary field
  c2tnb191v1: X9.62 curve over a 191 bit binary field
  c2tnb191v2: X9.62 curve over a 191 bit binary field
  c2tnb191v3: X9.62 curve over a 191 bit binary field
  c2pnb208w1: X9.62 curve over a 208 bit binary field
  c2tnb239v1: X9.62 curve over a 239 bit binary field
  c2tnb239v2: X9.62 curve over a 239 bit binary field
  c2tnb239v3: X9.62 curve over a 239 bit binary field
  c2pnb272w1: X9.62 curve over a 272 bit binary field
  c2pnb304w1: X9.62 curve over a 304 bit binary field
  c2tnb359v1: X9.62 curve over a 359 bit binary field
  c2pnb368w1: X9.62 curve over a 368 bit binary field
  c2tnb431r1: X9.62 curve over a 431 bit binary field
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
  Oakley-EC2N-3:
        IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
        Not suitable for ECDSA.
        Questionable extension field!
  Oakley-EC2N-4:
        IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
        Not suitable for ECDSA.
        Questionable extension field!
  brainpoolP160r1: RFC 5639 curve over a 160 bit prime field
  brainpoolP160t1: RFC 5639 curve over a 160 bit prime field
  brainpoolP192r1: RFC 5639 curve over a 192 bit prime field
  brainpoolP192t1: RFC 5639 curve over a 192 bit prime field
  brainpoolP224r1: RFC 5639 curve over a 224 bit prime field
  brainpoolP224t1: RFC 5639 curve over a 224 bit prime field
  brainpoolP256r1: RFC 5639 curve over a 256 bit prime field
  brainpoolP256t1: RFC 5639 curve over a 256 bit prime field
  brainpoolP320r1: RFC 5639 curve over a 320 bit prime field
  brainpoolP320t1: RFC 5639 curve over a 320 bit prime field
  brainpoolP384r1: RFC 5639 curve over a 384 bit prime field
  brainpoolP384t1: RFC 5639 curve over a 384 bit prime field
  brainpoolP512r1: RFC 5639 curve over a 512 bit prime field
  brainpoolP512t1: RFC 5639 curve over a 512 bit prime field

From what I have found in Google, the cygwin OpenSSL 1.1.1b package is
bound to the fedora package spec which is deactivating brainpool curves.

I'm a bit surprised by the differences in the 2 OpenSSL packages. But I
need to use Brainpool curves.

On top of that, the installer is proposing the OpenSSL 1.1.1b-1 package as
the newest one prevailing to OpenSSL 1.0.2r-1 package. Is it possible to
get back the brainpool curves into the OpenSSL 1.1.1b-1 package ?
if not, could please explain to me why only NIST curves are now supported
in the official package ?

Thanks for your response

Best Regards,

Benjamin

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Brian Inglis]

On 2019-06-03 06:09, Benjamin Baratte wrote:
> I would like to understand why the OpenSSL 1.1.1b package only includes the
> NIST EC curves support ?
> I'm basically try to use brainpool curves and I have noticed that the
> package 1.1.1b does not includes these curves and more generally only
> includes NIST curves

> From what I have found in Google, the cygwin OpenSSL 1.1.1b package is
> bound to the fedora package spec which is deactivating brainpool curves.
> 
> I'm a bit surprised by the differences in the 2 OpenSSL packages. But I
> need to use Brainpool curves.
> 
> On top of that, the installer is proposing the OpenSSL 1.1.1b-1 package as
> the newest one prevailing to OpenSSL 1.0.2r-1 package. Is it possible to
> get back the brainpool curves into the OpenSSL 1.1.1b-1 package ?
> if not, could please explain to me why only NIST curves are now supported
> in the official package ?

I have seen comments about legal liability, poor performance limited by choice
of random keys, small size of random keys, another model specific Intel FP bug:

https://github.com/openssl/openssl/blob/master/CHANGES
"Montgomery multiplication may produce incorrect results

     There is a carry propagating bug in the Broadwell-specific Montgomery
     multiplication procedure that handles input lengths divisible by, but
     longer than 256 bits. ... Otherwise the bug can manifest itself as
     transient authentication and key negotiation failures or reproducible
     erroneous outcome of public-key operations with specially crafted input.
     Among EC algorithms only Brainpool P-512 curves are affected and one
     presumably can attack ECDH key negotiation. ...

     This issue was publicly reported as transient failures and was not
     initially recognized as a security issue. Thanks to Richard Morgan for
     providing reproducible case.
     (CVE-2016-7055)
     [Andy Polyakov]"

You can easily rebuild the package yourself with the cygport utility, to check
that works, then change the build config to include the Brainpool ECs, and
rebuild the way you want it.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Steven Penny]

On Mon, 3 Jun 2019 14:35:29, Brian Inglis wrote:
> You can easily rebuild the package yourself with the cygport utility, to check
> that works, then change the build config to include the Brainpool ECs, and
> rebuild the way you want it.

Please do not presume someones technical prowess. It might be easy *to you*, but
its certainly not easy in an objective sense, and definitely not to a novice
Cygwin user.

This is coming from someone who has built hundreds of Cygwin and Mingw64
packages. Have some perspective.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Benjamin Baratte]

Hi Guys,

Thanks for your feedback.

I have recompile the openssl package with Cygport and this has allowed
me to point out the differences between the OpenSSL mainline and the
Cygwin pacakge.
Actually the Cygwin package follow the spec from Fedora package where
it has been decided to remove some patented algorithms.
After some readings on wikipedia, the implementation of the Brainpool
curves may requires patented method to be as efficient as NIST curves.
(https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Implementation)

I don't know if OpenSSL use such optimization algorithm but I find out
that we can use the Brainpool curves by providing the ECC parameters
to OpenSSL 1.1.1b Fedora version.
(https://bitnuts.de/articles/using_brainpool_ecc_in_openssl.html)

Therefore the patch will remove builtin support of RFC defined
Brainpool curves (and others) and keep only NIST which are optimized
remove only the named curves but not the algorithms behind.
I'm not legal person therefore I can't tell if this is really make any
difference but I think the algorithm is still embedded in the OpenSSL
package.

I think that the default ECC implementation is not optimized of all
curves except for NIST curves.

May be this needs to be check with OpenSSL team ?

Anyway, Steven you are right compiling a package like OpenSSL is not
straightforward even with Cygport but still feasable with reasonnable
efforts (I guess because I'm used to have unsual setup where automatic
tool does not work out of the box :) )

Regarding the CVE-2016-7055 pointed by Brian, as far as I have read
this is impacting only the Brainpool P 512 curve and this is not
compromizing the private key and I think we could restrict the
restriction to this curves only.
(https://nvd.nist.gov/vuln/detail/CVE-2016-7055)

Best Regards,

Ben


Le mar. 4 juin 2019 à 00:36, Steven Penny <svnpenn@gmail.com> a écrit :
>
> On Mon, 3 Jun 2019 14:35:29, Brian Inglis wrote:
> > You can easily rebuild the package yourself with the cygport utility, to check
> > that works, then change the build config to include the Brainpool ECs, and
> > rebuild the way you want it.
>
> Please do not presume someones technical prowess. It might be easy *to you*, but
> its certainly not easy in an objective sense, and definitely not to a novice
> Cygwin user.
>
> This is coming from someone who has built hundreds of Cygwin and Mingw64
> packages. Have some perspective.
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Brian Inglis]

On 2019-06-03 16:36, Steven Penny wrote:
> On Mon, 3 Jun 2019 14:35:29, Brian Inglis wrote:
>> You can easily rebuild the package yourself with the cygport utility, to check
>> that works, then change the build config to include the Brainpool ECs, and
>> rebuild the way you want it.
> 
> Please do not presume someones technical prowess. It might be easy *to you*, but
> its certainly not easy in an objective sense, and definitely not to a novice
> Cygwin user.
> 
> This is coming from someone who has built hundreds of Cygwin and Mingw64
> packages. Have some perspective.

I am encouraging and offering the poster a way to solve their problem, after
providing some possible reasons for dropping support from some ECs.
Rebuilding a Cygwin package from source using cygport is a relatively easy task.
I am not presuming, but assuming some amount of technical expertise, based on a
poster asking about openssl configuration and which ECs they want to support.
If they need more help they can ask in a follow up.

Please refrain from your own inappropriate assumptions and meta-commentary based
on that, as this is not a social media platform.
Why would you assume the poster is a novice?
Before commenting, please try yourself to consider multiple perspectives on
posts and replies?
"There are more things in heaven and Earth, Horatio, Than are dreamt of in your
philosophy." Hamlet: Shakespeare

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Steven Penny]

On Tue, 4 Jun 2019 09:25:48, Brian Inglis wrote:
> I am encouraging and offering the poster a way to solve their problem, after
> providing some possible reasons for dropping support from some ECs.
> Rebuilding a Cygwin package from source using cygport is a relatively easy
> task.

Easy compared to what, assembly? I am comfortable with 3 programming languages,
and learning 4 others, and compiling C is not "relatively easy". Especially
considering the scope:

    $ cd openssl-master
    $ find -name '*.c' -exec wc -l {} + | tail -1
    419738 total

400,000 lines of C.

> I am not presuming, but assuming some amount of technical expertise, based on
> a poster asking about openssl configuration and which ECs they want to
> support. If they need more help they can ask in a follow up.

reread the post:

https://cygwin.com/ml/cygwin/2019-06/msg00012.html

He shows some domain knowledge of OpenSSL, but where are you getting that he
knows about compiling C? A conservative read would reveal that he might have no
knowledge of compiling C, and you want him to compile 400,000 lines of C because
its "easy".

> Please refrain from your own inappropriate assumptions and meta-commentary
> based on that, as this is not a social media platform.

No, but it is a public forum. and I will call out nonsense if I see it. As your
type of comments are off putting to new users.

> Why would you assume the poster is a novice? Before commenting, please try
> yourself to consider multiple perspectives on posts and replies?

As should you.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Vince Rice]

> On Jun 4, 2019, at 5:55 PM, Steven Penny wrote:
> 
> Easy compared to what, assembly?

Easy compared to hard.

> He shows some domain knowledge of OpenSSL, but where are you getting that he
> knows about compiling C? 

It's cygport, he doesn't have to know about compiling C. He has to know about
running a one-line cygport command.

>> Please refrain from your own inappropriate assumptions and meta-commentary
>> based on that, as this is not a social media platform.
> 
> No, but it is a public forum. and I will call out nonsense if I see it. As your
> type of comments are off putting to new users.

Brian offered the user help. Brian is one of the most helpful people on this list. You
offered the user nothing, and berated Brian for offering help. The only nonsense on
offer here is from you. And the only one off-putting in this conversation is you.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Steven Penny]

On Tue, 4 Jun 2019 22:04:16, Vince Rice wrote:
> It's cygport, he doesn't have to know about compiling C. He has to know about
> running a one-line cygport command.

This just seems purposefully ignorant. How exactly is he suppose to modify the C
source to address the problem and recompile, if he doesnt know anything about
compiling C?

> You offered the user nothing, and berated Brian for offering help. The only
> nonsense on offer here is from you. And the only one off-putting in this
> conversation is you.

Oh really? Is that why OP agreed with me?:

> Anyway, Steven you are right compiling a package like OpenSSL is not
> straightforward even with Cygport but still feasable with reasonnable efforts
> (I guess because I'm used to have unsual setup where automatic tool does not
> work out of the box :) )

https://cygwin.com/ml/cygwin/2019-06/msg00026.html

Read the thread dude and stop trolling.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Houder]

On Tue, 4 Jun 2019 22:04:16, Vince Rice  wrote:

> It's cygport, he doesn't have to know about compiling C. ...

Vince, this utter nonsense, and you know it!

Henri


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r

[Brian Inglis]

On 2019-06-04 22:26, Houder wrote:
> On Tue, 4 Jun 2019 22:04:16, Vince Rice  wrote:
>> It's cygport, he doesn't have to know about compiling C. ...
> Vince, this utter nonsense, and you know it!

He hopefully should not, just rebuilding and reconfiguring an existing source
package, with current tools.

C difficulties normally occur after compiler upgrades.
Most cygport issues revolve around autotools, autoconfig, automake, and require
conversations with upstream for joint resolution across systems.

If he has difficulties, he could post here, and we'd help.
Anyway, he appears to have been successful.

RFC IPR section comments "implementations based on these domain parameters may
require use of inventions covered by patent rights. In particular, techniques
for an efficient arithmetic exploiting the special parameters of the twisted
curves may be covered by patents."
Certicom Research published a number of papers on efficient Brainpool ECCs.
The OP may want to run that by his org's legal IP group.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple