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 non-compati

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

Hi everybody, on the [openssl-dev] mailing list, there has been a long ongoing discussion about the new RAND_DRBG API and comparing it with the old RAND_METHOD API (see "[openssl-dev] Work on a new RNG for OpenSSL"). Two of the most controversal questions were: - Do we really need a new RNG A

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 > > randomn

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

> If I understand correctly, the RAND_DRBG API is really a completely > separate API that has nothing to do with the RAND_METHOD API pers se, > i.e. any association between the two is more or less "accidental"? Yes, you're right. The original DRBG API was implemented for the FIPS object module (

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 give

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

> In message on Tue, 29 Aug > 2017 13:27:20 +, "Dr. > Matthias St. Pierre" said: > > Matthias.St.Pierre> > Essentially, the argument for your last remark is > in-structure vtable > Matthias.St.Pierre> > vs refered to vtable. I tend to prefer the

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

Hi Rich, > I think the only way to do that in the DRBG model is to treat it as > “additional input” and do a generate > call. I think that would achieve the same effect, but it wouldn’t delay any > possible seeding of randomness > that the DRBG itself needs at some point. You're right, well, al

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 pro

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

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

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

> -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 > > ... > >

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

> > The 'RAND_add()/RAND_bytes()' pattern is broken > === > > In OpenSSL, the classical way for the RNG consumer to add his own randomness > is to call 'RAND_add()' before > calling 'RAND_bytes()'. If the new 'RAND_OpenSSL()' method (the > "compatibili

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 fo

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 > discussion, while

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 on

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

From: "Dr. Matthias St. Pierre" 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 . Instead, I followed the FAQ which sent me to the README file, and there was no mention of the request trac

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

[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 particular

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(); > forwa

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 prob

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 i

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] 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 a

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] [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 Be

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] Resolved: [PATCH] Export ASN1 templates for DH and ECDH groups

> According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message. Thanks a lot for finally adding the patch. Since our software is not ready for version 1.1 yet, I can't try it directly with the master, but I will backport

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:

[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' [-Wimpl

[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 insertions(+

[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

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

From: "Dr. Matthias St. Pierre" 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 #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 ch

[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 ---