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 <openssl-users-bounces@xxxxxxxxxxx> *On Behalf Of
> *openssl-users-request@xxxxxxxxxxx
> *Sent:* 20 November 2020 23:34
> *To:* openssl-users@xxxxxxxxxxx
> *Subject:* openssl-users Digest, Vol 72, Issue 19
>
>
>
> ------------------------------------------------------------------------
>
> NOTICE: This email was received from an EXTERNAL sender
>
> ------------------------------------------------------------------------
>
>
> Send openssl-users mailing list submissions to
> openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
>
> 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
> openssl-users-request@xxxxxxxxxxx <mailto:openssl-users-request@xxxxxxxxxxx>
>
> You can reach the person managing the list at
> openssl-users-owner@xxxxxxxxxxx <mailto:openssl-users-owner@xxxxxxxxxxx>
>
> 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" <sanarayana@xxxxxxxx
> <mailto:sanarayana@xxxxxxxx>>
> To: "openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>"
> <openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>>
> Subject: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID:
> <SN6PR03MB4061A9FF473DE74B064A1D8DB0FF0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:SN6PR03MB4061A9FF473DE74B064A1D8DB0FF0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>>
>
> 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 <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>
> To: openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> Subject: Re: set/get utilities are not available to access variable
> 'num' of structure bio_st
> Message-ID: <53108b39-21f8-dea0-c3c3-fe5517a5613f@xxxxxxxxxxx
> <mailto:53108b39-21f8-dea0-c3c3-fe5517a5613f@xxxxxxxxxxx>>
> 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 <skip@xxxxxxxxxxx <mailto:skip@xxxxxxxxxxx>>
> To: OpenSSL Users <openssl-users@xxxxxxxxxxx
> <mailto:openssl-users@xxxxxxxxxxx>>
> Subject: EC curve preferences
> Message-ID: <1605890639.1675.24.camel@xxxxxxxxxxx
> <mailto:1605890639.1675.24.camel@xxxxxxxxxxx>>
> 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
> skip@xxxxxxxxxxx <mailto:skip@xxxxxxxxxxx>
>
> 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 <Michael.Wojcik@xxxxxxxxxxxxxx
> <mailto:Michael.Wojcik@xxxxxxxxxxxxxx>>
> To: Skip Carter <skip@xxxxxxxxxxx <mailto:skip@xxxxxxxxxxx>>, OpenSSL Users
> <openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>>
> Subject: RE: EC curve preferences
> Message-ID:
> <DM6PR18MB2700D392831EA5CD3EF318D5F9FF0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:DM6PR18MB2700D392831EA5CD3EF318D5F9FF0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>>
>
> Content-Type: text/plain; charset="utf-8"
>
>> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx
> <mailto:openssl-users-bounces@xxxxxxxxxxx>> 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
> openssl-users@xxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxx>
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 72, Issue 19
> *********************************************
>
