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

On 8/29/17, 15:22, "openssl-dev on behalf of Salz, Rich via openssl-dev" wrote: ➢ I’d like to suggest that any approach other than “immediately mix the received randomness into the RNG state” is bad. If a user does

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

On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev" wrote: ➢ An other problem with the current implemenation is that the ➢ randomness parameter that's now given to RAND_add() is just ➢

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

IMHO this interface is a way for the user to improve the quality of the randomness it would get from the given RNG, *not* to replace (or diminish) its other sources. My proposal is to abolish this parameter, especially since now it is simply ignored (and IMHO – for a good reason). That's a

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

uri> Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? Are you talking about the UI API or something else? No-no-no, just the UI API. I used the term “UI” to emphasize that this is the “public” part of the API, exposed to the

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

> If, based on its value, OpenSSL may decide that it now got “enough” entropy > and doesn’t need to > pull more from other sources before serving randomness to requestors – then > it is harmful. > “Over-confidence” in this value by the caller can negatively impact the > quality of the produced

[openssl-dev] Bug in pkey_rsa_encrypt() and _decrypt()

Working on pkcs11 engine, I discovered a bug in crypto/rsa/rsa_pmeth.c in pkey_rsa_encrypt() and pkey_rsa_decrypt(). They cause a crash when called with out==NULL. Normally it should not happen – but when an engine is called, and it cannot process the padding – it reverts to the original

Re: [openssl-dev] Bug in pkey_rsa_encrypt() and _decrypt()

> Working on pkcs11 engine, I discovered a bug in crypto/rsa/rsa_pmeth.c in pkey_rsa_encrypt() and pkey_rsa_decrypt(). > > They cause a crash when called with out==NULL. Normally it should not happen > but when an engine is called, and it cannot process the padding it reverts

[openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

gt; wrote: On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote: Apologies in advance for cross-posting ??? but I???m not sure which of the two mailing lists this belongs to. A key (say, private key) is loaded from the pkcs11 engine via privkey = ENGINE_load_private_key(engine, );

Re: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

sl.org> wrote: On Mon, Oct 02, 2017, Matt Caswell wrote: > > > On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote: > > Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix. > > > > > > > > To be more s

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

>So I guess you want an interface that can both add things to the > "entropy" pool, and to the "additional data" pool? It shouldn't >be that hard, I'll try to come up with some proposal soon. I’d say the interface that Rich Salz proposed would be good enough: > … But I think a new

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

On 8/24/17, 09:45, "openssl-dev on behalf of Steffen Nurpmeso" wrote: >> … But I think a new API, >> RAND_add_ex() that took a flag >> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, >> RAND_LOCAL_PRIVATE

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

>>I personally see no harm if these RNG objects are made available to >> applications that need/use them > > But decisions like this live forever. It is therefore VERY important to > spend time thinking about what > becomes part of the public API and what remains hidden so that we can

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

>> Even opaque objects usually have some public interface. I think exposing >> RAND_add_ex() >> would be a good idea for 1.1..1, and it’s likely to serve as an acceptable >> “live forever” API. > > That’s my point. API decisions live forever. Point well taken. Nonetheless… > Suppose we

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

My offhand knee-jerk reaction would be that if you have a CPU compromised to that extent - the battle has been lost with no reason to continue. Going into more details, I checked that post, and disagree with the author (and I'm in a good company, as Linus seems to hold the same opinion).

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

Forgot to add that the adversary would have to compromise not only Intel but also AMD CPUs. Not sure about ARM - but if it implements RDRAND then it must be compromised too, otherwise the enemy victory wouldn be incomplete. ;-) And think of the chips powering mobile devices... Regards, Uri

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

>> P.S. I wonder if it's feasible to have a configuration parameter that would >> allow me to tell the TLS code to invoke RAND_add_ex() before generating >> session keys? > > Either you accept that NIST SP 90A is right, or you just bypass it > completely. We’re in the first camp.

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

>I at least have a plan to add additional data, but probably not in >the current idea was probably not the way you would like to see it. :-) >My idea was to query at least various sources that we don't >attribute any entropy to, like getpid(), gettimeofday(), >

Re: [openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

Fix confirmed, thank you! Regards, Uri Sent from my iPhone > On Sep 4, 2017, at 10:25, Matt Caswell <m...@openssl.org> wrote: > > > >> On 04/09/17 08:59, Matt Caswell wrote: >> >> >>> On 03/09/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote: &

[openssl-dev] Fwd: openssl 1-1-0-stable fails

Begin forwarded > Subject: openssl 1-1-0-stable fails > > OpenSSL_1_1_0-stable current Github > > Test Summary Report > --- > ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=95, Tests=561, 165

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

On Sep 1, 2017, at 18:48, Matt Caswell wrote: >>> *Subject:* *openssl 1-1-0-stable fails* >>> >>> OpenSSL_1_1_0-stable current Github >>> >>> Test Summary Report >>> --- >>> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1) >>> Failed

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

On 8/30/17, 00:59, "openssl-dev on behalf of Paul Dale" wrote: >My thoughts are that the new RNG API should be made public once it has >been properly designed. We've a chance to get this right, let's take the > time >

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

>> I *don’t want* OpenSSL to make *any* estimation of the amount of provided >> entropy. All I want it to do is to mix these bits into the RNG state. It’s >> *my* business how much entropy I’m providing – but I don’t want OpenSSL to >> make any decision regarding pull from other entropy sources

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

>> I would do exactly the opposite. “Normal” entropy is fetched from the default sources (/dev/urandom). But >> when a sensitive (aka long-term) keys are generated, a (portable :) hardware RNG is plugged in and used with >> RAND_add() equivalent. Reason – in my setup reliable trusted

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

All my builds include "make distclean" at the start of the process. However when I repeated that cleanup and re-run the build, 1_1_0-stable error disappeared. A fluke?! Regards, Uri Sent from my iPhone > On Sep 1, 2017, at 21:10, Blumenthal, Uri - 0553 - MITLL <u...@ll.m

[openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

able-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade make depend && make clean && make -j 2 all && make test && make install > On Sep 2, 2017, at 21:15, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit

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

I like this PR. Thank you! > On Sep 3, 2017, at 17:53, 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

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

Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? NIST 90Ar1 seems specific enough on what functionality DRBG can provide to users, and it doesn't seem like a very elaborate or rich interface. Why would it change, regardless of what you may

Re: [openssl-dev] Certificate Limitation Profile

I'm wondering how you think that policy will be distributed and why it needs signed. … For instance it might come as part of some software distribution (like a browser), and either you trust all the files in that distribution or you don't. I agree that an unsigned variant of CLP makes sense.

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

I think being able to interoperate with IoT devices using SPECK is a good idea. I'd like to know what kind of key exchange is likely to be used there. Regards, Uri Sent from my iPhone > On Jan 9, 2018, at 04:58, Richard Levitte wrote: > > I'm not terribly savvy regarding

Re: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type deviation from spec

I think the change is justified. — Regards, Uri > On Jan 16, 2018, at 14:31, Sands, Daniel wrote: > > On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote: >> OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE >> OF. Ouch! Will that cause

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

On 1/19/18, 12:52, "Salz, Rich" wrote: >> It appears to me that you could use openssl-dev instead of openssl-project, >> saving cycles on killing >> one and creating the other. > > We discussed that, but it would be harder to “undo” if things don’t work > out, we wanted >

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

It appears to me that you could use openssl-dev instead of openssl-project, saving cycles on killing one and creating the other. -- Regards, Uri Blumenthal On 1/19/18, 12:35, "openssl-dev on behalf of Salz, Rich via openssl-dev"

Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found

If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. - Original Message - From: Rich Salz via RT [mailto:r...@openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tsh...@akamai.com

Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found

Todd, I agree. Have the warning only where it matters (but have it there). From: Short, Todd [mailto:tsh...@akamai.com] Sent: Thursday, May 28, 2015 08:25 AM To: Blumenthal, Uri - 0553 - MITLL Cc: r...@openssl.org r...@openssl.org; openssl-dev@openssl.org openssl-dev@openssl.org Subject: Re

Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely to be used. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: David Woodhouse via RT Sent: Friday, August 7,

Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL wrote: Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

>> What other implementations, and what did they do? Always treating a CN as a >> DNS name? We can't. > > As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there > is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress > syntactically. That approach seems

Re: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine

Doug, could you please take a look at PR #548 (or is it #549)? It also addresses this KEY_FORM issue. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: deeng...@gmail.com via RT Sent: Friday, January 15, 2016 17:10 Reply To: r...@openssl.org

Re: [openssl-dev] [openssl.org #4246] OpenSSL-1.1-pre2 openssl req fails to use engine

t;OpenSC engine. Are we talking about Michael? BTW, on a separate issue - I’m rather concerned about the apparent circular dependency between OpenSSL and OpenSC. This makes it problematic to use OpenSC with another software library like Botan or Crypto++. But that’s for a different message thread

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Henson via RT; bcri...@gmail.com Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails toparse x509 certificate in DER format‎ On Thu, Feb 11, 2016 at 10:53:25PM +, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right thing in this case wo

Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? Clearly the device manufacturer is at fault here, but the punished party is the user - probably not what

<    1   2   3