Re: [openssl-dev] Kerberos

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 openssl-dev@openssl.org Subject: Re: [openssl-dev] Kerberos On 05/05/15 13:22, Blumenthal, Uri - 0553

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-us...@openssl.org; openssl-dev@openssl.org openssl-dev@openssl.org Subject: [openssl-dev] Kerberos I am considering

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

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:

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 #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] 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 u...@ll.mit.edu wrote: I think adding the recommended check would be beneficial. Considering the frequency of ‎key generation, performance impact shouldn't

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

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 

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

 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 about getting a second opinion? Sent

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

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

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:

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:

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 #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 openssl-dev-boun...@openssl.org on behalf of dw...@infradead.org wrote: UEFI is widely mocked for how bloated it is, given

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

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

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] On release pre announcements

On 7/9/15, 15:06 , openssl-dev on behalf of Salz, Rich openssl-dev-boun...@openssl.org on behalf of rs...@akamai.com 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?)

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

[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

[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

the expected output from at least “Message.pm”… In message <d221b126.1f30d%...@ll.mit.edu> on Fri, 18 Sep 2015 16:18:53 +0000, "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> said: >uri> Richard, >uri> >uri> Thank you for your help! Unfortunately, the

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

ts => 1; ... -- Regards, Uri Blumenthal On 9/18/15, 15:46 , "Richard Levitte" <rich...@levitte.org> wrote: >In message <d221dc6b.1f354%...@ll.mit.edu> on Fri, 18 Sep 2015 19:23:09 >+, "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> said: &g

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( >> \_filter, >> cmdstr(app(["openssl"])), >> top_file("apps", "server.pem"), >> 1# <= This is

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

. Is anyone else seeing this? >matt> >matt> Matt >matt> >matt> On 17/09/15 20:15, Blumenthal, Uri - 0553 - MITLL wrote: >matt> > $ apps/openssl$ openssl version >matt> > OpenSSL 1.1.0-dev xx XXX >matt> > $ make test >matt> > testi

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

, 19 Sep 2015 20:35:13 >+0100, Matt Caswell <m...@openssl.org> 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] [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-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

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

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

[openssl-dev] Cannot verify self-signed certificates?

It appears that openssl verify refuses to deal with self-signed certificates? Is it the expected/intended behavior? I can easily imagine circumstances when a user would be happy with a “partial” validation, i.e. with validating as much as practically possible – like consistency, correctness of the

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

ot;pkcs11" set. The key ID is not a valid PKCS#11 URI as defined by RFC7512. PKCS11_load_public_key returned NULL unable to load key file Is it a bug, or what am I doing wrong? Thanks! -- Regards, Uri Blumenthal On 12/10/15, 17:17 , "openssl-dev on behalf of Blumenthal, Uri - 0553 - MITLL&qu

Re: [openssl-dev] Cannot verify self-signed certificates?

>>If I want to “partially” verify a certificate via the command-line >>utility >> - e.g. when I don’t have the issuing certificate at hand, is there a way >> to tell openssl tool to go just as far as it can *without* climbing up >>the >> cert chain? I understand and agree that it significantly

Re: [openssl-dev] Cannot verify self-signed certificates?

On 12/15/15, 17:51 , "openssl-dev on behalf of Viktor Dukhovni" <openssl-dev-boun...@openssl.org on behalf of openssl-us...@dukhovni.org> wrote: >>On Dec 15, 2015, at 5:30 PM, Blumenthal, Uri - 0553 - MITLL >><u...@ll.mit.edu> wrote: >> >>$ op

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" <openssl-dev-boun...@openssl.org on behalf of u...@ll.mit.edu> wrote: >On 12/10/15, 3:39 , "openssl-dev on behalf of Richard Levitte&qu

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

o help - 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 <d28e0643.23c27%...@ll.mit.edu> on Wed, 9 Dec 2015 21:2

Re: [openssl-dev] Cannot verify self-signed certificates?

On 12/15/15, 15:34 , "openssl-dev on behalf of Viktor Dukhovni" <openssl-dev-boun...@openssl.org on behalf of openssl-us...@dukhovni.org> wrote: >On Tue, Dec 15, 2015 at 08:04:45PM +0000, Blumenthal, Uri - 0553 - MITLL >wrote: >> It appears that openssl verify refu

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

>>> $ openssl dgst -engine pkcs11 -keyform engine -verify >> > "pkcs11:object=SIGN%20pubkey;object-type=public" -sha256 -sigopt >> >> The current implementation of engine_pkcs11 seems to work with private >> keys and certificates only. I've added a fix in engine_pkcs11, but it >> seems that

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

rsautl, or dgst… What would be a good location in the code for that addition? Thanks! > On 12/17/2015 4:06 PM, Blumenthal, Uri - 0553 - MITLL wrote: >> I’m playing with RSA-PSS and PKCS11 engine (in OpenSSL, of course :). >> >> This works: >> >> $ openssl dgst -engin

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

On 12/18/15, 10:46 , "openssl-dev on behalf of Nikos Mavrogiannopoulos" <openssl-dev-boun...@openssl.org on behalf of n...@redhat.com> wrote: >On Thu, 2015-12-17 at 22:06 +0000, Blumenthal, Uri - 0553 - MITLL >wrote: >> I’m playing with RSA-PSS and PKCS11 e

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

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

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" <openssl-dev-boun...@openssl.org on behalf of st...@openssl.org> wrote: >On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote: >... > >> >Temporary fix is to set the second ar

[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

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

[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

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

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

>>On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL >><u...@ll.mit.edu> 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/

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" <openssl-dev-boun...@openssl.org on behalf of levi...@openssl.org> wrote: >In message <d3886b43.2dd2e%...@ll.mit.edu> on Thu, 16 Jun 2016 18:42:17 >+0000, "Blumenthal, Uri - 0553 - MITLL" <u

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

[openssl-dev] pkeyutl does not invoke hash?

I’m not sure whether this is a bug (as I suspect – hence sending to openssl-dev), or a poorly-documented “feature” (so copying to openssl-users). I am trying to use “openssl pkeyutl” to digitally sign (and verify) a file. When the file size matches the size of the specified digest (32 bytes for

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

.   Original Message   From: Hubert Kario Sent: Friday, January 15, 2016 07:00 To: Blumenthal, Uri - 0553 - MITLL Cc: openssl-dev@openssl.org; openssl-us...@openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

n 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > <openssl-dev-boun...@openssl.org on behalf of st...@openssl.org> wrote: > > >On Thu, Jan 14, 2016, Salz, Rich wrote: > > > >> Ok

Re: [openssl-dev] Website "Downloads": remove 1.1.0pre1 from list of downloadable files

On 1/15/16, 13:34 , "openssl-dev on behalf of Richard Levitte" wrote: >In message <569937f1.6000...@kippdata.de> on Fri, 15 Jan 2016 19:18:25 >+0100, Rainer Jung said: > >rainer.jung> In addition one

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" <openssl-dev-boun...@openssl.org on behalf of st...@openssl.org> wrote: >On Wed, Jan 13, 2016, Blumenthal, Uri - 0553 - MITLL wrote: >> >> >> If the input to "pkeyutl -sign" is suppo

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

] [openssl-users] pkeyutl does not invoke hash? On Friday 15 January 2016 00:02:43 Dr. Stephen Henson wrote: > On Thu, Jan 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > On 1/14/16, 16:51 , "openssl-dev on behalf of Dr. Stephen Henson" > > > > <openssl-dev-b

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

On 1/14/16, 13:56 , "Hubert Kario" <hka...@redhat.com> wrote: >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: >> If you already know what Dr. Henson explained in the quoted emails - >> then the man page is crystal clear. However, if you

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-users] pkeyutl does not invoke hash?

2016 21:32:47 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" > > <openssl-dev-boun...@openssl.org on behalf of st...@openssl.org> wrote: > >The reason you can specify which hash the digest is for is that

[openssl-dev] Current master branch doesn't compile - fails "make depend"

The complete report is at https://github.com/openssl/openssl/issues/651 Configuration: $ ./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2 enable-deprecated experimental-jpake threads zlib enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1

Re: [openssl-dev] Do you use the JPAKE feature?

It’s currently “experimental” and we’re thinking of dropping it completely from the next release. If you use it, please reply here soon. All of my openssl builds have JPAKE enabled. But I cannot call myself a user of it. I’d rather not see it dropped, but I can’t claim operational impact if

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

Testing the previous Github version of OpenSSL-1.1 produced encouraging results (notice the leading zero, right where it belongs): $ x=128; DYLD_LIBRARY_PATH=/Users/ur20980/src/openssl-1.1/lib ~/src/openssl-1.1/bin/openssl asn1parse -genstr "INTEGER:$x" -out d.der && hexdump -C d.der 0:d=0

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

On 2/11/16, 14:29 , "openssl-dev on behalf of Salz, Rich" wrote: >If arbitrary leading zero's were allowed in DER, then the encoding >wouldn't be *distinguished*, i.e., unique. I am NOT talking about “arbitrary” leading zeros. I

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

>On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT >wrote: >>On Wed Feb 10 21:59:12 2016, bcri...@gmail.com wrote: >>As the error is suggesting it doesn't like the serialNumber in the >>certificate. >> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1

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

>>On Feb 11, 2016, at 2:46 PM, Blumenthal, Uri - 0553 - MITLL >><u...@ll.mit.edu> wrote: >> >> Testing the previous Github version of OpenSSL-1.1 produced encouraging >> results (notice the leading zero, right where it belongs): >> >> $ x=128; DYLD

Re: [openssl-dev] Current Github master fails to compile/link

On 2/11/16, 16:16 , "openssl-dev on behalf of Salz, Rich" wrote: >Yes, fixed now. I confirm the fix. Thanks! smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe:

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

[openssl-dev] Current Github master fails to compile/link

./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2 enable-deprecated experimental-jpake threads zlib enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/engines-1.1 … LD_LIBRARY_PATH=.: clang -DDSO_DLFCN -DHAVE_DLFCN_H

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

On 2/4/16, 12:10 , "openssl-dev on behalf of Kurt Roeckx via RT" wrote: >On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote: >> Really? >> >> That's all we get, a one-liner, no explanation, no rationale, response? >>

Re: [openssl-dev] OpenSSL Security Advisory

+1 Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Hanno Böck Sent: Friday, January 29, 2016 06:18 To: openssl-dev@openssl.org Reply To: openssl-dev@openssl.org Cc: open...@openssl.org Subject: Re: [openssl-dev] OpenSSL Security Advisory

Re: [openssl-dev] ECDH engine

ges to OpenSSL, which is another >> approach. >> He has said there were here: >> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches >> >> You could also hire someone who could do more then: "test it and offer minor >> enhancements".

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

On 2/1/16, 9:23 , "Hubert Kario" <hka...@redhat.com> wrote: >On Wednesday 20 January 2016 17:17:47 Blumenthal, Uri - 0553 - MITLL >wrote: >> I see. Steve, what would you suggest to add to the man page, in view >> of what we’ve been discussing for the last few d

[openssl-dev] openssl-1.1 started looking for engines using wrong names

In short, after commits done in the last few days, openssl-1.1 stopped looking for lib.so, and started looking for .so. I think it’s an introduced bug that needs to be fixed: $ ~/src/openssl-1.1/bin/openssl engine pkcs11 -t 140735268914000:error:25066067:DSO support routines:dlfcn_load:could not

Re: [openssl-dev] Ubsec and Chil engines

On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse" wrote: >>It may even be better, instead of pushing for different engines for >> different hardware, to make PKCS#11 the only API used to talk to >> hardware. There is a

Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug

If somebody (Mik, Felipe, you hear? :) cares to send me a *simple* *short* code that exposes this problem, I’ll be willing to test it on Linux and Mac OS X, with OpenSSL-1.0.2f, OpenSSL-1.0.2-stable, and 1.1-pre. -- Regards, Uri Blumenthal On 2/20/16, 9:10 , "openssl-dev on behalf of Salz,

Re: [openssl-dev] Ubsec and Chil engines

>>> Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 >> > to die, and be replaced by native code in openssl/crypto/pkcs11/ >> >> Would you mind explaining what you mean by “native code” that presumably >> could replace the current libp11, and who in your opinion would support

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

>>> Nonsense. Source code is not API documentation, it is an >> > implementation, not an interface contract. >> >> I'm not sure I'd consider it nonsense. > >Comments in source code are not documentation, they explain the >internals of the implementation, not the contract. Actually they can (and

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

On 1/19/16, 7:15 , "Hubert Kario" <hka...@redhat.com> wrote: >On Monday 18 January 2016 19:22:19 Blumenthal, Uri - 0553 - MITLL wrote: >> My preference would be to explain exactly - to avoid confusion and >> problems arising from possible misunderstanding. >&g

[openssl-dev] Bug and PR: pkeyutl.c fails -derive with token (1.0.2-stable)

Currently pkeyutl.c fails to derive a shared symmetric key when the peer public key is on a hardware token. PR https://github.com/openssl/openssl/pull/557 fixes this issue. Review and merge would be appreciated. It applies to OpenSSL_1_0_2-stable. (Will be a separate one for 1.1.) -- Regards,

[openssl-dev] Bug and PR: pkeyutl.c fails to work with keys that reside on a token (fix against master)

This fix is for a problem that existed in all the OpenSSL branches. For 1_0_2-stable it has been already fixed by the approved and merged PR #523. This PR https://github.com/openssl/openssl/pull/548 is a port of it to the master branch (and has been sitting there for a while :). I’d appreciate a

Re: [openssl-dev] Configure --prefix and --openssldir

These ‎arguments work quite well for me.  I use them to install openssl over Macports default installation, and having --prefix and --openssldir turns out to be sufficient for the job. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From:

Re: [openssl-dev] ECDH engine

chip that add uncertainly of non-interoperability with other chips/tokens. On Jan 20, 2016, at 8:11 AM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote: What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via

Re: [openssl-dev] ECDH engine

lps. P.S. At this time I’m standing by my original opinion – that a better way is incorporating ECDH1_*DERIVE in libp11 and engine_pkcs11, rather than creating an engine specifically for one chip that add uncertainly of non-interoperability with other chips/tokens. > On Jan 20, 2016, at 8:1

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

sl.org> wrote: >On Wed, Jan 20, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > >> On 1/20/16, 5:10 , "Hubert Kario" <hka...@redhat.com> wrote: >> >> It appears to me that pkeyutl is more an instrument to access those >> primitive operations, u

Re: [openssl-dev] ECDH engine

What is this Atmel x508x? Is it a chip? Is it a token/smartcard? Is it accessible via PKCS#11 at all? Is it accessible by/via OpenSC? I am trying to figure why such a generic and useful set of ECC operations (Sign, Derive) is implementation-limited to one single .  A much better solution to me

Re: [openssl-dev] ECDH engine

looks like Ubuntu is even worse off than Macports). > On Wed, Jan 20, 2016 at 11:10 AM, Blumenthal, Uri - 0553 - MITLL > <u...@ll.mit.edu> wrote: >> Are you saying it won't work on OpenSSL_1_0_2-stable?! >> >> Sent from my BlackBerry 10 smartphone on the Verizon Wirel

Re: [openssl-dev] ECDH engine

, there is also underway changes for OpenSC to use OpenSSL-1.1: https://github.com/OpenSC/OpenSC/pull/654 https://github.com/dengert/OpenSC/tree/prep-openssl-1.1 On 1/20/2016 12:02 PM, Blumenthal, Uri - 0553 - MITLL wrote: I forgot to add that ‎OpenSSL-1_0-2-stable with the current (Github master

Re: [openssl-dev] ECDH engine

of other things. But that was there approach. Its their package. From working package to distribution always takes several years... ‎ On 1/20/2016 1:34 PM, Blumenthal, Uri - 0553 - MITLL wrote: Probably it was one of the main reasons why we didn't use pkcs11 for ATECC508A and wrote an engine instead

Re: [openssl-dev] ECDH engine

> Ø Still, since openssl-1_0_2 does ECDH, and it exposes ‎ECDSA to external > engine(s), how difficult would it be to add ECDH exposure? I suspect - a good > deal easier than getting 1.1 replace 1.0.x as the de-facto deployment > standard. > > > It’s a new feature, so it won’t come from

Re: [openssl-dev] ECDH engine

On 1/20/16, 16:25 , "openssl-dev on behalf of Salz, Rich" wrote: >> The fact that these mechanisms are half-done means to be that it’s a >>bug in need of fixing. > >I doubt that anyone else on the team will find this argument

Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

On 1/20/16, 5:10 , "Hubert Kario" <hka...@redhat.com> wrote: >On Tuesday 19 January 2016 22:16:23 Blumenthal, Uri - 0553 - MITLL wrote: >> Looks good. I might add an *explicit* statement “pkeyutl does not >> invoke the specified digest function”. >&g

Re: [openssl-dev] ECDH engine

o: openssl-dev@openssl.org >> Subject: Re: [openssl-dev] ECDH engine >> ‎ >> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to >> external engines. It took years to even get ECDSA exposed. >> OpenSSL approach to support this is OpenSSL-1.1 that do

Re: [openssl-dev] ECDH engine

17, 2016 at 11:32 To: openssl-dev <openssl-dev@openssl.org> Subject: Re: [openssl-dev] ECDH engine > Hi Uri, > > On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL > <u...@ll.mit.edu> wrote: >>> When I started to write the ECDSA code for engine_pkcs1

  1   2   3   >