Re: set/get utilities are not available to access variable 'num' of structure bio_st (Matt Caswell)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: set/get utilities are not available to access variable 'num' of structure bio_st (Matt Caswell)

Narayana, Sunil Kumar

Hi Matt,
               We are using  MEM type BIO. similar to the openssl library ‘BIO_TYPE_MEM ‘ we have an internal type defined like ex:- ‘BIO_TYPE_XYZ_MEM’  and all other mem utilities are internally defined.

Like XYZ_mem_new/XYZ_mem_read … etc  these utilities are accessing the bio_st variable ‘num’.

please suggest set/get utilities to handle this scenario.


Regards,

Sunil

From: openssl-users <[hidden email]> On Behalf Of [hidden email]
Sent: 20 November 2020 23:34
To: [hidden email]
Subject: openssl-users Digest, Vol 72, Issue 19

 


NOTICE: This email was received from an EXTERNAL sender



Send openssl-users mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

1. set/get utilities are not available to access variable
'num' of structure bio_st (Narayana, Sunil Kumar)
2. Re: set/get utilities are not available to access variable
'num' of structure bio_st (Matt Caswell)
3. EC curve preferences (Skip Carter)
4. RE: EC curve preferences (Michael Wojcik)


----------------------------------------------------------------------

Message: 1
Date: Fri, 20 Nov 2020 13:46:00 +0000
From: "Narayana, Sunil Kumar" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: set/get utilities are not available to access variable
'num' of structure bio_st
Message-ID:
<[hidden email]>

Content-Type: text/plain; charset="utf-8"

Hi ,
We are porting our Application from openssl 1.0.1 to openssl 3.0. In related to this activity we require to access the variable 'num' of structure bio_st.
In older versions the variable was accessed to set and get value using pointer operator (bi->num ).
Since this is not allowed in 3.0 we are looking for the Get/Set utilities similar to other member (BIO_set_flags/ BIO_get_flags)

Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.

Regards,
Sunil


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/f84c547a/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 20 Nov 2020 13:55:34 +0000
From: Matt Caswell <[hidden email]>
To: [hidden email]
Subject: Re: set/get utilities are not available to access variable
'num' of structure bio_st
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8



On 20/11/2020 13:46, Narayana, Sunil Kumar wrote:
> Hi ,
>
> ??????????????? We are porting our Application from ?openssl 1.0.1 to
> openssl 3.0. In related to this activity we require to access the
> variable ?*num*? of structure *bio_st. *
>
> In older versions the variable was accessed to set and get value using
> pointer operator (bi->num ).
>
> Since this is not allowed in 3.0 we are looking for the Get/Set
> utilities similar to other member*(BIO_set_flags/ BIO_get_flags) *
>
> ?
>
> Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.

What kind of BIO are you using? Different BIOs may provide different
mechanisms to get hold of this value. For example a number of file
descriptor based BIOs provide BIO_get_fd().

Matt



------------------------------

Message: 3
Date: Fri, 20 Nov 2020 08:43:59 -0800
From: Skip Carter <[hidden email]>
To: OpenSSL Users <[hidden email]>
Subject: EC curve preferences
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"


I am sure this in the documentation somewhere; but where ?

What are the preferred ECDH curves for a given keysize ? Which curves
are considered obsolete/deprecated/untrustworthy ?


--
Dr Everett (Skip) Carter??0xF29BF36844FB7922
[hidden email]

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/b8a90ad9/attachment-0001.sig>

------------------------------

Message: 4
Date: Fri, 20 Nov 2020 18:03:22 +0000
From: Michael Wojcik <[hidden email]>
To: Skip Carter <[hidden email]>, OpenSSL Users
<[hidden email]>
Subject: RE: EC curve preferences
Message-ID:
<[hidden email]>

Content-Type: text/plain; charset="utf-8"

> From: openssl-users <[hidden email]> On Behalf Of Skip
> Carter
> Sent: Friday, 20 November, 2020 09:44
>
> What are the preferred ECDH curves for a given keysize ? Which curves
> are considered obsolete/deprecated/untrustworthy ?

For TLSv1.3, this is easy. RFC 8446 B.3.1.4 only allows the following: secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D), x448(0x001E). Those are your choices. If you want interoperability, enable them all; if you want maximum security, only use X25519 and X448. See safecurves.cr.yp.to for the arguments in favor of the latter position.

Frankly, unless you're dealing with something of very high value or that needs to resist breaking for a long time, I don't see any real-world risk in using the SEC 2 curves. You might want to disallow just secp256r1 if you're concerned about that key size becoming tractable under new attacks or quantum computing within your threat timeframe. Ultimately, this is a question for your threat model.


For TLSv1.2, well...

- Some people recommend avoiding non-prime curves (i.e. over binary fields, such as the sect* ones) for intellectual-property reasons. I'm not going to try to get into that, because IANAL and even if I were, I wouldn't touch that without a hefty retainer.

- Current consensus, more or less, seems to be to use named curves and not custom ones. The arguments for that seem pretty persuasive to me. So don't use custom curves.

- Beyond that? Well, here's one Stack Exchange response from Thomas Pornin (who knows a hell of a lot more about this stuff than I do) where he suggests using just prime256v1 (which is the same as secp256r1 I believe?) and secp384r1:

https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use

Those are the curves in Suite B, before the NSA decided to emit vague warnings about ECC. They subsequently decided P384 aka secp384r1 is OK until post-quantum primitives are standardized. So if your application prefers secp384r1 for TLSv1.2, then you can decide whether to also allow prime256v1 for interoperability. Again, that's a question for your threat model.

All that said, some people will have different, and quite possibly better-informed, opinions on this.

--
Michael Wojcik

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 72, Issue 19
*********************************************

Reply | Threaded
Open this post in threaded view
|

Re: set/get utilities are not available to access variable 'num' of structure bio_st (Matt Caswell)

Matt Caswell-2


On 23/11/2020 11:28, Narayana, Sunil Kumar wrote:
> Hi Matt,
>                We are using  MEM type BIO. similar to the openssl
> library ‘BIO_TYPE_MEM ‘ we have an internal type defined like ex:-
> ‘BIO_TYPE_XYZ_MEM’  and all other mem utilities are internally defined.
>
> Like XYZ_mem_new/XYZ_mem_read … etc  these utilities are accessing the
> bio_st variable ‘*num’*.
>
> please suggest set/get utilities to handle this scenario.

If I understand correctly you want to store an "int" value internally to
a custom BIO.

Custom BIOs can associate an arbitrary data structure with the BIO
object and store whatever they like in it using the BIO_get_data() and
BIO_set_data() functions.

For example:

typedef struct {
    int num;
} XYZ_PRIVATE_DATA;

static int XYZ_mem_new(BIO *bio)
{
    XYZ_PRIVATE_DATA *data = OPENSSL_zalloc(sizeof(*data));

    if (data == NULL)
        return 0;

    /* Store whatever you like in num */
    data->num = 5;
    BIO_set_data(bio, data);
}

static int XYZ_mem_free(BIO *bio)
{
    XYZ_PRIVATE_DATA *data = BIO_get_data(bio);

    OPENSSL_free(data);
    BIO_set_data(bio, NULL);
}

static int XYZ_mem_read(BIO *bio, char *out, int outl)
{
    XYZ_PRIVATE_DATA *data = BIO_get_data(bio);

    /* Do the read operation and use data->num as required */
}


Matt

>
>
> Regards,
>
> Sunil
>
> *From:*openssl-users <[hidden email]> *On Behalf Of
> *[hidden email]
> *Sent:* 20 November 2020 23:34
> *To:* [hidden email]
> *Subject:* openssl-users Digest, Vol 72, Issue 19
>
>  
>
> ------------------------------------------------------------------------
>
> NOTICE: This email was received from an EXTERNAL sender
>
> ------------------------------------------------------------------------
>
>
> Send openssl-users mailing list submissions to
> [hidden email] <mailto:[hidden email]>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> [hidden email] <mailto:[hidden email]>
>
> You can reach the person managing the list at
> [hidden email] <mailto:[hidden email]>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
> 1. set/get utilities are not available to access variable
> 'num' of structure bio_st (Narayana, Sunil Kumar)
> 2. Re: set/get utilities are not available to access variable
> 'num' of structure bio_st (Matt Caswell)
> 3. EC curve preferences (Skip Carter)
> 4. RE: EC curve preferences (Michael Wojcik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 20 Nov 2020 13:46:00 +0000
> From: "Narayana, Sunil Kumar" <[hidden email]
> <mailto:[hidden email]>>
> To: "[hidden email] <mailto:[hidden email]>"
> <[hidden email] <mailto:[hidden email]>>
> Subject: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID:
> <[hidden email]
> <mailto:[hidden email]>>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi ,
> We are porting our Application from openssl 1.0.1 to openssl 3.0. In
> related to this activity we require to access the variable 'num' of
> structure bio_st.
> In older versions the variable was accessed to set and get value using
> pointer operator (bi->num ).
> Since this is not allowed in 3.0 we are looking for the Get/Set
> utilities similar to other member (BIO_set_flags/ BIO_get_flags)
>
> Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.
>
> Regards,
> Sunil
>
>
> -----------------------------------------------------------------------------------------------------------------------
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that
> is confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is
> strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all
> copies, including any attachments.
> -----------------------------------------------------------------------------------------------------------------------
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/f84c547a/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Nov 2020 13:55:34 +0000
> From: Matt Caswell <[hidden email] <mailto:[hidden email]>>
> To: [hidden email] <mailto:[hidden email]>
> Subject: Re: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID: <[hidden email]
> <mailto:[hidden email]>>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 20/11/2020 13:46, Narayana, Sunil Kumar wrote:
>> Hi ,
>>
>> ??????????????? We are porting our Application from ?openssl 1.0.1 to
>> openssl 3.0. In related to this activity we require to access the
>> variable ?*num*? of structure *bio_st. *
>>
>> In older versions the variable was accessed to set and get value using
>> pointer operator (bi->num ).
>>
>> Since this is not allowed in 3.0 we are looking for the Get/Set
>> utilities similar to other member*(BIO_set_flags/ BIO_get_flags) *
>>
>> ?
>>
>> Is this not supported in 3.0 ? If yes, Please guide the proper
> alternatives.
>
> What kind of BIO are you using? Different BIOs may provide different
> mechanisms to get hold of this value. For example a number of file
> descriptor based BIOs provide BIO_get_fd().
>
> Matt
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Nov 2020 08:43:59 -0800
> From: Skip Carter <[hidden email] <mailto:[hidden email]>>
> To: OpenSSL Users <[hidden email]
> <mailto:[hidden email]>>
> Subject: EC curve preferences
> Message-ID: <[hidden email]
> <mailto:[hidden email]>>
> Content-Type: text/plain; charset="utf-8"
>
>
> I am sure this in the documentation somewhere; but where ?
>
> What are the preferred ECDH curves for a given keysize ? Which curves
> are considered obsolete/deprecated/untrustworthy ?
>
>
> --
> Dr Everett (Skip) Carter??0xF29BF36844FB7922
> [hidden email] <mailto:[hidden email]>
>
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 831-641-0645 x103
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 659 bytes
> Desc: This is a digitally signed message part
> URL:
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/b8a90ad9/attachment-0001.sig>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 20 Nov 2020 18:03:22 +0000
> From: Michael Wojcik <[hidden email]
> <mailto:[hidden email]>>
> To: Skip Carter <[hidden email] <mailto:[hidden email]>>, OpenSSL Users
> <[hidden email] <mailto:[hidden email]>>
> Subject: RE: EC curve preferences
> Message-ID:
> <[hidden email]
> <mailto:[hidden email]>>
>
> Content-Type: text/plain; charset="utf-8"
>
>> From: openssl-users <[hidden email]
> <mailto:[hidden email]>> On Behalf Of Skip
>> Carter
>> Sent: Friday, 20 November, 2020 09:44
>>
>> What are the preferred ECDH curves for a given keysize ? Which curves
>> are considered obsolete/deprecated/untrustworthy ?
>
> For TLSv1.3, this is easy. RFC 8446 B.3.1.4 only allows the following:
> secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D),
> x448(0x001E). Those are your choices. If you want interoperability,
> enable them all; if you want maximum security, only use X25519 and X448.
> See safecurves.cr.yp.to for the arguments in favor of the latter position.
>
> Frankly, unless you're dealing with something of very high value or that
> needs to resist breaking for a long time, I don't see any real-world
> risk in using the SEC 2 curves. You might want to disallow just
> secp256r1 if you're concerned about that key size becoming tractable
> under new attacks or quantum computing within your threat timeframe.
> Ultimately, this is a question for your threat model.
>
>
> For TLSv1.2, well...
>
> - Some people recommend avoiding non-prime curves (i.e. over binary
> fields, such as the sect* ones) for intellectual-property reasons. I'm
> not going to try to get into that, because IANAL and even if I were, I
> wouldn't touch that without a hefty retainer.
>
> - Current consensus, more or less, seems to be to use named curves and
> not custom ones. The arguments for that seem pretty persuasive to me. So
> don't use custom curves.
>
> - Beyond that? Well, here's one Stack Exchange response from Thomas
> Pornin (who knows a hell of a lot more about this stuff than I do) where
> he suggests using just prime256v1 (which is the same as secp256r1 I
> believe?) and secp384r1:
>
> https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use
>
> Those are the curves in Suite B, before the NSA decided to emit vague
> warnings about ECC. They subsequently decided P384 aka secp384r1 is OK
> until post-quantum primitives are standardized. So if your application
> prefers secp384r1 for TLSv1.2, then you can decide whether to also allow
> prime256v1 for interoperability. Again, that's a question for your
> threat model.
>
> All that said, some people will have different, and quite possibly
> better-informed, opinions on this.
>
> --
> Michael Wojcik
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> [hidden email] <mailto:[hidden email]>
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 72, Issue 19
> *********************************************
>
Reply | Threaded
Open this post in threaded view
|

RE: set/get utilities are not available to access variable 'num' of structure bio_st (Matt Caswell)

Narayana, Sunil Kumar

Hi Matt,

                Thanks for the reply.. we would implement as you suggested.

 

 

From: Matt Caswell <[hidden email]>
Sent: 23 November 2020 17:12
To: Narayana, Sunil Kumar <[hidden email]>; [hidden email]
Subject: Re: set/get utilities are not available to access variable 'num' of structure bio_st (Matt Caswell)

 


NOTICE: This email was received from an EXTERNAL sender





On 23/11/2020 11:28, Narayana, Sunil Kumar wrote:
> Hi Matt,
>                We are using  MEM type BIO. similar to the openssl
> library ‘BIO_TYPE_MEM ‘ we have an internal type defined like ex:-
> ‘BIO_TYPE_XYZ_MEM’  and all other mem utilities are internally defined.
>
> Like XYZ_mem_new/XYZ_mem_read … etc  these utilities are accessing the
> bio_st variable ‘*num’*.
>
> please suggest set/get utilities to handle this scenario.

If I understand correctly you want to store an "int" value internally to
a custom BIO.

Custom BIOs can associate an arbitrary data structure with the BIO
object and store whatever they like in it using the BIO_get_data() and
BIO_set_data() functions.

For example:

typedef struct {
int num;
} XYZ_PRIVATE_DATA;

static int XYZ_mem_new(BIO *bio)
{
XYZ_PRIVATE_DATA *data = OPENSSL_zalloc(sizeof(*data));

if (data == NULL)
return 0;

/* Store whatever you like in num */
data->num = 5;
BIO_set_data(bio, data);
}

static int XYZ_mem_free(BIO *bio)
{
XYZ_PRIVATE_DATA *data = BIO_get_data(bio);

OPENSSL_free(data);
BIO_set_data(bio, NULL);
}

static int XYZ_mem_read(BIO *bio, char *out, int outl)
{
XYZ_PRIVATE_DATA *data = BIO_get_data(bio);

/* Do the read operation and use data->num as required */
}


Matt

>
>
> Regards,
>
> Sunil
>
> *From:*openssl-users <[hidden email]> *On Behalf Of
> [hidden email]
> *Sent:* 20 November 2020 23:34
> *To:* [hidden email]
> *Subject:* openssl-users Digest, Vol 72, Issue 19
>
>  
>
> ------------------------------------------------------------------------
>
> NOTICE: This email was received from an EXTERNAL sender
>
> ------------------------------------------------------------------------
>
>
> Send openssl-users mailing list submissions to
> [hidden email] <[hidden email]>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> [hidden email] <[hidden email]>
>
> You can reach the person managing the list at
> [hidden email] <[hidden email]>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
> 1. set/get utilities are not available to access variable
> 'num' of structure bio_st (Narayana, Sunil Kumar)
> 2. Re: set/get utilities are not available to access variable
> 'num' of structure bio_st (Matt Caswell)
> 3. EC curve preferences (Skip Carter)
> 4. RE: EC curve preferences (Michael Wojcik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 20 Nov 2020 13:46:00 +0000
> From: "Narayana, Sunil Kumar" <[hidden email]> <[hidden email]>>
> To: "[hidden email]"
> <[hidden email]>>
> Subject: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID:
> <[hidden email]> <[hidden email]>>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi ,
> We are porting our Application from openssl 1.0.1 to openssl 3.0. In
> related to this activity we require to access the variable 'num' of
> structure bio_st.
> In older versions the variable was accessed to set and get value using
> pointer operator (bi->num ).
> Since this is not allowed in 3.0 we are looking for the Get/Set
> utilities similar to other member (BIO_set_flags/ BIO_get_flags)
>
> Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.
>
> Regards,
> Sunil
>
>
> -----------------------------------------------------------------------------------------------------------------------
> Notice: This e-mail together with any attachments may contain
> information of Ribbon Communications Inc. that
> is confidential and/or proprietary for the sole use of the intended
> recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is
> strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all
> copies, including any attachments.
> -----------------------------------------------------------------------------------------------------------------------
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/f84c547a/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Nov 2020 13:55:34 +0000
> From: Matt Caswell <[hidden email]>>
> To: [hidden email] <[hidden email]>
> Subject: Re: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID: <[hidden email]> <[hidden email]>>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 20/11/2020 13:46, Narayana, Sunil Kumar wrote:
>> Hi ,
>>
>> ??????????????? We are porting our Application from ?openssl 1.0.1 to
>> openssl 3.0. In related to this activity we require to access the
>> variable ?*num*? of structure *bio_st. *
>>
>> In older versions the variable was accessed to set and get value using
>> pointer operator (bi->num ).
>>
>> Since this is not allowed in 3.0 we are looking for the Get/Set
>> utilities similar to other member*(BIO_set_flags/ BIO_get_flags) *
>>
>> ?
>>
>> Is this not supported in 3.0 ? If yes, Please guide the proper
> alternatives.
>
> What kind of BIO are you using? Different BIOs may provide different
> mechanisms to get hold of this value. For example a number of file
> descriptor based BIOs provide BIO_get_fd().
>
> Matt
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Nov 2020 08:43:59 -0800
> From: Skip Carter <[hidden email]>>
> To: OpenSSL Users <[hidden email]> <[hidden email]>>
> Subject: EC curve preferences
> Message-ID: <[hidden email]> <[hidden email]>>
> Content-Type: text/plain; charset="utf-8"
>
>
> I am sure this in the documentation somewhere; but where ?
>
> What are the preferred ECDH curves for a given keysize ? Which curves
> are considered obsolete/deprecated/untrustworthy ?
>
>
> --
> Dr Everett (Skip) Carter??0xF29BF36844FB7922
> [hidden email] <[hidden email]>
>
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 831-641-0645 x103
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 659 bytes
> Desc: This is a digitally signed message part
> URL:
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/b8a90ad9/attachment-0001.sig>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 20 Nov 2020 18:03:22 +0000
> From: Michael Wojcik <[hidden email]> <[hidden email]>>
> To: Skip Carter <[hidden email]>>, OpenSSL Users
> <[hidden email]>>
> Subject: RE: EC curve preferences
> Message-ID:
> <[hidden email]> <[hidden email]>>
>
> Content-Type: text/plain; charset="utf-8"
>
>> From: openssl-users <[hidden email]> <[hidden email]>> On Behalf Of Skip
>> Carter
>> Sent: Friday, 20 November, 2020 09:44
>>
>> What are the preferred ECDH curves for a given keysize ? Which curves
>> are considered obsolete/deprecated/untrustworthy ?
>
> For TLSv1.3, this is easy. RFC 8446 B.3.1.4 only allows the following:
> secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D),
> x448(0x001E). Those are your choices. If you want interoperability,
> enable them all; if you want maximum security, only use X25519 and X448.
> See safecurves.cr.yp.to for the arguments in favor of the latter position.
>
> Frankly, unless you're dealing with something of very high value or that
> needs to resist breaking for a long time, I don't see any real-world
> risk in using the SEC 2 curves. You might want to disallow just
> secp256r1 if you're concerned about that key size becoming tractable
> under new attacks or quantum computing within your threat timeframe.
> Ultimately, this is a question for your threat model.
>
>
> For TLSv1.2, well...
>
> - Some people recommend avoiding non-prime curves (i.e. over binary
> fields, such as the sect* ones) for intellectual-property reasons. I'm
> not going to try to get into that, because IANAL and even if I were, I
> wouldn't touch that without a hefty retainer.
>
> - Current consensus, more or less, seems to be to use named curves and
> not custom ones. The arguments for that seem pretty persuasive to me. So
> don't use custom curves.
>
> - Beyond that? Well, here's one Stack Exchange response from Thomas
> Pornin (who knows a hell of a lot more about this stuff than I do) where
> he suggests using just prime256v1 (which is the same as secp256r1 I
> believe?) and secp384r1:
>
> https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use
>
> Those are the curves in Suite B, before the NSA decided to emit vague
> warnings about ECC. They subsequently decided P384 aka secp384r1 is OK
> until post-quantum primitives are standardized. So if your application
> prefers secp384r1 for TLSv1.2, then you can decide whether to also allow
> prime256v1 for interoperability. Again, that's a question for your
> threat model.
>
> All that said, some people will have different, and quite possibly
> better-informed, opinions on this.
>
> --
> Michael Wojcik
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> [hidden email] <[hidden email]>
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 72, Issue 19
> *********************************************
>




Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.