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

My thoughts. Randomness should be whitened. Anything feed into an randomness pool, should be mixed in and run through SHA256. pool = SHA256(pool || new-randomness) Pseudorandomness of the output has been a design goal/requirement only in SHA-3 family. An

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

> Pseudorandomness of the output has been a design goal/requirement only > in SHA-3 family. Any prior hash function’s exhibition of this property is > coincidental. > > Therefore I suggest using SHA3 instead. Is pseudorandomness a requirement? Or is it the "50% chance

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

Defence in depth seems prudent: independent sources with agglomeration and whitening. As Kurt noted, [on modern OSes,] it is really unclear what sources are available to us that are not already being used by the kernel. I would turn to hardware. Since OpenSSL already has assembly-level optim

Re: [openssl-dev] what's possible and what's not ... including RNGs

Knowledge of the platform is a required part of the OpenSSL configuration. If the platform supports HRNG (usually in the form of CPU instructions), use it: let OpenSSL mix its output with whatever other randomness sources it picks on that platform/system. IMHO that’s the best strategy. Thankful

[openssl-dev] Master: test fails

$ make distclean || true $ ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrademake depend && make clean && make -j 4 all && make test

Re: [openssl-dev] Master: test fails

Sure looks like that... Regards, Uri Sent from my iPhone > On Jul 22, 2017, at 14:41, Salz, Rich via openssl-dev > wrote: > > Wow that green is hard to read J > > So your config options change the tests for 70-test-tls13messages, but the > plan isn’t updated, right? > -- > openssl-dev mai

Re: [openssl-dev] Master: test fails

On Jul 23, 2017, at 09:17, Salz, Rich wrote: > > So what are your exact config options? Just the “./config” line. Simple: ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers enable-zlib-

Re: [openssl-dev] Master: test fails

CI does not seem to flag/manifest this error any more. -- Regards, Uri From: openssl-dev on behalf of Uri Blumenthal Reply-To: openssl-dev Date: Sunday, July 23, 201730 at 21:06 To: Rich Salz Cc: openssl-dev Subject: Re: [openssl-dev] Master: test fails On Jul 23, 2017, at 09:1

Re: [openssl-dev] Build issue

Instead of "make clean" try "make distclean", then reconfigure and rebuild (don't forget "make depend"). Regards, Uri Sent from my iPhone > On Jul 27, 2017, at 23:24, Matthew Stickney wrote: > >> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte wrote: >> Have you tried a 'make clean' and the

[openssl-dev] Current master fails to build

See https://github.com/openssl/openssl/issues/4080 First, ssl/s3_lib.c file misses “#include ” in the beginning. This prevents successful linking of libssl. After that is fixed, test 80-test_new_s

Re: [openssl-dev] Current master fails to build

On Aug 3, 2017, at 15:46, Salz, Rich via openssl-dev wrote: > >> After that is fixed, test 80-test_new_ssl.t fails (wstat 256, 0x100). > > Do you have core file? The failure is not repeatable, at least on my system > :( Alas, I don’t. But Travis CI fails this master 4 out of 14 jobs, see t

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

Thanks everyone for the discussion (mainly in June) about this. There’s a blog post describing what we’ve done for the 1.1.1 release: https://www.openssl.org/blog/blog/2017/08/12/random/ Nice. But some important things could be made clearer. We added a new configuration parameter, --with

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

>> 1. What’s the default if “with-rand-seed” was not provided? All of the >> listed supported types? None of them? Some of them…? > > As the first bullet says, it’s “os”. OK, thanks. > As for the second part of your question, it is deliberately not answered. > If you care, you’ll have

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

>>> Modify the source :) >> >>Very bad answer. > >And also a wrong one. Your application can always call RAND_add(). Sorry for mistake. And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Somethi

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

I have only one issue with the current design: the apparent absence of RAND_add() interface for the "private" RNG. I request that it is added (no pun intended, really :). Regards, Uri Sent from my iPhone > On Aug 17, 2017, at 09:18, Salz, Rich via openssl-dev > wrote: > > \ >> somewhere som

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

All the items discussed are important. But I’d like the development team to comment on (and ideally – accept) my request to add RAND_add() method to the RNG that is used in generation of private keys. Reason/justification: to be able to improve the available randomness by mixing in output from

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

Offhand, I'd say it's a perfect solution. It allows me to mix in additional randomness when I want to the RNG that I think may need it. Exactly what I need. Thanks! 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

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

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(), >clock_gettime

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

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 Sent

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 A

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 indicating which to seed. > > If you say it and conti

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 chang

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 move

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 need

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 ➢ ignored, it assumes it's the same as the length. For what it’s wo

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 u

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 fine

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

On 8/29/17, 11:33, "openssl-dev on behalf of Salz, Rich via openssl-dev" wrote: Could you please be more specific wrt. DRBG organization that in your opinion could impact the UI? > From your use-case: you want to add entropy into a specific DRBG. Yes. > You want to p

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 RAND_add() now, as opposed to 100 source code lines before, there may be a r

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 >

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

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 >and make an effort to do so. There is no rush. Not quite. I

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

>> > It allows hardware sources to be used via the same API. >> >> I rather doubt this. For example, my smartcard (accessible via PKCS#11) is a hardware source, which I >> occasionally use. How do you see it used with the same API? > > We have a similar situation, on a

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

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

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 test: 4 >>> Non-zer

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 > wrote: >

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

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 own randomness >> is to call

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 wrote: > > > >> On 04/09/17 08:59, Matt Caswell wrote: >> >> >>> On 03/09/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote: >>> M

[openssl-dev] Bug: digest parameter is rejected

RSA-OAEP supports different hash functions and MGF. SHA-1 is the default. OpenSSL implementation of OAEP wrongly refuses to set the hash algorithm, preventing one from using SHA-2 family: $ openssl version OpenSSL 1.0.2l  25 May 2017 $ openssl pkeyutl -encrypt -in t1264.dat -out t1264.da

Re: [openssl-dev] Bug: digest parameter is rejected

OpenSSL implementation of OAEP wrongly refuses to set the hash algorithm, preventing one from using SHA-2 family: You'll probably need to pick up master and its -rsa_mgf1_md argument to pkeyutl. Thank you – better with “-pkeyopt rsa_mgf1_md:sha256”. But still broken – as it affects only the M

Re: [openssl-dev] Bug: digest parameter is rejected

On 9/18/17, 14:50, "openssl-dev on behalf of Douglas E Engert" wrote: Can you also add -pkeyopt rsa_oaep_md:sah256 See crypto/rsa/rsa_pmeth.c pkey_rsa_ctrl_str for the options. There is also rsa_oaep_label Thank you!! That saved the day: $ ~/openssl-1.1/bin/openssl pkeyutl -encrypt

Re: [openssl-dev] Bug: digest parameter is rejected

See crypto/rsa/rsa_pmeth.c pkey_rsa_ctrl_str for the options. There is also rsa_oaep_label Thank you!! That saved the day: . . . . . Where can I see the complete list of the options that “-pkeyopt” supports now? I missed the crypto/rsa/rsa_pmeth.c pkey_rsa_ctrl_st

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

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 t

[openssl-dev] Missing EVP_PKEY method to set engine?

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, ); and this operation succeeds. However the resulting key handle has its engine

[openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

for the members, or add/move this structure from evp-int.h to evp.h (so it's no longer opaque). What is your opinion? Thanks! Regards, Uri Sent from my iPhone On Oct 1, 2017, at 18:54, Dr. Stephen Henson wrote: On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote:

Re: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

gt; > 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 specific, the following get methods are missing in 1.0.2: > &g

[openssl-dev] Nasty bug in crypto/evp/m_sigver.c

This bug prevents normal working of EVP_DigestSignInit() and subsequent calls when pkcs11 engine is involved. Scenario: hashing and signing data, when signing is done on a token that supports only internal padding (aka it performs RSA-PSS padding on-board, rather than letting software such a

Re: [openssl-dev] Nasty bug in crypto/evp/m_sigver.c

Forgot to add that when you do provide the engine impl in the EVP_DigestSignInit() invocation, the app fails because it tries to “outsource” the digesting of the data to the engine as well: $ ./t2a Using YubiHSM device... Signature padding is RSA-PSS padding Enter PKCS#11 token PIN for Yub

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 IoT, but I imagine th

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 interop problems if we cha

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" wrote: There’s a new blog post at https://www.opens

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 > to make it very c

Re: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option

Good idea, IMHO. -- Regards, Uri BlumenthalVoice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln LaboratoryCell: (339) 223-5363 244 Wood Street, Lexington, MA 02420-9185 Web: http://www.ll.mit.edu/CST/ MIT LL R

Re: [openssl-dev] Kerberos

What are the problems? - Original Message - From: Matt Caswell [mailto:m...@openssl.org] Sent: Tuesday, May 05, 2015 04:21 AM To: openssl-us...@openssl.org ; openssl-dev@openssl.org Subject: [openssl-dev] Kerberos I am considering removing Kerberos support from OpenSSL 1.1.0. There are

Re: [openssl-dev] Kerberos

#x27;m not volunteering for :). Between a rock and a hard place. :-) - Original Message - From: Matt Caswell [mailto:m...@openssl.org] Sent: Tuesday, May 05, 2015 08:56 AM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Kerberos On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wro

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 Cc: openssl-de

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 ; openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #3876] [PATCH

Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill md5sum!)

Bill, I agree. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Bill Cox Sent: Tuesday, June 9, 2015 18:00 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #3897] request: add BLAKE2 hash function (let's kill

Re: [openssl-dev] Build failure on SLES11

Just to let you ‎know that I thoroughly enjoyed your reply. :-) Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Andy Polyakov Sent: Thursday, June 11, 2015 10:14 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [op

Re: [openssl-dev] On release pre announcements

On 7/9/15, 15:06 , "openssl-dev on behalf of Salz, Rich" wrote: >Perhaps something like the CVE vectors, that others have suggested? >https://nvd.nist.gov/CVSS/Vector-v2.aspx I’d say it makes sense, and would be useful. >It's (a bit?) extra work while getting the release out, so it would be >g

Re: [openssl-dev] We're working on license changes

+1 Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Hanno Böck Sent: Friday, July 31, 2015 12:55 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] We're working on license changes Hi, On Fri, 31 Jul 20

Re: [openssl-dev] common factors in (p-1) and (q-1)

I think adding the recommended check would be beneficial. Considering the frequency of ‎key generation, performance impact shouldn't matter all that much.  Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: p...@securecottage.com Sent: Friday

Re: [openssl-dev] common factors in (p-1) and (q-1)

-dev@openssl.org Subject: Re: [openssl-dev] common factors in (p-1) and (q-1) On Fri, Jul 31, 2015 at 4:43 PM, Blumenthal, Uri - 0553 - MITLL wrote: I think adding the recommended check would be beneficial. Considering the frequency of ‎key generation, performance impact shouldn't matter all

Re: [openssl-dev] common factors in (p-1) and (q-1)

Viktor, This is my logic precisely:"Perhaps we should do this check, just because we can".  It makes things cryptographically better. Is it really necessary (better vs. good enough)? I don't know, maybe not. But the prudent approach seems to be closing as many of the potential loopholes as pos

Re: [openssl-dev] We're working on license changes

How about getting a second opinion? Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Matt Caswell Sent: Tuesday, August 4, 2015 03:56 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] We're working on li

Re: [openssl-dev] We're working on license changes

erry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Blumenthal, Uri - 0553 - MITLL Sent: Tuesday, August 4, 2015 09:20 To: Matt Caswell; openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] We're working on license changes How

Re: [openssl-dev] We're working on license changes

No I don't. And since I haven't contributed to this project in the past (rejected patch doesn't count), and don't have immediate code contribution plans for the future - I personally couldn't care less.‎ For my own use most any open source license works fine. Sent from my BlackBerry 10 smartpho

Re: [openssl-dev] We're working on license changes

True, but "most people" aren't contributing code. (Assuming this assumption is correct.) Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Salz, Rich Sent: Tuesday, August 4, 2015 12:03 To: openssl-dev@openssl.org Reply To: openssl-dev@openss

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

e: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled On Fri, 2015-08-07 at 15:07 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Considering emerging attacks against UEFI I'd be hesitant weakening > protection mechanisms, even tho

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

For the sake of brevity I’ll answer to only some of your points (that I consider relevant to my views or work). On 8/10/15, 5:44 , "openssl-dev on behalf of David Woodhouse" wrote: >UEFI is widely mocked for how bloated it is, given that the job of a sane >firmware is to boot the operating as qu

[openssl-dev] Strange problem with cms_cd.o?

I am trying to build the current Github version of openssl on Ubuntu-14.04 LTS. Must add that this system has openssl-1.0.1f already installed (relict of Ubuntu software update process). Everything seems to compile fine, but linking of “openssl” fails, complaining that it cannot find “CMS_Compress

[openssl-dev] Some tests fail on the current/latest SNAP

$ apps/openssl$ openssl version OpenSSL 1.1.0-dev xx XXX $ make test testing... make[1]: Entering directory `/media/uri/Src/openssl/test' make[2]: Entering directory `/media/uri/Src/openssl' making all in apps... make[3]: Entering directory `/media/uri/Src/openssl/apps' make[3]: Nothing to be

Re: [openssl-dev] Some tests fail on the current/latest SNAP

ommand line might help clear this up: > >HARNESS_VERBOSE=yes make TESTS=test_sslextension test > >Cheers, >Richard > >In message <55fb36b5.40...@openssl.org> on Thu, 17 Sep 2015 22:55:01 >+0100, Matt Caswell said: > >matt> Hmmm. I cannot reproduce

Re: [openssl-dev] Some tests fail on the current/latest SNAP

t least “Message.pm”… In message on Fri, 18 Sep 2015 16:18:53 +0000, "Blumenthal, Uri - 0553 - MITLL" said: >uri> Richard, >uri> >uri> Thank you for your help! Unfortunately, the problem persists: >uri> >uri> testing... >uri> make[1]: Enterin

Re: [openssl-dev] Some tests fail on the current/latest SNAP

uot;), 1 ); plan tests => 1; ... -- Regards, Uri Blumenthal On 9/18/15, 15:46 , "Richard Levitte" wrote: >In message on Fri, 18 Sep 2015 19:23:09 >+, "Blumenthal, Uri - 0553 - MITLL" said: > >uri> On 9/18/15, 15:15 , "Richard Lev

Re: [openssl-dev] Some tests fail on the current/latest SNAP

On 9/18/15, 15:54 , "Matt Caswell" wrote: >>You can look for yourself, $proxy should be assigned like this: >> >> my $proxy = TLSProxy::Proxy->new( >> \&extension_filter, >> cmdstr(app(["openssl"])), >> top_file("apps", "server.pem"), >> 1# <= This is what turns o

Re: [openssl-dev] Some tests fail on the current/latest SNAP

I compiled with   ./config threads shared zlib Should I drop zlib and try again...? Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Matt Caswell Sent: Friday, September 18, 2015 18:01 To: Blumenthal, Uri - 0553 - MITLL; Richard Levitte Cc

Re: [openssl-dev] Some tests fail on the current/latest SNAP

.org> on Sat, 19 Sep 2015 20:35:13 >+0100, Matt Caswell said: > >matt> On 18/09/15 21:24, Blumenthal, Uri - 0553 - MITLL wrote >matt> > # Looks like you planned 11 tests but ran 20. >matt> > >matt> > >matt> > # Failed test 'CMS <=>

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

FWIW, I agree with Viktor. ‎ ‎ Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Salz, Rich‎ Sent: Friday, November 13, 2015 17:02 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Removing obsolete crypto

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> On 16 November 2015 at 19:05, Hubert Kario wrote: >> Example: CAdES V1.2.2 was published in late 2000, the first serious >> attacks on MD2 were not published until 2004. I think it is not >> unreasonable for CAdES-A documents to exist today which were originally >> signed with MD2 while it was s

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Huge +1. I find Viktor’s arguments more than convincing - irrefutable. As for “weakening the library”, I don’t find this argument correct. It is not about libssl - it’s about libcrypto. Quite a different animal. -- Regards, Uri Blumenthal On 11/16/15, 18:23 , "openssl-dev on behalf of Matt

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" wrote: >On 11/18/2015 07:05 AM, Hubert Kario wrote: >> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to >>support >> both relatively modern TLS with user certificates, preferably the >>newest >> cryptosystems and has

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/19/15, 5:01 , "openssl-dev on behalf of Tomas Mraz" wrote: >On Čt, 2015-11-19 at 02:12 +, Viktor Dukhovni wrote: >> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: >> >>> I guess I'm just having a hard time wrapping my head around why, upon >> > hearing that the volunte

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

> ​Heh. I actually tested building all releases of openssl after 0.9.7 a few > months back - several refuse to build with the default options on 64 bit. In > addition my experience shows that compilers get stricter over time, so old > code will general need changes to work with newer compilers (eve

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

>> I did not say “no maintenance costs”. I said that I concur that the >> maintenance costs for such code would be minimal, which usually it is. >> >> I’m against “disabling by default”. Removing access to such code from libssl >> is OK, and the correct thing to do from the security point of view.

Re: [openssl-dev] [openssl.org #4157] Download Documentation

On 11/30/15, 11:10 , "openssl-dev on behalf of Hubert Kario" wrote: >On Friday 27 November 2015 13:39:36 Tom Jay via RT wrote: >> 3. Some kind of useful examples of common usages >> of OpenSSL would be appreciated. > >https://wiki.openssl.org/index.php/Main_Page > >If you have specific use cases

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

+2 to Rich and Nico. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Salz, Rich Sent: Wednesday, December 9, 2015 08:37 To: paul.d...@oracle.com; openssl-dev@openssl.org; Nico Williams Reply To: openssl-dev@openssl.org Subject: Re: [openssl-

[openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token?

I’m having a problem, and am not sure whether it’s due to my ignorance/misuse of the tool (i.e. it should be done differently), or a bug in the tool, or it’s just not capable of doing what I want it to. What I’m trying to accomplish: use engine_pkcs11 wit

Re: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token?

and your willingness to fix this even more. By the way, there appears to be another order-related issue also: -pkeyopt must follow -inkey. But in this case pkeyutl at least reports the problem correctly. Thanks! >In message on Wed, 9 Dec 2015 21:24:41 >+, "Blumenthal, Uri - 0553 -

Re: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token?

e” (for ECDH key)… Thanks! -- Regards, Uri Blumenthal On 12/10/15, 10:38 , "openssl-dev on behalf of Blumenthal, Uri - 0553 - MITLL" wrote: >On 12/10/15, 3:39 , "openssl-dev on behalf of Richard Levitte" > wrote: > >>This is an odity with 'openssl p

Re: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token?

you would need to set > PIV_9C_KEY=path.to.pubkey.file.der > This should work with other programs like openssl pkeyutl too. > > Once the certificate is then loaded, the PIV_9X_KEY environment variable will > not be used. Got it. Thanks! On 12/10/2015 9:38 AM, Blumenthal, Uri -

Re: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token?

On 12/10/15, 12:32 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >The reason for that is because the -engine option sets the ENGINE to use >for >everything and the PKCS#11 ENGINE doesn't support that public key method. I’m afraid I don’t understand. What good is a PKCS#11 engine if it d

Re: [openssl-dev] openssl pkeyutl unable to use keys on a PKCS11 token?

On 12/10/15, 16:56 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >>>Temporary fix is to set the second argument in EVP_PKEY_CTX_new to NULL >> >in pkeyutl.c >> >> With your proposed (temporary) fix, the signature both generated and >> verified successfully (see below). Could I ask to pu

<    1   2   3   >