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

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

[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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

>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

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

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

>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

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

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

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

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

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

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

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

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

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

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

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

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

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] 90-test_secmem.t hangs the machine for good

On 5/15/17, 1:20 PM, "openssl-dev on behalf of Benjamin Kaduk via openssl-dev" wrote: > On a semi-related note, I want able to locate mann.h file either. `man mmap` will list any headers needed for the mmap() declaration and flag values. On the random OS X machine I have handy, it claims is

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

@akamai.com > // "One if by land, two if by sea, three if by the Internet." > >> On May 15, 2017, at 1:15 PM, Blumenthal, Uri - 0553 - MITLL >> wrote: >> >> My disk is SSD, but computer load is pretty high. Which probably explains >> that recovery

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

pect the hang may > eventually recover; but if you have a hard disk that time might be quite long. > > -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > >> On May 15, 2017, at 11:51 AM, Blumenthal, Uri - 05

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

reserve 1<<34 bytes of memory… there goes your 16GB... -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL wrote: Todd> Yes, it’s likely this is due to the amoun

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

The obvious candidate for closer inspection is a few commits previous, commit 7031ddac94d0ae616d1b0670263a9265ce672cd2 Author: Todd Short Date: Thu May 11 15:48:10 2017 -0400 which adds test cases intended to trigger the edge cases being fixed. Point well-taken. ;-) It seems that there

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

On 5/12/17, 2:49 PM, "openssl-dev on behalf of Benjamin Kaduk via openssl-dev" wrote: ➢ I’m sorry to report that in the current OpenSSL 1.1 master running “make test” ➢ freezes up the machine. Mac OS X 10.11.6, Xcode-8.2, current Github master. ➢ Here’s the configuration: A commit hash

[openssl-dev] 90-test_secmem.t hangs the machine for good

I’m sorry to report that in the current OpenSSL 1.1 master running “make test” freezes up the machine. Mac OS X 10.11.6, Xcode-8.2, current Github master. Here’s the configuration: ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128 enable-rfc37

Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag

On 4/13/17, 5:58 PM, "openssl-dev on behalf of Richard Levitte" wrote: deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey deengert> > "pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep deengert> > -in t256.dat.enc -out t256.dat.dec

Re: [openssl-dev] rsautl.c incorrectly processes "-oaep" flag

On 4/13/17, 5:18 PM, "Richard Levitte" wrote: uri> . . . . . uri> libp11 does not know how to deal with OAEP padding, so it returns an error. uri> uri> Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the engine (aka to libp11), and strip the padding using OpenSSL

[openssl-dev] rsautl.c incorrectly processes "-oaep" flag

I am trying to use “openssl rsautl” to wrap/unwrap symmetric keys in a script. Decryption (and encryption too, but that isn’t relevant) is done using a token accessible via pkcs11 engine (libp11). The problem is: “rsautl” appears to assume that if “-oaep” flag is given, then the engine is going

Re: [openssl-dev] License change agreement

Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: >>>> On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: >>>> >>>>> On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: >>>>>> On Fri, Mar 24, 2017 at 04:11:48A

Re: [openssl-dev] License change agreement

Apache license is fine for me, while GPL could be problematic. Incompatibility with GPLv2 is not a problem for us. If it is a problem for somebody - feel free to explain the details. Though I think the decision has been made, and the majority is OK with it. Regards, Uri Sent from my iPhone

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

We don’t need the full output width of a good hash function, but for _this_ purpose (as far as I understand) we don’t need the strength of a good hash function either – and we surely don’t need the unnecessary performance hit of a good hash where we don’t need a good hash. Or am I missing so

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

I confirm that this fix (currently in the master) resolves the issue. Thanks! — Regards, Uri On 11/29/16, 4:53 AM, "openssl-dev on behalf of Matt Caswell" wrote: On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote: > > The problem is in t

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

>> So why is it better to say “…engine –key /some/weird/path/weird >> -file.pem” than “…engine –key pkcs11:id=02” (or such)? > > There appears to be some confusion here. pkcs11 is a representation > for defined tokens. Well, I did not mean *specifically* pkcs11 – just as an e

Re: [openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" wrote: > One of the principle problems of using TPM based keys is that there's > no easy way of integrating them with standard file based keys. Why should token- and/or TPM-based keys be integrated with file-based keys?

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

> The problem is in the test. Version negotiation happens before cipher > selection. The test creates a connection which negotiates TLSv1.3. It > then attempts to select a cipher. However no TLSv1.3 ciphers are offered > by the test so the connection aborts. In truth the test is all

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

>> The only thing that changed for this build now was addition of “enable-tls1_3” config option (and of course, pulling the latest stuff from the master). >> >> Removing “enable-tls1_3” and reconfiguring makes this error disappear. So I think it’s somewhere in tls1_3 code. ;-)

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

>I can't reproduce this. But on the other hand I don't have previous >installation on --prefix. But did you add “enable-tls1_3” to your config? >I mean I would guess this is because test >program picks shared libraries at --prefix locations instead of just >built ones, and those

[openssl-dev] FW: 1.1 master fails mac-then-encrypt test

Mac OS X 10.11.6, Xcode-8.1. $ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc Configuring OpenSSL version 1.1.1-dev (0x1010

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

James.Bottomley> Yes, that's right. When any SSL program sees a TPM wrapped key, it James.Bottomley> should just do the right thing if it has the engine capability without James.Bottomley> needing the user to add any options to the command line. Mm... I'm not sure I agree w

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Frankly, I think this approach of specially-encoded PEM or DER files telling the app what key to ask from the engine is madness, compared to the straightforward URI approach (no pun intended :). Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   Fr

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

Thank you! I think I understand. (Sounds like an ugly and hardly necessary complication to me – not to mention that there might not be a filesystem to keep those around, but…) — Regards, Uri On 11/16/16, 5:06 PM, "openssl-dev on behalf of Dr. Stephen Henson" wrote: On Wed, Nov 16, 2016,

Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

My apologies – I don’t fully understand “file based engine keys”. I thought the keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or smartcard, etc), or in a file. If a key is in a file – it’s not an “engine key”. What am I missing, and what’s your use case(s)? — Regards, U

Re: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0

On 9/16/16, 11:52, "openssl-dev on behalf of Salz, Rich" wrote: >>OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised >> by client. > >When I made X25519 the default, I didn't think about it. That was probably a >mistake. Good catch! I think so. > >> So it is ver

Re: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability

If you want to dedicate a target to /arch:ia32, I can’t object or complain. VC-WIN32-XP sounds like a good choice for that. -- Regards, Uri Blumenthal On 8/26/16, 17:27, "openssl-dev on behalf of Scott Ware" wrote: >On Fri, Aug 26, 2016 at 5:11 PM, Blumenthal, Uri - 0553 -

Re: [openssl-dev] Building VC-WIN32 with VS2012 and above breaks older CPU compatability

On 8/26/16, 17:04, "openssl-dev on behalf of Andy Polyakov" wrote: >So suggestion is to impose /arch:ia32 on all users. Well, I personally >have lesser problem with that (as most most performance-critical >assembly code paths will be compiled anyway, processor capabilities >detected at run-time,

Re: [openssl-dev] [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?

On 7/26/16, 15:24 , "openssl-users on behalf of Dr. Stephen Henson" wrote: >On Tue, Jul 26, 2016, Jim Carroll wrote: >> After experimenting, I can confirm this is the same issue we're seeing, >> although experiencing it very differently from the MIT/Kerberos team. >>I can >> confirm that right no

[openssl-dev] Discrepancy between docs and actual behavior: CMS in 1.0.2

I confess I did not test this with 1.1.x. But in 1.0.2h there’s a problem. CMS man page says: If the -decrypt option is used without a recipient certificate then an attempt is made to locate the recipient by trying each potential recipient in turn using the supplied private key. To thwart the MMA

[openssl-dev] doc/crypto/BIO_set_callback.pod still not fixed in the master

Please add a blank line after the “+over” around line 39 in doc/crypto/BIO_set_callback.pod -- Regards, Uri Blumenthal smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Error is a pod file

install ./doc/crypto/BIO_set_callback.pod -> /Users/ur20980/src/openssl-1.1/share/man/man3/BIO_set_callback.3 IO::File=IO(0x7f896a02d1c0) around line 42: =over should be: '=over' or '=over positive_number' POD document had syntax errors at /opt/local/bin/pod2man line 68. make: *** [install_man_docs

Re: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug

On 6/20/16, 17:12 , "openssl-dev on behalf of Salz, Rich" wrote: >> Defensive programming is about handling gracefully the cases when the >> user/caller does something he “is not supposed to do”. > >There is a limit. True. >Should we return an error code that will most likely be ignored? Yes,

Re: [openssl-dev] [openssl.org #4579] Bug - libcrypto.a null pointer dereference bug

On 6/20/16, 16:48 , "openssl-dev on behalf of Rich Salz via RT" wrote: >You are not supposed to pass NULL into OpenSSL API's. Just like doing >this will >cause a crash strcpy(NULL, "hello”) in a C program. Defensive programming is about handling gracefully the cases when the user/caller does som

Re: [openssl-dev] Current github 1.1-pre: installation broken (doc symlinks)

On 6/16/16, 15:02 , "openssl-dev on behalf of Richard Levitte" wrote: >In message on Thu, 16 Jun 2016 18:42:17 >+0000, "Blumenthal, Uri - 0553 - MITLL" said: >uri> /bin/sh: >uri> >/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Ini

[openssl-dev] Current github 1.1-pre: installation broken (doc symlinks)

link /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5_Final.html -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5.html MD5_Final.html => MD5.html install ./doc/crypto/MDC2_Init.pod -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html /bin/sh:

Re: [openssl-dev] [openssl.org #4559] bug: CRYPTO_set_mem_functions() Doesn't Work in Version 1.0.1b

On 6/3/16, 13:23 , "openssl-dev on behalf of Dan Kegel via RT" wrote: >1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.) I compiled your death program, and confirm that it does abort on 1.0.2h. So presumably no fix is necessary there: $clang -I/opt/local/include -o t t.c -

[openssl-dev] Inconsistency between implementation and docs in openssl cms

Manual page for “openssl cms” says: If the -decrypt option is used without a recipient certificate then an attempt is made to locate the recipient by trying each potential recipient in turn using the supplied private key. To thwart the MMA attack (Bleichenbacher's

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

>>On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL >> wrote: >> >>> 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. &

[openssl-dev] Does OpenSSL support ECC-based S/MIME as defined in RFC 5753?

Does OpenSSL support ECC-based S/MIME as defined in RFC 5753? I was trying to create an encrypted S/MIME message using OpenSSL-1.0.2h, and got the following: $ openssl smime -encrypt -aes128 -inform SMIME -in Cyph_Bot_test.eml -outform SMIME -out Cyph_Bot_test.smime.eml -subject SMIME_ECC ~/Docum

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

[openssl-dev] Current Github build fails

$ ./Configure darwin64-x86_64-cc threads shared zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) no-asan [default] OPENSSL_NO_ASAN (skip dir)

  1   2   3   >