[openssl-dev] Padding for RSA signatures

Hi, I am playing around with RSA signatures with different padding and have some questions. I have my sample code below for reference. It's in Swift (but it should still be close enough to C to be readable). Also in Swift, some of the complex macros in OpenSSL have to be broken down

Re: [openssl-dev] Potential timing problems in OpenSSL RSA implementation

Hi, > I'd like to stress that this is highly speculative, it may very well be > that this is not exploitable in any practical way. But I thought it's > important enough that it should be public knowledge. (Also "This leaves > a small timing channel, [...] but it is not believed to be large >

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

onfused what you mean here, since my engine doesn't "own" any instances > of an RSA struct, it just has a static instance of RSA_METHOD struct defined. > So therefore my engine never "sets" public or private key components. It just > uses the modexp functions to wri

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

engine doesn't "own" any instances of an RSA struct, it just has a static instance of RSA_METHOD struct defined. So therefore my engine never "sets" public or private key components. It just uses the modexp functions to write the public/private data (contained in the RSA

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

On Mon, Aug 28, 2017, Brett R. Nicholas wrote: > > The rsa_mod_exp function is only called for private key operations. You > > can't > > tell if it is a private encrypt or a private decrypt though but that > > shouldn't matter because the operation performed at that level is the same > > for >

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

on). Brett From: openssl-dev <openssl-dev-boun...@openssl.org> on behalf of Dr. Stephen Henson <st...@openssl.org> Sent: Sunday, August 27, 2017 6:45 PM To: openssl-dev@openssl.org Subject: Re: [openssl-dev] confusion with rsa_meth_st in a custom RSA engine On

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

rsa_mod_exp(), the only way I can think of determining whether the function > has been called by private_encrypt/decrypt() or public_encrypt/decrypt would > be to check if the p and q fields of the RSA *rsa struct passed into the > function are NULL? But I can't tell from the source co

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

est now, though. @Richard, I've looked at the source like you suggested. One more question..quoting your reply below: > That flag means that the standard public/private encrypt/decrypt won't > try to access the p, q, dmp1 and iqmp components of the RSA structure, > i.e. the

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

In message <bn3pr03mb1462808dc39e3a2a1386aedbe0...@bn3pr03mb1462.namprd03.prod.outlook.com> on Wed, 23 Aug 2017 01:50:04 +, "Brett R. Nicholas" <brett.r.nicholas...@dartmouth.edu> said: > I am trying to develop a engine for a custom RSA hardware accelerator, an

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

penssl-dev-ow...@openssl.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openssl-dev digest..." Today's Topics: 1. Upgrading OpenSSL (Leon Brits) 2. Re: confusion with rsa_meth_st in a custom RSA engine (Douglas E Engert) 3. R

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

But You will have to populate the key with the public parts of the key. On 8/22/2017 8:50 PM, Brett R. Nicholas wrote: I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation. Some context: for encryption, my

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

I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation. Some context: for encryption, my accelerator takes as inputs the base, public exponent, and modulus, and returns the resulting ciphertext

Re: [openssl-dev] Problem displaying rsa private key.

modulus:     00:cd:a7:cc:46:17:97:e6:89:e7:bb:36:e2:4d:f0: Without the leading zero, the 0xCD would be interpreted as a negative number according to ASN1/DER rules. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Problem displaying rsa private key.

An rsa private key may be displayed using the following command (on MS Windows): openssl rsa -inform PEM -in E:\Temp\private.pem -text -noout When I execute this command I get the following partial results: modulus: 00:cd:a7:cc:46:17:97:e6:89:e7:bb:36:e2:4d:f0: 32:1c:e7:e2:6f:18:de:80

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

> Doesn't the fact that AES-192 seems to be more resistant against related key > attacks than AES-256 "in a world of 2^50 keys" count as an argument for > inclusion? > > A related question, is the fact that AES-192 is more resistant to related key > attacks caused by the fact that it uses a key

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

Hello Rich, On Mon, 2017-01-09 at 19:52 +, Salz, Rich wrote: > AES 192 has been discussed at various times in the IETF mailing lists > (see CFRG and TLS for most likely places). Here's one posting: > https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html > > My short summary is

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

> Has anyone ever attempted to get such ciphers included in that IANA list? It > seems AES-192 is being treated rather stepmotherly in the standards. AES 192 has been discussed at various times in the IETF mailing lists (see CFRG and TLS for most likely places). Here's one posting:

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

Hello Viktor, On Mon, 2017-01-09 at 19:25 +, Viktor Dukhovni wrote: > There are no AES-192 ciphersuites in the IANA TLS registry: > > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 > > so these cannot (interoperably) be used with TLS. Right. I

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

On Mon, Jan 09, 2017 at 07:57:43PM +0100, Leonard den Ottolander wrote: > Considering that AES-192 seems to be very resistant against related key > attacks (http://eprint.iacr.org/2009/317) and the algorithm is already > available in the openssl code I am trying to expose the AES-192 > ciphers.

[openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

apps tests) it chokes with a client error: ERROR in CLIENT 140069906728640:error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available:s23_clnt.c:502: TLSv1.2, cipher (NONE) (NONE) 1 handshakes of 256 bytes done Failed DHE-RSA-

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

how gnome keyring currently does it. You want it *exactly* how GKR (or the other examples I gave) do it, with the sole exception that RSA keys can be wrapped by the TPM instead. I had also been talking about using Skylake's SGX software enclaves to do a similar augmentation to software tokens. >

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

On Wed, 2016-12-14 at 17:05 +, David Woodhouse wrote: > On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote: > > > Hm, this seems odd. If something is stored in a file then > > > exposing it through PKCS#11 doesn't make sense at all. Do not > > > attempt to use PKCS#11 for any file

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

On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote: > > Hm, this seems odd. If something is stored in a file then exposing it > > through PKCS#11 doesn't make sense at all. Do not attempt to use > > PKCS#11 for any file access. > > OK, so the horse has already left the stable on that one

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

On Wed, 2016-12-14 at 09:07 +, David Woodhouse wrote: > On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote: > > > > So the proposal is to have a TPM specific value for > > PrivateKeyAlgorithm (which would have to be proposed as an OID) and > > use PrivateKeyInfo for the key? That

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

On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote: > > So the proposal is to have a TPM specific value for PrivateKeyAlgorithm > (which would have to be proposed as an OID) and use PrivateKeyInfo for > the key?  That could be made to work. Right. > The slight fly in the ointment that's

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

On Tue, 2016-12-13 at 22:28 +, David Woodhouse wrote: > On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote: > > The reason for that is that the PEM forms which contain > > the key algorithm in the PEM header were considered legacy types > > and new methods should use PKCS#8 instead.

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

On Tue, Dec 13, 2016, David Woodhouse wrote: > On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote: > > The reason for that is that the PEM forms which contain > > the key algorithm in the PEM header were considered legacy types and new > > methods > > should use PKCS#8 instead. So there

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

On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote: > The reason for that is that the PEM forms which contain > the key algorithm in the PEM header were considered legacy types and new > methods > should use PKCS#8 instead. So there was no way to set legacy PEM decoders to > discourage

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

On Tue, Dec 13, 2016, Dr. Stephen Henson wrote: > > So if we wanted to go down this route all that is needed to get a form of this > functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD. > Note however that this currently assumes the data between the PEM headers is base64

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

ustom PEM key forms actually largely already exists in OpenSSL so significant changes are not required if we want to go down this route. To see what I mean consider an existing format such as an RSA key which has -BEGIN RSA PRIVATE KEY- at the start. When the PEM file is parsed in PEM

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

On Fri, 2016-12-02 at 08:03 -0800, James Bottomley wrote: > >   Most likely (and hopefully) the latter keys will be handled over > > PKCS#11 rather than directly. > > I have reservations about scaling pkcs11 into a multi-tenant > environment, but I agree, in principle it is possible.  I'm looking

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

On Fri, 2016-12-02 at 14:04 +0100, Richard Levitte wrote: > It does now for everything but PKCS#12 files.  Those are trickier, and > I'm working on it. Nice. > Speaking of...  do you mind if I pilfer from that Makefile.am for our > tests? Not at all; please do. You're welcome to use anything in

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

On Thu, 2016-12-01 at 12:49 +0100, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote: > > > > > The point here is that because there's a pem file > > > representation of the > > > > key, it can be used anywhere a PEM file can be *without* > > >

[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 said: dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Just let me shamelessly mention my STORE effort again ;-) dwmw2> > Among others,

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

On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote: > > > The point here is that because there's a pem file > > representation of the > > > key, it can be used anywhere a PEM file can be *without* > > having > > to tell > > > openssl what the engine is (the PEM guards being

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

ely unloaded as soon as you close the TPM connection. The engine code to use them is here https://sourceforge.net/p/trousers/openssl_tpm_engine the TPM connection is from engine init to engine finish and once the key is loaded, it stays in the TPM until engine finish. create_tpm_key is what take

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

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

On Wed, 2016-11-30 at 21:18 +, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" < > openssl-dev-boun...@openssl.org on behalf of > james.bottom...@hansenpartnership.com> wrote: > > > One of the principle problems of using TPM based

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

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

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. This proposal adds a generic method for handling file based engine keys that can be loaded as PEM files. Integration into the PEM loader requires a BIO based

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

S#8 standards mandated its use!) > > They predate it by several years. At the time they were published very > few could conceive how UTF-8/unicode would look like. The original PKCS documents predated the publication of Unicode by a few months in 1991. Sure, *NOBODY* could have predicted

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

On Thu, 2016-11-24 at 14:26 +0100, Nikos Mavrogiannopoulos wrote: > On Wed, Nov 23, 2016 at 10:10 PM, David Woodhouse wrote: > > > Locales is not the only thing you have to worry about. UTF-8 and UTF-16 > > > can express the same string in various (different) ways, so they

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 said: dwmw2> On Wed, 2016-11-23 at 22:33 +0100, Richard Levitte wrote: dwmw2> > That being said, though, your recommendation should probably specify dwmw2> > (after

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

phic application again in their life. 5.1. PKCS#1 and other native ASN.1 encodings Applications MUST support unencrypted private keys: o RSA keys in PKCS#1 form as defined by [RFC2437] o DSA keys in the ASN.1 form defined by OpenSSL and documented in Appendix B (if DSA keys are

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

rk"  But only for >>some keys. >>> >>> Part of my I am opposed to guessing. >> >>For me it's the other way round. Magically detecting *that* particular >>perfectly valid PKCS#1 RSA key is actually intended for the gem engine >>would indeed be gu

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

ump through extra hoops to use >them >> > would be perfectly fine in my book. >> >> oh I see.  "Users shouldn't care, it should just work"  But only for >some keys. >> >> Part of my I am opposed to guessing. > >For me it's the other way round.

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

> On Tue, 2016-11-22 at 15:49 +, David Woodhouse wrote: >> On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote: >> > The more interesting part is when it tries to load files it guesses >> > are raw DER.  It's currently only trying a few chosen content >> > types, >> > I'm happy to add

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

;Users shouldn't care, it should just work"  But only for some > keys. > > Part of my I am opposed to guessing. For me it's the other way round. Magically detecting *that* particular perfectly valid PKCS#1 RSA key is actually intended for the gem engine would indeed be guessing. It's

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

> FWIW I am perfectly content for applications *not* to automatically work > with such keys. Making the user jump through extra hoops to use them > would be perfectly fine in my book. oh I see. "Users shouldn't care, it should just work" But only for some keys. Part of my I am opposed to

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

On Wed, 2016-11-23 at 14:41 +, Peter Sylvester Edelweb wrote: > > An exemple used by the 'gem' engine. > > openssl rsa -in key.pem -text > Private-Key: (4096 bit) > modulus: >     00:c4:d9:a4:27:ea:17:10:09:35:79:89:fc:10:1f: >     01:39:34:b7:23:93:5a:61:05:af:b1:0

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

[subject change] In message <3d837eb338bb47a68938676967ed1...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 14:41:14 +, "Salz, Rich" said: rsalz> rsalz> > Essentially, you're suggesting that we split out the matching part of the d2i rsalz> > functions and

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

On Wed, 2016-11-23 at 10:53 +, David Woodhouse wrote: > On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote: > > > > Right... > > > > But then, embedding everything in an OCTET STRING isn't exactly a > > novel idea either. How do we discern a DER encoded TSS KEY BLOB > > from whatever

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

On Wed, 2016-11-23 at 15:21 +0100, Richard Levitte wrote: > In message <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016 > 13:33:45 +, David Woodhouse said: > > dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote: > dwmw2> > > But, what I get from you

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

On 11/23/2016 02:33 PM, David Woodhouse wrote: > If I make a new object type which looks like a PKCS#1 RSA key but is > actually something completely different, it's *already* likely that > OpenSSL will load that new object as if it was an RSA key in some > cases. > An exemple u

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

> Essentially, you're suggesting that we split out the matching part of the d2i > functions and put that to good use. Or do you have some other idea, along > the lines if magic? NO. I am suggesting add one new routine that tries varies "convert to native" and returns which conversion worked.

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

In message <2360f57bb7504a328e5517ac92e19...@usma1ex-dag1mb1.msg.corp.akamai.com> on Wed, 23 Nov 2016 13:51:03 +, "Salz, Rich" said: rsalz> rsalz> > Why is it different if we do exactly that in libcrypto? rsalz> rsalz> Because *we* are not guessing. We are telling the

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

In message <1479908025.8937.74.ca...@infradead.org> on Wed, 23 Nov 2016 13:33:45 +, David Woodhouse said: dwmw2> On Wed, 2016-11-23 at 13:13 +, Salz, Rich wrote: dwmw2> > > But, what I get from you is "what if a octet stream matches two different dwmw2> > > ASN.1

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

On Wed, 2016-11-23 at 14:26 +0100, Richard Levitte wrote: > > Quite frankly, that's a though that should go back to David and his > demand of automatic detection.  If anyone would *ever* create a raw > DER file holding a tss OCTET STRING, then the file spec *will* have to > have an indication of

[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 said: dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Just

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

In message on Wed, 23 Nov 2016 13:13:05 +, "Salz, Rich" said: rsalz> rsalz> > Uh... the d2i functions are already both in one. Are you saying they rsalz> > should be split in two, one part that

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

> Uh... the d2i functions are already both in one. Are you saying they > should be split in two, one part that does all the checking and the other that > just decodes, trusting that all checks are already done? What you're gonna > do there is double part of the work. Well, not double, but

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

On Tue, 2016-11-22 at 15:26 -0500, Thomas Francis, Jr. wrote: > On 11/22/16 2:37 PM, David Woodhouse wrote: > > And the locale / character set issue is not relevant here. ASN.1 is > > binary, PEM is ASCII. > PEM should be ASCII; in practice it is not necessarily ASCII.  There are > several

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

There is at least one real life HSM engine, that encodes numerical identifiers as "pseudo prime numbers", you end up with a RSA private key that has 1 and 2 prime numbers? No new ASN.1 Best On 11/23/2016 11:47 AM, Richard Levitte wrote: > In message <1479894913.8937.58.ca.

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

On Wed, 2016-11-23 at 11:47 +0100, Richard Levitte wrote: > > Right... > > But then, embedding everything in an OCTET STRING isn't exactly a > novel idea either.  How do we discern a DER encoded TSS KEY BLOB from > whatever else that had the same "novel" idea? An OCTET STRING is an > OCTET

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 said: dwmw2> On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > dwmw2> > dwmw2> So maybe it's just "content types" that we have handlers for,

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

On Wed, 2016-11-23 at 09:56 +0100, Richard Levitte wrote: > > > dwmw2> So maybe it's just "content types" that we have handlers for, each with > dwmw2> an optional PEM tag for matching, *and* an optional match function > dwmw2> which is given the parsed ASN.1 and checks if it's a match. > > I'm

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

On Wed, 2016-11-23 at 09:39 +0100, Tomas Mraz wrote: > > I also would not be too much worried - the API call should not be > completely universal - the application should know whether it is > loading a certificate or private key. It should just be able to use a > single call to load a certificate

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 said: dwmw2> On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Actually, I agree with this, and that goes along with how our PEM dwmw2> >

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

On St, 2016-11-23 at 00:03 +0100, Richard Levitte wrote: > In message <021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp > .akamai.com> on Tue, 22 Nov 2016 18:03:31 +, "Salz, Rich" akamai.com> said: > > rsalz> It is already possible to write a utility library that tries >

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

On Tue, 2016-11-22 at 18:06 +0100, Richard Levitte wrote: > > Actually, I agree with this, and that goes along with how our PEM > routines work (specifically, PEM_X509_INFO_read_bio()), it just > treats the data as an octet string and hands it down to a d2i routine > of choice, with a pointer to

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

In message <1479839148.2376.31.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 10:25:48 -0800, James Bottomley said: James.Bottomley> On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote: James.Bottomley> > > > It does this by trying to interpret the blob

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

In message <021a5d5b885845f5ab79c4420232e...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 18:03:31 +, "Salz, Rich" said: rsalz> It is already possible to write a utility library that tries rsalz> everything in turn, and returns an enumeration that says "seems

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

On 11/22/16 2:37 PM, David Woodhouse wrote: On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote: And the locale / character set issue is not relevant here. ASN.1 is binary, PEM is ASCII. PEM should be ASCII; in practice it is not necessarily ASCII. There are several products that

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

On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote: > > That's not the proposal. The proposal is to use PEM form because we can > > make it uniquely self describing using the guard tags which obviates the > > problem above. > > Well that's what you want. David wants more than that :) S'true

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

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

> That's not the proposal. The proposal is to use PEM form because we can > make it uniquely self describing using the guard tags which obviates the > problem above. Well that's what you want. David wants more than that :) > On the larger issue of non-self describing formats like ASN.1: if

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

On Tue, 2016-11-22 at 18:03 +, Salz, Rich wrote: > > > 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... > > I am. With locales and UTF8, the old simple days of

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

> > 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... I am. With locales and UTF8, the old simple days of text/binary are probably long gone. And if any ASN.1 definition has

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

On Tue, 2016-11-22 at 18:46 +0100, Richard Levitte wrote: > In message > <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on > Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich" said: > > rsalz> > The more interesting part is when it tries to load files it

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

In message <489af892b16b43ee9a7009ffe52db...@usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 22 Nov 2016 17:40:54 +, "Salz, Rich" said: rsalz> > The more interesting part is when it tries to load files it guesses are raw DER. rsalz> rsalz> And this part worries me. I do

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

> The more interesting part is when it tries to load files it guesses are raw > DER. And this part worries me. I do not think a "security library" should be guessing. -- 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 <1479833048.2376.21.ca...@hansenpartnership.com> on Tue, 22 Nov 2016 08:44:08 -0800, James Bottomley said: James.Bottomley> On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote: James.Bottomley> > On Tue, 2016-11-22 at 17:21 +0100, Richard

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

On Tue, 2016-11-22 at 16:28 +, David Woodhouse wrote: > On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote: > > > > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything > > else is > > dwmw2> redundant anyway. > > > > Oh! Ok, that makes things much simpler (at least in

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

On Tue, 2016-11-22 at 17:21 +0100, Richard Levitte wrote: > > dwmw2> It is *only* the OCTET STRING of the blob itself. Everything else is > dwmw2> redundant anyway. > > Oh!  Ok, that makes things much simpler (at least in a way) Kind of. But then again, there's an argument that it was none of

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 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, 22 Nov 2016 11:57:42 +,

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

On Tue, 2016-11-22 at 17:14 +0100, Richard Levitte wrote: > > I'm sorry, I have obviously had you a bit confused.  What I'm > currently interested in is decoding the content of a 'TSS KEY BLOB' > PEM file, and I assume that's a TssBlob type, yeah? No, it's not. (Sorry!) -- dwmw2 smime.p7s

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

On Tue, 2016-11-22 at 07:44 -0800, James Bottomley wrote: > > > I'm just having a look at the spec (page 151 in > > http://www.trustedcomputinggroup.org/wp-content/uploads/TSS_1_2_Errat > > a_A-final.pdf), and am a bit confused by the TssBlobType type.  Which > > is it in practice, an ENUMERATED

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

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 > 11:57:42 +, David Woodhouse said: > > dwmw2> Besides, it requires files in the form described by the Portable Data > dwmw2> section of

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

On Tue, 2016-11-22 at 16:07 +0100, Richard Levitte wrote: > In message > on > Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich" said: > > rsalz> > dwmw2> It should work out what the contents are for *itself*.

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

On Tue, 2016-11-22 at 16:14 +0100, Richard Levitte wrote: > The more interesting part is when it tries to load files it guesses > are raw DER.  It's currently only trying a few chosen content types, > I'm happy to add more as time goes.  However, I suspect that nothing > in your test suite will

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

On Tue, 2016-11-22 at 16:32 +0100, Richard Levitte wrote: > In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov > 2016 11:57:42 +, David Woodhouse said: > > dwmw2> Besides, it requires files in the form described by the > Portable Data > dwmw2> section of

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

In message <1479815862.8937.22.ca...@infradead.org> on Tue, 22 Nov 2016 11:57:42 +, David Woodhouse said: dwmw2> Besides, it requires files in the form described by the Portable Data dwmw2> section of the TSS (1.2) spec. That's a SEQUENCE with a blob type dwmw2> (which

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 said: dwmw2> On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Just let me shamelessly mention my STORE effort again ;-) dwmw2> > Among others,

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

In message on Tue, 22 Nov 2016 14:42:35 +, "Salz, Rich" said: rsalz> > dwmw2> It should work out what the contents are for *itself*. Whether rsalz> > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs,

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

> dwmw2> It should work out what the contents are for *itself*. Whether > dwmw2> they be PEM, DER, PKCS#n, TPM-wrapped blobs, or anything else. I disagree with this approach, but that's just my opinion. I am worried about "keep trying something until it works" because you'll get strange errors

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

On Tue, 2016-11-22 at 14:18 +0100, Richard Levitte wrote: > > Just let me shamelessly mention my STORE effort again ;-) > Among others, it does attempt to solve that very problem (in the > 'file' scheme handler). Neat. Note that I have a ready-made test suite for you in OpenConnect:

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

On Tue, 2016-11-22 at 14:32 +0100, Richard Levitte wrote: > In message <1479820334.8937.31.ca...@infradead.org> on Tue, 22 Nov 2016 > 13:12:14 +, David Woodhouse said: > > dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: > dwmw2> > > dwmw2> > Not sure I

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 said: dwmw2> On Tue, 2016-11-22 at 14:06 +0100, Richard Levitte wrote: dwmw2> > dwmw2> > Not sure I follow...  'file=/foo/bar/key.pem' is just a path / dwmw2> >

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

In message <1479820158.8937.29.ca...@infradead.org> on Tue, 22 Nov 2016 13:09:18 +, David Woodhouse said: dwmw2> On Tue, 2016-11-22 at 12:54 +, Salz, Rich wrote: dwmw2> > > would much rather have seen a patch where OpenSSL's PEM module is dwmw2> > > tought to

  1   2   3   4   5   6   7   8   >