<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1636254327;
        mso-list-type:hybrid;
        mso-list-template-ids:585520048 1189121756 1074331651 1074331653 1074331649 1074331651 1074331653 1074331649 1074331651 1074331653;}
@list l0:level1
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;
        mso-fareast-font-family:"Times New Roman";
        mso-bidi-font-family:Calibri;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-IN" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Matt,<br>
<span style="mso-fareast-language:EN-US">               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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Like XYZ_mem_new/XYZ_mem_read … etc  these utilities are accessing the bio_st variable ‘<b>num’</b>.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">please suggest set/get utilities to handle this scenario.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><br>
Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Sunil<o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> openssl-users <openssl-users-bounces@openssl.org>
<b>On Behalf Of </b>openssl-users-request@openssl.org<br>
<b>Sent:</b> 20 November 2020 23:34<br>
<b>To:</b> openssl-users@openssl.org<br>
<b>Subject:</b> openssl-users Digest, Vol 72, Issue 19<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<p class="MsoNormal">NOTICE: This email was received from an EXTERNAL sender<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<p class="MsoNormal"><br>
Send openssl-users mailing list submissions to<br>
<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-users">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openssl-users-request@openssl.org">openssl-users-request@openssl.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openssl-users-owner@openssl.org">openssl-users-owner@openssl.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of openssl-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. set/get utilities are not available to access variable<br>
'num' of structure bio_st (Narayana, Sunil Kumar)<br>
2. Re: set/get utilities are not available to access variable<br>
'num' of structure bio_st (Matt Caswell)<br>
3. EC curve preferences (Skip Carter)<br>
4. RE: EC curve preferences (Michael Wojcik)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 20 Nov 2020 13:46:00 +0000<br>
From: "Narayana, Sunil Kumar" <<a href="mailto:sanarayana@rbbn.com">sanarayana@rbbn.com</a>><br>
To: "<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a>" <<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a>><br>
Subject: set/get utilities are not available to access variable<br>
'num' of structure bio_st<br>
Message-ID:<br>
<<a href="mailto:SN6PR03MB4061A9FF473DE74B064A1D8DB0FF0@SN6PR03MB4061.namprd03.prod.outlook.com">SN6PR03MB4061A9FF473DE74B064A1D8DB0FF0@SN6PR03MB4061.namprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi ,<br>
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.<br>
In older versions the variable was accessed to set and get value using pointer operator (bi->num ).<br>
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)<br>
<br>
Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.<br>
<br>
Regards,<br>
Sunil<br>
<br>
<br>
-----------------------------------------------------------------------------------------------------------------------<br>
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that<br>
is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or<br>
distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended<br>
recipient, please notify the sender immediately and then delete all copies, including any attachments.<br>
-----------------------------------------------------------------------------------------------------------------------<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/f84c547a/attachment-0001.html">https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/f84c547a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 20 Nov 2020 13:55:34 +0000<br>
From: Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>><br>
To: <a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
Subject: Re: set/get utilities are not available to access variable<br>
'num' of structure bio_st<br>
Message-ID: <<a href="mailto:53108b39-21f8-dea0-c3c3-fe5517a5613f@openssl.org">53108b39-21f8-dea0-c3c3-fe5517a5613f@openssl.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
<br>
On 20/11/2020 13:46, Narayana, Sunil Kumar wrote:<br>
> Hi ,<br>
> <br>
> ??????????????? We are porting our Application from ?openssl 1.0.1 to<br>
> openssl 3.0. In related to this activity we require to access the<br>
> variable ?*num*? of structure *bio_st. *<br>
> <br>
> In older versions the variable was accessed to set and get value using<br>
> pointer operator (bi->num ).<br>
> <br>
> Since this is not allowed in 3.0 we are looking for the Get/Set<br>
> utilities similar to other member*(BIO_set_flags/ BIO_get_flags) *<br>
> <br>
> ?<br>
> <br>
> Is this not supported in 3.0 ? If yes, Please guide the proper alternatives.<br>
<br>
What kind of BIO are you using? Different BIOs may provide different<br>
mechanisms to get hold of this value. For example a number of file<br>
descriptor based BIOs provide BIO_get_fd().<br>
<br>
Matt<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 20 Nov 2020 08:43:59 -0800<br>
From: Skip Carter <<a href="mailto:skip@taygeta.com">skip@taygeta.com</a>><br>
To: OpenSSL Users <<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a>><br>
Subject: EC curve preferences<br>
Message-ID: <<a href="mailto:1605890639.1675.24.camel@taygeta.com">1605890639.1675.24.camel@taygeta.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
I am sure this in the documentation somewhere; but where ?<br>
<br>
What are the preferred ECDH curves for a given keysize ? Which curves<br>
are considered obsolete/deprecated/untrustworthy ?<br>
<br>
<br>
-- <br>
Dr Everett (Skip) Carter??0xF29BF36844FB7922<br>
<a href="mailto:skip@taygeta.com">skip@taygeta.com</a><br>
<br>
Taygeta Scientific Inc<br>
607 Charles Ave<br>
Seaside CA 93955<br>
831-641-0645 x103<br>
<br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 659 bytes<br>
Desc: This is a digitally signed message part<br>
URL: <<a href="https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/b8a90ad9/attachment-0001.sig">https://mta.openssl.org/pipermail/openssl-users/attachments/20201120/b8a90ad9/attachment-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 20 Nov 2020 18:03:22 +0000<br>
From: Michael Wojcik <<a href="mailto:Michael.Wojcik@microfocus.com">Michael.Wojcik@microfocus.com</a>><br>
To: Skip Carter <<a href="mailto:skip@taygeta.com">skip@taygeta.com</a>>, OpenSSL Users<br>
<<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a>><br>
Subject: RE: EC curve preferences<br>
Message-ID:<br>
<<a href="mailto:DM6PR18MB2700D392831EA5CD3EF318D5F9FF0@DM6PR18MB2700.namprd18.prod.outlook.com">DM6PR18MB2700D392831EA5CD3EF318D5F9FF0@DM6PR18MB2700.namprd18.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
> From: openssl-users <<a href="mailto:openssl-users-bounces@openssl.org">openssl-users-bounces@openssl.org</a>> On Behalf Of Skip<br>
> Carter<br>
> Sent: Friday, 20 November, 2020 09:44<br>
><br>
> What are the preferred ECDH curves for a given keysize ? Which curves<br>
> are considered obsolete/deprecated/untrustworthy ?<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
For TLSv1.2, well...<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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:<br>
<br>
<a href="https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use">https://security.stackexchange.com/questions/78621/which-elliptic-curve-should-i-use</a><br>
<br>
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.<br>
<br>
All that said, some people will have different, and quite possibly better-informed, opinions on this.<br>
<br>
--<br>
Michael Wojcik<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
openssl-users mailing list<br>
<a href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-users">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of openssl-users Digest, Vol 72, Issue 19<br>
*********************************************<o:p></o:p></p>
</div>
</body>
</html>