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

"development of OpenSSL". It may be close, thought, such as planning the schedule of the next release. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

news.gmane.org openssl-dev> as gmane.comp.encryption.openssl.project as readonly list. openssl-dev> openssl-dev> I will always have a fondness for NNTP :) ... except for the trashing of the database disk(s) back in the days if you're running a server... (I did) (on VMS ;-)) But yeah, totally

[openssl-dev] NonStop platform support

effort in PR 5043: https://github.com/openssl/openssl/pull/5043 (if you claim the use of and can verify the correctness of some specific config target(s), they can be classified as community supported) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project ht

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

I'm not terribly savvy regarding IoT, but I imagine that they do talk to something bigger. A server end, perhaps? What do we expect to run on that end? What happens, in that case, if SPECK makes its way into the TLS cipher suites? Would it be interesting to have OpenSSL interop with such

Re: [openssl-dev] Problems building openssl on Solaris

Ah, sorry, I didn't read the output properly. Regarding the STV_PROTECTED warnings, I don't know at all... I did a bit of a search and saw that this has been discussed before, a little more than a year ago. See https://mta.openssl.org/pipermail/openssl-dev/2016-August/008192.html As for the

Re: [openssl-dev] Problems building openssl on Solaris

I suggest adding 'no-threads' to the OpenSSL configuration options, at least as a first step. That should at least take away gcc's complaint about '-pthread'... I cannot say if that'll fix the rest, I don't know Solaris enough. Cheers, Richard In message

Re: [openssl-dev] [openssl-users] OpenSSL engine and TPM usage.

In message

Re: [openssl-dev] Can I haz TLS 1.3 ?

It's not specific to devops. Here, a quick history lesson: https://english.stackexchange.com/questions/20356/origin-of-i-can-haz Cheers Richard Ted Marynicz skrev: (4 oktober 2017 10:53:35 CEST) >Haz? > >Is that some kind of devops-speak I am not (yet) aware of? > >Ted

Re: [openssl-dev] how to static compile ssl engine into openssl

In message <20170926203053.5hlfcbx273lko...@roeckx.be> on Tue, 26 Sep 2017 22:30:53 +0200, Kurt Roeckx <k...@roeckx.be> said: kurt> On Tue, Sep 26, 2017 at 07:32:06AM +0200, Richard Levitte wrote: kurt> > kurt> > You mean to have nginx use the shared OpenSSL

Re: [openssl-dev] how to static compile ssl engine into openssl

> There is another alternative to do it, just to alone chengwenping1> compile openssl and nginx, but it will take effort to chengwenping1> deploy it. You mean to have nginx use the shared OpenSSL libraries, which also enables dynamic engines? Yes, that's the usual way to go about these

Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency

read should be part of both compiling and linking, so Howard is perfectly correct, we're not doing this quite right. When -pthread is used, it should also be added to the libcrypto.pc's Libs.private line. I'm currently travelling, but will give this more concrete attention when I've returned, i.e. next week. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency

Matt Caswell skrev: (17 september 2017 15:04:10 GMT+08:00) >On Sat, 16 Sep 2017 22:26:10 +0100 >Howard Chu via openssl-dev wrote: > >> In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on >> libpthread but this is not reflected in the

Re: [openssl-dev] OPenssl 1.1.0 and FIPS

The Doctor skrev: (16 september 2017 15:26:16 CEST) >On Sat, Sep 16, 2017 at 12:56:08PM +, Salz, Rich via openssl-dev >wrote: >> >> Tryong to compile Fips into OPEnssl-1.1.0 and I run into >> >> FIPS is not supported for 1.1.0 >> > >jUST A SMALL FIX

Re: [openssl-dev] how to compile out selected ciphers

In message

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

ly) designed to be stable for some (hopefully considerable) time. Ah, ok. In an OpenSSL context, this gets a bit confusing since there is an API called UI ( ). -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubsc

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

more OpenSSL-like to you? Yes. And per fairly recent recommendations to avoid cluttering the name space, that would be OSSL_DRGB_CTX and OSSL_DRGB_METHOD, btw. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsu

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

> the code then I am. My role was only to give the Matthias.St.Pierre> starting shot, the rest is up to you. Fair enough! :-) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

the FIPS DRBG, which has been removed. Essentially, the argument for your last remark is in-structure vtable vs refered to vtable. I tend to prefer the latter (and that's the usual OpenSSL pattern too, even though there are exceptions). -- Richard Levitte levi...@openssl.org OpenS

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

I'm late in the game, having only followed the development very superficially... If I understand correctly, the RAND_DRBG API is really a completely separate API that has nothing to do with the RAND_METHOD API pers se, i.e. any association between the two is more or less "accidental"? Frankly, I

Re: [openssl-dev] confusion with rsa_meth_st in a custom RSA engine

e RSA structure, i.e. the components that make up the private part. Instead, that's left entirely to the mod_exp function (i.e. what you actually do implement). If you want to see for yourself what's happening, I suggest a study of crypto/rsa/rsa_ossl.c (OpenSSL 1.1.0 and up) or crypro/rsa/rsa_eay.c (OpenSSL 1.0.2). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

be buggy. May I suggest insert this line before the check, try again and see what it says? print STDERR "Current directory: ", rel2abs('.'), "\n"; -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

ere are build warnings mtstickney> > earlier in the process, but from what I've seen they look harmless). mtstickney> > mtstickney> > -Matt Stickney mtstickney> > mtstickney> > On Mon, Jul 31, 2017 at 10:17 AM, Richard Levitte <levi...@openssl.org> wrote

Re: [openssl-dev] Build issue

ebuild? If the previous run gave incorrect results, you may have ended up with an incomplete libcrypto.so, but with timestamps that make it look lite it's already built. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

stickney> about 9pm EDT last night, so I'd imagine that util/mkdef.pl in master mtstickney> still has whatever the issue is. mtstickney> mtstickney> -Matt Stickney mtstickney> mtstickney> On Tue, Jul 25, 2017 at 2:59 PM, Richard Levitte <levi...@openssl.org> wrote: mtstickney> > In message

Re: [openssl-dev] Build issue

In message

Re: [openssl-dev] Windows system cert store

In message

Re: [openssl-dev] Compiler requirements

o say that C95 compiler is fine as well. C99, not so much, there's too much risk that we start excluding some platforms if we start using its features. Anyway, I don't think it's safe to upgrade our minimum expectations now. OpenSSL 1.2.0 would be a good time for such re-evaluations. Cheers, Richard

Re: [openssl-dev] Compiler requirements

rs language syntax. We do use libraries that came later, but then also guard them with a suitable check of __STDC_VERSION__ or similar, and use or provide alternate implementations when necessary. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.opens

Re: [openssl-dev] 2 snapshots did not generate accordingly

We were still building snapshots for it, though. I've adjusted the script today and removed all present 1.0.1 snapshots (that's the answer for you, Doc) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To un

Re: [openssl-dev] 2 snapshots did not generate accordingly

tar.gz doctor> doctor> did not generate accordingly. doctor> doctor> They are at 0 bytes Thanks for notifying us. The disk had filled up, I'm cleaning up. I'll remove those empty tarballs, there will be new ones tomorrow. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL

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

y differ... the question of deprecating commands hasn't actually come up yet. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

In message <006b8116-8aad-18f6-8759-2696ebf38...@gmail.com> on Thu, 13 Apr 2017 16:41:35 -0500, Douglas E Engert <deeng...@gmail.com> said: deengert> deengert> deengert> On 4/13/2017 4:18 PM, Richard Levitte wrote: deengert> > In message <1ef605ec-d2dd-4d15-a27f-1

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

c/p11_rsa.c#L72 What you propose for OpenSSL is quite a lot harder to implement well, and one might also wonder why the OAEP padding should have that special treatment and no other? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

TIME+ COMMAND darshanmody> 27303 root 20 0 42500 6124 2740 S 10.3 0.2 0:43.23 openssl darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -Original Message- darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.

Re: [openssl-dev] License change agreement

correctly, *any* license change faces the exact same problem. My interpretation of what you say is that unless we can successfully reach all contributors, no exception, we're stuck with the current license, probably for life. Am I reading you correctly? -- Richard Levitte levi...@o

Re: [openssl-dev] Memory leak in application when we use ECDH

I think that Matt is asking for example code that exhibits this leak. You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch. The reason is that we can't know what assumptions you're going with in your callback or application, so if we code an example

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

ed all applications to have converted the moment we declared our 1.1.0 release stable? That will not happen... as far as we've observed, most are hardly even looking before we've made a stable release (which I agree is unfortunate). Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL

Re: [openssl-dev] Openssl 1.0.2 snap STABLE 20170311 issue

Fixed: commit 6fe43af8d77b119f8af913c284149bca482ee58c Author: Richard Levitte <levi...@openssl.org> Date: Sat Mar 11 11:19:20 2017 +0100 Revert "Use the callbacks from the SSL object instead of the SSL_CTX object" This shouldn't h

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

steffen> i really would have sworn that it worked in the past. I was actually surprised to find this undocumented. I could have sworn I'd done so, but apparently, I only did in a commit message: commit fad599f7f147ee71e5581211fb654c2c8c491cd8 Author: Richard Levitte <levi...@open

Re: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations

or the GNU toolchain, I'd recommend configuring with something like this (from memory, I might be fuzzy in the details): -Wl,--enable-new-dtags -rpath '$(LIBRPATH)' LIBRPATH is a convenience Makefile variable that gets correctly set to the configured shared library installation directory, mean

Re: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

I'd suggest prefixing the PR subject with "code-health:" or "[code-health]", just like work in progress is prefixed "WIP:" or "[WIP]" Cheers, Richard In message <9ecbf19a-3239-440c-b874-b959b6bb9...@akamai.com> on Mon, 27 Feb 2017 14:54:09 +, "Short, Todd" said: tshort>

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

util/ssleay.num > /tmp/ssleay.num.diff) /home/levitte/gitwrk/openssl.net/official/1.0.1 HEAD detached at OpenSSL_1_0_1u nothing to commit, working tree clean /home/levitte/gitwrk/openssl.net/official/1.0.2 HEAD detached at OpenSSL_1_0_2k nothing to commit, working tree clea

Re: [openssl-dev] Openssl 1.0.2 snapshot bug

Yup, we have a fix coming up: https://github.com/openssl/openssl/pull/2713 In message <20170223125425.ga77...@doctor.nl2k.ab.ca> on Thu, 23 Feb 2017 05:54:25 -0700, The Doctor said: doctor> doctor> Script started on Thu Feb 23 05:41:55 2017 doctor> You have mail.

[openssl-dev] STORE, the continued story

would be interesting, and so would the PKCS#11 one. Also, if there's an LDAP engine to adapt, that would be an interesting project as well. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list

Re: [openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

In message <589b86c1.10...@roumenpetrov.info> on Wed, 08 Feb 2017 22:59:45 +0200, Roumen Petrov <open...@roumenpetrov.info> said: openssl> Hi Richard, openssl> openssl> Richard Levitte wrote: openssl> > Hi, openssl> > openssl> > I've some ponderings t

[openssl-dev] (future) STORE vs X509_LOOKUP_METHOD by_dir

ke to see the STORE module itself become part of 1.1.1, but a new key store to replace our current rehash links will obviously have to wait 'til 1.2.0. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openss

Re: [openssl-dev] [openssl-commits] UI_METHOD

In message <9da4cbdc-7437-b942-0d2e-e05808cd1...@akamai.com> on Thu, 12 Jan 2017 11:17:10 -0600, Benjamin Kaduk <bka...@akamai.com> said: bkaduk> On 01/11/2017 11:27 AM, Richard Levitte wrote: bkaduk> bkaduk> The branch master has been updat

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

around somewhere that would be compatible with OpenSSL’s EVP_PKEY tshort> mechanism (similar to Poly1305, in that it needs a key). tshort> -- tshort> -Todd Short tshort> // tsh...@akamai.com tshort> // "One if by land, two if by sea, three if by the Internet." tshort> tshort

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

1 Jan 2017 15:34:58 +0100 (CET), Richard Levitte <levi...@openssl.org> said: levitte> In message <1e19cdfea8224717b3eee11e2d8ac...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 11 Jan 2017 03:13:39 +, "Salz, Rich" <rs...@akamai.com> said: levitte> levit

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

us any advantage over OpenSSL_LH_strhash for our uses. Cheers, Richard (*) Strictly speaking, it's a modified version that takes a length and tolerates all 8-bit bytes, including 0x00. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- o

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

l%E2%80%93Vo_hash_function I'm a little worried about the zero hash value issue mentioned here: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#Non-cryptographic_hash michel.sales> https://en.wikipedia.org/wiki/CityHash Google has replaced that with FarmHash acco

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

Benjamin Kaduk <bka...@akamai.com> skrev: (10 januari 2017 20:19:21 CET) >On 01/10/2017 12:31 PM, Richard Levitte wrote: >> >> Benjamin Kaduk <bka...@akamai.com> skrev: (10 januari 2017 18:48:32 >CET) >>> On 01/09/2017 10:05 PM, Salz, Rich wrot

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

Benjamin Kaduk skrev: (10 januari 2017 18:48:32 CET) >On 01/09/2017 10:05 PM, Salz, Rich wrote: >> >> Should we move to using SIPHash for the default string hashing >> function in OpenSSL? It’s now in the kernel >> https://lkml.org/lkml/2017/1/9/619 >>

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

In message <1483487075.2464.59.ca...@hansenpartnership.com> on Tue, 03 Jan 2017 15:44:35 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said: James.Bottomley> On Tue, 2017-01-03 at 12:19 +0100, Richard Levitte wrote: James.Bottomley> > ⁣There seems to b

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

⁣There seems to be some confusion here. James, I understand the tpm engine as an external project, not part of the OpenSSL source proper and not intended to be. However, openssl-dev@openssl.org is a list focused on the development of OpenSSL proper. That makes it a bit odd to discuss the tpm

Re: [openssl-dev] Linker error when adding new cipher in crypto folder

here… rschm2> rschm2> Any help is much appreciated! On way is to, as already mentioned, edit util/libcrypto.num. The other is to edit util/mkdef.pl and then run 'make update'. In mkdef.pl, you'll find a bunch of lines like this: $crypto.="include/openssl/whatever.h" Simply add a l

Re: [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

2 emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL-- v2 only parent [2] IMPLICIT INTEGER OPTIONAL-- v2 only publicKey [3] IMPLICIT OCTET STRING OPTIONAL -- v2 only privateKey OCTET STRING } Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

In message <20161222.225335.92995302056231655.levi...@openssl.org> on Thu, 22 Dec 2016 22:53:35 +0100 (CET), Richard Levitte <levi...@openssl.org> said: levitte> In message <e6400041-6133-8b74-2ff9-043ec6dcb...@gmail.com> on Thu, 22 Dec 2016 13:33:16 -0800, Joey Yandle &l

Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

t's not stricly necessary to add them statically in the libcrypto code. They can be added dynamically by the engine by calling OBJ_create() with the correct arguments. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mail

Re: [openssl-dev] Add a new algorithm in "crypto" dir, how to add the source code into the build system

ctly necessary) and the TLS ciphersuites (I don't think that can be done dynamically at all, at least yet). https://github.com/gost-engine/engine Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list T

Re: [openssl-dev] Cross compiling openssl for an old ARM environment - howto?

We are saying that we don't support 16-bit platforms and haven't really done so for a long time. The C-only version is no exception. However, the response was that 32- and 64-bit operations and numbers are supported on that device, so it should still be possible to play with. Cheers, Richard

Re: [openssl-dev] Cross compiling openssl for an old ARM environment - howto?

rsalz> I don't think openssl ever really ran on 16bit. It certainly doesn't any more. It did, though, a long time ago. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

be PIN or openssl> something different. openssl> Please use more generic description. openssl> For instance engine callback is defined in generic way - ui_method and openssl> its callback_data. I see what you mean. Just did the improvement. -- Richard Levitte levi...@openssl.or

[openssl-dev] STORE [was: [RFC v2 2/2] pem: load engine keys]

In message <584d77cb.7090...@roumenpetrov.info> on Sun, 11 Dec 2016 17:59:07 +0200, Roumen Petrov <open...@roumenpetrov.info> said: openssl> HI Richard, openssl> openssl> Richard Levitte wrote: openssl> > In message<58472e4f.3010...@roumenpetrov.info> on Tue

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

Roumen Petrov <open...@roumenpetrov.info> skrev: (11 december 2016 17:31:10 CET) >Hi Richard, > >Richard Levitte wrote: >> In message<20161206.223057.237264374331072901.levi...@openssl.org> >on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard >Levitte<levi.

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

In message <20161206.223057.237264374331072901.levi...@openssl.org> on Tue, 06 Dec 2016 22:30:57 +0100 (CET), Richard Levitte <levi...@openssl.org> said: levitte> That being said, it should certainly be easy enough to change the levitte> appropriate places to make sure hea

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

In message <58472e4f.3010...@roumenpetrov.info> on Tue, 06 Dec 2016 23:31:59 +0200, Roumen Petrov <open...@roumenpetrov.info> said: openssl> Hi Richard, openssl> openssl> Richard Levitte wrote: openssl> > [SNIP] openssl> > James.Bottomley> 1. We agree

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

In message <1481043672.4406.22.ca...@hansenpartnership.com> on Tue, 06 Dec 2016 09:01:12 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said: James.Bottomley> On Tue, 2016-12-06 at 17:47 +0100, Richard Levitte wrote: James.Bottomley> > In message &

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

In message <1481042048.4406.14.ca...@hansenpartnership.com> on Tue, 06 Dec 2016 08:34:08 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said: James.Bottomley> On Tue, 2016-12-06 at 15:12 +0100, Richard Levitte wrote: James.Bottomley> > In message &

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

In message <1480697558.2410.33.ca...@hansenpartnership.com> on Fri, 02 Dec 2016 08:52:38 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said: James.Bottomley> On Thu, 2016-12-01 at 09:30 +0100, Richard Levitte wrote: James.Bottomley> > James.Bottoml

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

In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 13:57:12 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Just let me shamelessly mention my STORE effort agai

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

James Bottomley <james.bottom...@hansenpartnership.com> skrev: (1 december 2016 07:36:26 CET) >On Thu, 2016-12-01 at 01:38 +0100, Richard Levitte wrote: >> >> James Bottomley <james.bottom...@hansenpartnership.com> skrev: (1 >> december 2016 00:42:09 CET) >&

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

James Bottomley <james.bottom...@hansenpartnership.com> skrev: (1 december 2016 00:42:09 CET) >On Thu, 2016-12-01 at 00:22 +0100, Richard Levitte wrote: >> This patch doesn't fit the rest... > >I'm not quite sure I follow why. It casts bp to const char *. That

Re: [openssl-dev] [RFC v2 2/2] pem: load engine keys

This patch doesn't fit the rest... Generally speaking, I am unsure about your solution. It seems like hack to fit a specific case where something more general could be of greater service to others as well. Cheers Richard On November 30, 2016 4:27:49 PM GMT+01:00, James Bottomley

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

In message <1479993631.8937.91.ca...@infradead.org> on Thu, 24 Nov 2016 13:20:31 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote: dwmw2> > That being said, though, your recommendation should probably sp

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

Richard Levitte <levi...@openssl.org> skrev: (23 november 2016 22:23:18 CET) > > >David Woodhouse <dw...@infradead.org> skrev: (23 november 2016 19:42:29 >CET) >>On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote: >>> >>> > FWIW I am perfect

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

David Woodhouse skrev: (23 november 2016 19:42:29 CET) >On Wed, 2016-11-23 at 17:00 +, Salz, Rich wrote: >> >> > FWIW I am perfectly content for applications *not* to automatically >work >> > with such keys. Making the user jump through extra hoops to use >them >> >

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

ething. rsalz> The point is, it is not openssl that is doing that. Speaking of ambiguity, I was thinking of having my 'file' scheme loader try all d2i's and having it "throw up its hands" if it found more than one matching. STOREerr(..., STORE_R_MABIGUOUS_CONTENT) type of thing... The

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

the application "we think it's a FOO" guessing? What's the application going to do, go "nh, methinks it's a BAR" and try to decode the blob as that (and most probably fail) rather than FOO? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://

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

spec) exactly what you didn't want to see, no matter if the file was PEM or raw DER? -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

Change of subject, this part of the thread isn't so much TPM any more... In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 13:57:12 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: dwmw2>

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

le spec *will* have to have an indication of what type of content it is. If we're thinking in URI terms, I could think of a contraption like file:whatever.pem?t=tsskeyblob ... or dare I say it, tpmkey:file=whatever.pem (David is so going to hate me ;-) ...) Cheers, Richard -- Richard L

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

In message <1479894913.8937.58.ca...@infradead.org> on Wed, 23 Nov 2016 09:55:13 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > dwmw2> > dwmw2> So maybe it's just &

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

In message <1479889418.8937.54.ca...@infradead.org> on Wed, 23 Nov 2016 08:23:38 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Actually, I agree with this, and that goes a

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

t; such a bug exists, doing opportunistic format detection the better James.Bottomley> guarantor of overall system security because if such a bug is found, it James.Bottomley> would have to be fixed within openssl to everyone's benefit. I agree with that sentiment. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

What you're gonna do there is double part of the work. But, what I get from you is "what if a octet stream matches two different ASN.1 types? Is that it? -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To uns

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

t; And this part worries me. I do not think a "security library" should be guessing. It does this by trying to interpret the blob against known ASN.1 definitions, and will only succeed when there's a complete match. I'm not terribly worried... -- Richard Levitte levi

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

that can be returned, so one for a EVP_KEY, one for a X509, one for a X509_CRL, and so on and so forth). That would make it possible for an engine to declare its own handler during the binding call, along with all other information it feeds back to libcrypto. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

In message <1479830167.8937.43.ca...@infradead.org> on Tue, 22 Nov 2016 15:56:07 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: dwmw2> > In message <1479815862.8937.22.ca...@infradead.org> on Tue,

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

In message <1479829450.2376.10.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 07:44:10 -0800, James Bottomley <james.bottom...@hansenpartnership.com> said: James.Bottomley> On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: James.Bottomley> > In message &

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

at the spec (page 151 in http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errata_A-final.pdf), and am a bit confused by the TssBlobType type. Which is it in practice, an ENUMERATED or an INTEGER? -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.ope

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

In message <1479823032.8937.37.ca...@infradead.org> on Tue, 22 Nov 2016 13:57:12 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Just let me shamelessly mention my STORE effort agai

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

OpenSSL internals now, aren't we? David, correct me if I got you wrong. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 13:12:14 +, David Woodhouse <dw...@infradead.org> said: dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Not sure I follow...  'file=/foo/bar/key.

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

o call different functions for PEM vs. DER files anyway. Just let me shamelessly mention my STORE effort again ;-) Among others, it does attempt to solve that very problem (in the 'file' scheme handler). -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.ope

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

user, it's just a string. For all I care, the URI could just as well be 'tpmkey:id=L2Zvby9iYXIva2V5LnBlbQ==' That doesn't say anything about the contents of /foo/bar/key.pem, not more than file:/foo/bar/key.pem does, or even if there actually is a file /foo/bar/key.pem. Maybe I misunderstand w

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

ng. We can use the pem James.Bottomley> header concept to extend this format if it becomes necessary. My vote goes to a URI based spec rather than bastardising PEM files. I understand this kinda throws years of developmemt out the window, but there you have it. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

gt;   Original Message   uri> From: David Woodhouse uri> Sent: Monday, November 21, 2016 08:43 uri> To: Richard Levitte; openssl-dev@openssl.org uri> Reply To: openssl-dev@openssl.org uri> Cc: James Bottomley uri> Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling

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

If I understand correctly, the intention is to avoid having to use ENGINE_load_private_key() directly or having to say '-keyform ENGINE' to the openssl commands, and to avoid having to remember some cryptic key identity to give with '-key'. Instead of all that, just give the name of a .pem file

Re: [openssl-dev] openssl enc changed behaviour between 1.1.0 and earlear

In message <20161104205933.gw7pyvclnmdkv...@breakpoint.cc> on Fri, 4 Nov 2016 21:59:33 +0100, Sebastian Andrzej Siewior <openssl-...@ml.breakpoint.cc> said: openssl-dev> On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote: openssl-dev> > openssl-dev> >

  1   2   3   4   5   6   7   8   9   10   >