[openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

From: Dr. Matthias St. Pierre m...@ncp-e.com Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

Hello, On 01/28/2015 12:52 AM, Matt Caswell wrote: Please submit patches to r...@openssl.org. Sorry about that, I will repost it. I overlooked https://www.openssl.org/support/rt.html. Instead, I followed the FAQ which sent me to the README file, and there was no mention of the request

Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups

On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote: On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS

[openssl-dev] Comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs

Hello, first of all, I'd like to say that I agree with the core developers that it's a good idea to make all these OpenSSL structs opaque and provide an API for creation/desruction and member access instead. I have two comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs in

Re: [openssl-dev] [openssl.org #3920] ECDSA_METHOD_new() argument should be constified?

On 06/22/2015 09:17 PM, Dmitry Belyavsky via RT wrote: Hello all, I try to provide my own ECDSA method using engine. I want to use common functions for verifying the signature and a custom one for signing. My code is ... const ECDSA_METHOD * meth1 = ECDSA_OpenSSL();

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

Am 14.08.2015 um 16:22 schrieb Jan Ehrhardt: I guess there was a change from optional (in VC9/VC11) to required in VC14, but only for the 1.0.2 branch. The PHP devs were the first to notice and included applink.c in the VS2015/VC14 builds of PHP7. Apachelounge followed by including applink.c

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

Hello Jan, thank you for sharing your observations and your patch. I stumbled over it, because we are currently having a similar problem with our Windows builds producing these OPENSSL_Uplink/no OPENSSL_Applink errors. However, I'm in doubt whether your patch really fixes the cause of the

Re: [openssl-dev] Improving OpenSSL default RNG

On 10/24/2015 05:55 PM, Marcus Meissner wrote: > On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote: >> On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote: >> ... >> In general the NIST DRBGs seem fairly complicated (or completely >

Re: [openssl-dev] Improving OpenSSL default RNG

Hi, I have a related question concerning alternative RNGs, hope it is not too off-topic: Currently we are using the NIST-SP800-90a compliant DRBG (FIPS_drbg_method()), because it seemed to us to be more sophisticated and mature than the default RAND_SSLeay(). At least it's better documented

Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module

On 09/21/2015 12:01 AM, Jan Ehrhardt wrote: > Dr. Matthias St. Pierre in gmane.comp.encryption.openssl.devel (Sun, 16 > Aug 2015 23:52:21 +0200): >> >> Thank you once more for the detailed reply. I applied your patches >> provisorily before going on vacation last f

Re: [openssl-dev] 1.1 release being delayed

> > And as far as regressions after beta 2 release are concerned, it looks > > like there was a change in the API that is not backwards compatible. I > > was hoping this would not happen after the "Beta 2 - Opaque work > > complete". Did I misunderstand what that note means? > > > > The

Re: [openssl-dev] Work on a new RNG for OpenSSL

own choice if I need to. Regards, Matthias On 28.06.2017 16:46, Matt Caswell wrote: > > On 28/06/17 15:42, Matthias St. Pierre wrote: >> Hello Matt, >> >> I am not quite sure what your current favourite solution for the upcoming >> default OpenSSL random g

Re: [openssl-dev] Work on a new RNG for OpenSSL

RNG? It looks like you made two votes for the first and one vote for the second variant (see below). Could you please clarify your preference? Regards, Matthias St. Pierre Vote 1: On 27.06.2017 09:28, Matt Caswell wrote: > On 26/06/17 21:18, Kurt Roeckx wrote: >>> “Re

Re: [openssl-dev] Work on a new RNG for OpenSSL

hat it will be added to the OpenSSL master as officially supported RAND method? - Will the new OpenSSL RNG support a way to configure reseed intervals and external entropy sources in a similar fashion as the FIPS DRBG did? Best regards, Matthias St. Pierre [1] Section 6.1 of the Ope

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 27.06.2017 14:55, Salz, Rich via openssl-dev wrote: > That's three questions :) But yes, we should address that. I'm not sure if > new RAND API's are the way to go or perhaps a RAND_control API that gives us > a bit more flexibility. Ups, it used to be only two. That's always the problem

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> -Ursprüngliche Nachricht- > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von Matt > Caswell > Gesendet: Dienstag, 29. August 2017 16:36 > An: openssl-dev@openssl.org > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API > > > > On 29/08/17 15:02,

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> I realize that reseed() not only mixes my “additional input” but also > replaces the entire state. NIST does > not specify interface to “just” mix the “additional input” into the state > without replacing the whole state > with some fresh entropy by calling Get_entropy_input(). Maybe we can

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> -Ursprüngliche Nachricht- > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von > Blumenthal, Uri - 0553 - MITLL > Gesendet: Mittwoch, 30. August 2017 17:23 > An: openssl-dev@openssl.org > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API > > ... > >

[openssl-dev] Plea for a new public OpenSSL RNG API

HOD to RAND_DRBG could be deprecated and faded out smoothly. Looking forward to receiving your comments. (But please be patient with me, I'm currently on physical rehab after a surgery.) Matthias St. Pierre smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> On 29/08/17 10:45, Dr. Matthias St. Pierre wrote > > ... > > The 'RAND_add()/RAND_bytes()' pattern is broken > > === > > > > In OpenSSL, the classical way for the RNG consumer to add his own > > randomness is to

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> Essentially, the argument for your last remark is in-structure vtable > vs refered to vtable. I tend to prefer the latter (and that's the > usual OpenSSL pattern too, even though there are exceptions). You are the experts and much more familiar with the code then I am. My role was only to

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

> > We have a similar situation, on a small hardware device with little > own entropy > > but with a smartcard reader. > > Yes, but in most cases you cannot count on the smartcard (or smartcard-like > device) being in the reader. > Which is why in my opinion this is an ideal case for

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

citely > > *Note:* Currently it looks like the situation is even worse: if 'RAND_add()' > is called multiple times before > a reseed occurs, then the result of the previous call is overwritten. I just posted GitHub PR #4328 related to this issue [openssl/openssl] WIP: Fix the RAND_ad

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

On 24.01.2018 19:08, Viktor Dukhovni wrote: > > Well, but we now have "openssl-project" for discussions of the > ongoing development of OpenSSL. It is mostly for team members, > but though it is moderated, IIRC others can join and post. Ok, I didn't know that. If anyone seriously participating

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

On 24.01.2018 18:32, Viktor Dukhovni wrote: > >> On Jan 24, 2018, at 9:27 AM, Michael Richardson wrote: >> >>> email clients are designed to handle hundreds to thousands of messages >>> a day, Github UI isn't > Indeed email is best for informal ad-hoc back and forth threaded

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

On 23.01.2018 15:54, Hubert Kario wrote: > On Tuesday, 23 January 2018 15:36:26 CET Salz, Rich wrote: >> ➢ this feature sends notifications about _all_ conversations happening. >> >> For me, I get the actual comments that are posted. Don’t you? > when I comment in an issue/PR or mark it as

[openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). Signed-off-by: Dr. Matthias St. Pierre m

[openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

From: Dr. Matthias St. Pierre m...@ncp-e.com Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters

[openssl-dev] [openssl.org #3925] [PATCH] Removed trailing semicolon from macro body of three function-like macros

The trailing semicolon turned the macros into statements and prevented them from being used in arbitrary expressions. --- include/openssl/bio.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/openssl/bio.h b/include/openssl/bio.h index 7fe88ec..12f59ac 100644 ---

[openssl-dev] [openssl.org #3921] [PATCH] Fix const-correctness issues of new ECDSA_METHOD api

- The function ECDSA_METHOD_new() acts like a copy constructor, but unfortunately its argument is not declared const. This leads to compiler errors when it is used as follows: ECDSA_METHOD * method = ECDSA_METHOD_new(ECDSA_OpenSSL()); - The ECDSA_METHOD_set_name() should take a 'const

Re: [openssl-dev] [openssl.org #3676] Resolved: [PATCH] Export ASN1 templates for DH and ECDH groups

1_1_0 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH +DHparams_it1_1_0 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH Regards, Matthias St. Pierre -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3676 Please log in as guest with password guest if prompted -- openssl-dev

Re: [openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

> Von: Stephen Henson via RT [mailto:r...@openssl.org] > Gesendet: Samstag, 5. März 2016 17:53 > An: Dr. Matthias St. Pierre > Cc: openssl-dev@openssl.org > Betreff: [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH > groups > > ... > > The fact we

Re: [openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups

Is there any chance that this change will find it's way into OpenSSL 1.1 ? Regards, Matthias St. Pierre -Ursprüngliche Nachricht- Von: Rich Salz via RT [mailto:r...@openssl.org] Gesendet: Mittwoch, 2. März 2016 15:28 An: Dr. Matthias St. Pierre Cc: openssl-dev@openssl.org Betreff

Re: [openssl-dev] [openssl.org #3676] Resolved: [PATCH] Export ASN1 templates for DH and ECDH groups

> > The fact we don't export the DHparameters item I'd regard as a bug which > > should be fixed. Will the missing export for DHparameters still be fixed for 1.1? Matthias St. Pierre > -Ursprüngliche Nachricht----- > Von: Dr. Matthias St. Pierre via RT [mailto:r...@opens

[openssl-dev] [openssl.org #4685] [PATCH v2] Add missing prototype for FIPS callback

The call to FIPS_crypto_set_id_callback() was added in revision a43cfd7bb1fc681d563e, but there is no prototype for it in . --- Moved the function prototype upwards, because declarations can only be placed at the top of a function in C. crypto/o_init.c | 5 + 1 file changed, 5

[openssl-dev] [openssl.org #4685] [PATCH] Add missing prototype for FIPS callback

The call to FIPS_crypto_set_id_callback() was added in revision a43cfd7bb1fc681d563e, but there is no prototype for it in . --- This leads to warnings on some platforms (e.g. x86_64-ncp-linux-gnu-gcc): o_init.c:77:5: warning: implicit declaration of function 'FIPS_crypto_set_id_callback'