Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Dr. Stephen Henson]

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> Thanks for the hint.  The problem is fixed.
> 
> Server was setting:
> 
> if (SSL_CTX_set1_groups_list(ctx, "X25519:P-256") == 0) {
> //
> }
> 
> The call succeeds.
> 
> But the old TLS 1.2 code was setting:
> 
> int nid = NID_X9_62_prime256v1;
> EC_KEY* ecdh = EC_KEY_new_by_curve_name(nid);
> if (ecdh == NULL)
> {
>//error
> }
> SSL_CTX_set_tmp_ecdh(ctx, ecdh);
> 
> After disabling this, the server responds with the right group - X25519.
> 

Yes that's the problem. By doing that you're replacing the groups list with a
single curve.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

[Dr. Stephen Henson]

On Wed, Oct 04, 2017, Mahesh Bhoothapuri wrote:

> if (SSL_CTX_set1_groups_list(ctx, "P-521:P-384:P-256") == 0) {
>//error
> }
> 

If you have the above line you're telling the client to advertise support for
P-521:P-384:P-256 in that order and the server to only use them.

> The client and server both use SSL_CTX_set1_groups-list to set the
> supported group list.  Right now,  the server always
> has P-256 in the supported groups extension.
> When the the groups list is changed to add X25519,  the server responds
> with P-256.   Is there a way to have the server support
> multiple specified groups.
> 
> Section 9.1 of the rfc states:
> "
> 
> A TLS-compliant application MUST support digital signatures with
>rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
>CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
>TLS-compliant application MUST support key exchange with secp256r1
>(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748
> ].
>   "
> 

Yes and OpenSSL does support those but there is nothing stopping a server or
client being configured to support a different set of groups.

>   So, having the server support P-256 satisfies the MUST part.  How
> can we support X25519 on the server, or
> 

Use X25519 in the supported group list.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

[Dr. Stephen Henson]

On Wed, Oct 04, 2017, Matt Caswell wrote:

> 
> As Tomas said - that ship has sailed. In my mind that change was a
> mistake. It could have been done in a non-breaking way by introducing a
> new header format at that time.
> 

As regards a new header format. In the case of some of the structures we use
there is an appropriate password based encryption ASN.1 AlgorithmIdentifier.
The code to encode and decode that format is already in OpenSSL and it
is documented in various standards. It is currently used for private key
encryption (via PKCS#8) and PKCS#7 EncryptedData format (used by PKCS#12).
One of several advantages of using that form is that any new forms we want to
support just need to be a new password based encryption algorithm and "enc"
handles it automatically. So we'd get scrypt, PBKDF2 and all the older PKCS#12
algorithms automatically. We wouldn't be able to use the current non-standard
password based encrytion algorithm without defining our own OID but I can't
see why we'd want to use that when much better alternatives are available.

In fact if we were feeling particularly adventurous we could output a CMS or
PKCS#7 EncryptedData ContentInfo in the enc utility.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

[Dr. Stephen Henson]

On Mon, Oct 02, 2017, Matt Caswell wrote:
> 
> 
> On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote:
> > Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix.
> > 
> >  
> > 
> > To be more specific, the following get methods are missing in 1.0.2:
> > 
> >  
> > 
> > - EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *,  ???)
> > 
> > - EVP_PKEY_meth_get_decrypt(EVP_PKEY_METHOD *,  ???)
> > 
> > - EVP_PKEY_meth_get_encrypt(EVP_PKEY_METHOD *,  ???)
> > 
> >  
> > 
> > Note that the corresponding set methods are (thankfully) already present:
> > 
> >  
> > 
> > - EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *,  ???)
> > 
> > - EVP_PKEY_meth_set_decrypt(EVP_PKEY_METHOD *,  ???)
> > 
> > - EVP_PKEY_meth_set_encrypt(EVP_PKEY_METHOD *,  ???)
> > 
> >  
> > 
> > Can I hope that these get methods would be added? Maybe even soon?
> 
> Normally we don't add new features/functions to a stable release.
> However our policy for 1.1.0 (which obviously made lots of structures
> opaque), is that missing accessors are considered a bug - and we do add
> those. The situation is less clear for 1.0.2 since most structures are
> not opaque and we did not make wholesale opacity changes for that release.
> 
> If we had a PR to add them it might spur the discussion about whether
> adding these is valid for 1.0.2 or not to a conclusion!! Fancy creating one?
> 

Personally I'm in favour of adding these to 1.0.2, that structure has always
been opaque.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Bug in pkey_rsa_encrypt() and _decrypt()

[Dr. Stephen Henson]

On Tue, Sep 26, 2017, Blumenthal, Uri - 0553 - MITLL wrote:

> Working on pkcs11 engine, I discovered a bug in crypto/rsa/rsa_pmeth.c in 
> pkey_rsa_encrypt() and pkey_rsa_decrypt().
> 
> They cause a crash when called with out==NULL. Normally it should not happen 
> ??? but when an engine is called, and it cannot process the padding ??? it 
> reverts to the original OpenSSL-provided pkey_rsa_encrypt() or 
> pkey_rsa_decrypt() (as appropriate). OpenSSL pkeyutl makes two calls when the 
> key is not directly available (aka not presented in a disk file), and the 
> first call with out==NULL crashes when RSA_private_decrypt() or 
> RSA_public_encrypt() tries to copy the result to out.
> 

The original RSA pkey method has the flag EVP_PKEY_FLAG_AUTOARGLEN set which
handles the NULL output automatically so it is not handled in pkey_rsa_*().

The ENGINE should either set this flag itself too or deal with NULL arguments
manually if that is not appropriate.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
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

[Dr. Stephen Henson]

On Tue, Aug 29, 2017, Richard Levitte wrote:

> 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 cannot see anything wrong with making that a public API.  I
> wonder, though, if this is going to be an implementation that's kinda
> sorta built-in only, or if other implementations of the basic stuff
> will be possible...  or in other words, will we have a "method"
> structure like we have with so many other APIs?  In saying this, I'm
> counting in the possibility that some implementations could come in
> the form of engines, is this something that's been thought about?  I
> do notive the DRGB_CTX structure, but that doesn't quite follow the
> usual "method" pattern we have...
> 

In terms of future FIPS 140-2 compliance having a way to redirect all PRNG
operations to a FIPS compliant version is essential. This would require some
kind of method. We can redirect via RAND_METHOD but that currently means that
any ENGINE supplied PRNG is severely restricted (one global PRNG only)
compared to the built in DRBG. We could resolve that via a DRBG_METHOD or some
extended RAND_METHOD.

That's for the future though: there wont be a new FIPS module for some time
that will need this functionality.

In terms of the API itself. We could make RAND_DRBG public and I can see
reasons both for and against that. The main objection I can see is that it
commits us to DRBG like PRNGs: that is if we (or an ENGINE) in future wants to
use a RNG that isn't a good fit for the DRBG API it's a problem. We're
partially hitting that now because the DRBG API is not a good fit for the
older RAND API.

One alternative is to expand RAND_METHOD so it treats a DRBG as a special case
of the expanded API and it is flexible enough to handle any future needs. That
would (for example) have extended RAND APIs which can be passed an "instance"
of a PRNG (something like RAND_CTX which is analagous to the DRBG instance
structure we currently have).

That is tricky because RAND_METHOD is alas not an opaque structure and can't
be made so before OpenSSL 1.2.0. Tricky but not impossible.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Mon, Aug 28, 2017, Brett R. Nicholas wrote:

> 
> 
> One more follow up question:
> 
> 
> > If possible you should set the public key components anyway: some operations
> 
> > such as generating certificate requests require them to be present
> 
> I'm confused 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 write the public/private data (contained in the 
> RSA struct passed as an argument from the higher level encrypt/decrypt 
> functions) out to the hardware accelerator, and then return the result. So I 
> could never "set the public key components anyway", as they would be set by 
> whichever program calls RSA_public/private_encrypt/decrypt().
> 
> 
> Is my implementing it in this way different than how you thought I was 
> implementing it? It made sense to me to do it this way, however please let me 
> know if you think I'm going about it wrong, or if there are issues with this 
> particular strategy. I want to make sure I'm using the engine API in the most 
> intuitive and efficient way!
> 
> 

Ah if you're performing crypto acceleration of already existing keys then
that's fine.

In some cases an ENGINE can load a private key (typically from an HSM) and
returns the EVP_PKEY structure: in that case it would initialise the RSA
structure for RSA keys. It's that case where (n, e) should be initialised
if possible.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upgrading OpenSSL

[Dr. Stephen Henson]

On Mon, Aug 28, 2017, Leon Brits wrote:

> The upgrade is now working fine in one of the applications which make TLS 
> connections. I can see the engine functions being called when some action 
> (sign/verify) which require the privatekey.
> 
> However, this engine is also used in a patched version of Racoon2.
> In one of the files (crypto_openssl.c) a function is called by the IKE daemon 
> (iked) during setup with:
> :
> EVP_SignInit(, md);
> EVP_SignUpdate(, octets->v, octets->l);
> EVP_SignFinal(, (unsigned char*)sig->v, , pkey);
> :
> With the upgraded OpenSSL v1.0.2, the last function now fails with the error:
> 2017-08-28 15:44:14 [INTERNAL_ERR]: 
> crypto_openssl.c:1238:eay_rsassa_pkcs1_v1_5_sign(): RSA_sign failed: 
> 30972:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key 
> type:p_sign.c:123:
> 
> Q: I assume it is looking for one of the missing parameters (p) in the RSA 
> structure - correct?
> Q: If so, how did it work in v0.9.8?
> 
> If I change the first command to:
> EVP_SignInit_ex(, md, engine);
> Then it segfaults in the "SignFinal" command :(
> 
> The engine is dynamically loaded the same way in both my TLS connection 
> application and in the Racoon2 application.
> 
> Thanks for your time - any help is appreciated!
> 

Have you recompiled the application? Some structures have changed between
OpenSSL 0.9.8 and 1.0.2 so you'll get problems with applications (or an
ENGINE) compiled against the wrong headers.

If that isn't the problem then what is "md" set to?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

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
> > both.
> 
> Ah, I see. So to clarify (pls correct me if I'm wrong):
> 
>   *   rsa_mod_exp() is the modular exponentiation function that openSSL will 
> attempt to use for all private key operations (if RSA_FLAG_EXT_PKEY is set, 
> or the private parameters of that method are non-null), before defaulting to 
> bn_mod_exp().
>   *   And bn_mod_exp() is the modular exponentiation function used by all 
> public key operations
> 
> 
> So in my case, I should set RSA_FLAG_EX_PKEY in my engine's RSA_METHOD 
> struct, and then implement my own versions of rsa_mod_exp (for the private 
> key encryption/decryption), and bn_mod_exp (for the public key 
> encryption/decryption).
> 
> 

Yes. Note also that if you set the public key components (n, e) you don't need
to perform the public key operations in your ENGINE if you keep the original
bn_mod_exp(): OpenSSL will do them for you. If possible you should set the
public key components anyway: some operations such as generating certificate
requests require them to be present.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Sun, Aug 27, 2017, Brett R. Nicholas wrote:

> 
> This makes sense to me, and it seems that is the desired behavior. However,
> if I *only* reimplement the rsa_mod_exp() function, and leave the
> encrypt/decrypt functions to the default openSSL implementations, how can my
> engine know which of the four of those functions called its rsa_mod_exp
> function()? To put it another way: my accelerator will need to know whether
> it is meant to perform public key or private key operations, since the
> inputs will be written to different memory addresses. From within
> 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 code if this will be
> guaranteed just by having  RSA_FLAG_EXT_PKEY set in the "flags" field of my
> engine's RSA_METHOD.
> 

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

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] GCM tag in manual and examples

[Dr. Stephen Henson]

On Tue, Aug 22, 2017, Lukasz Kostyra wrote:

> Hello,
> 
> I've been trying recently to work with OpenSSL and use it to encrypt and
> decrypt data with AES cipher in GCM mode. While reading the documentation, I
> noticed an inconsistency between example code and manual.
> 
> My concern is the function used to set GCM tag when decrypting some data. In
> current version of the manual[1] it is written that EVP_CIPHER_CTX_ctrl
> function with EVP_CTRL_GCM_SET_TAG argument can be legally used only before
> any data is processed by OpenSSL - "Sets the expected tag to taglen bytes
> from tag. This call is only legal when decrypting data and must be made
> before any data is processed (e.g. before any EVP_DecryptUpdate() call).
> 
> However, looking at an example code on wiki[2] it appears that user can set
> a tag after calls to EVP_DecryptUpdate. The tag must be set only before
> calling EVP_DecryptFinal, which according how to GCM mode works should be a
> correct behavior. Running an example code confirms, that user doesn't have
> to set the tag before any processing calls, only before EVP_DecryptFinal.
> 
> This inconsistency was checked in 1.0.2, but appearently it appears on 1.1.0
> and on master documentation as well (with EVP_CTRL macro being different, as
> it also involves OCB mode now). Is it just a case of missing correction in
> documentation? Or maybe the documentation is correct, but there is a bug in
> OpenSSL?
> 

It's a bug in the documentation. The code used to require the tag first but
that was fixed but the documentation wasn't.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: openssl-fips build on cygwin 64bit

[Dr. Stephen Henson]

On Thu, Jul 20, 2017, Cristi Fati wrote:

> Apologies for spam, if this isn't the right place:
> 
> 
> *Details*:
> 
>- *cygwin* *64bit*  running on *Win10* (*CYGWIN_NT-10.0 cfati-e5550-0
>2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin*)
>- *openssl-1.0.2l* - irrelevant
>- *openssl-fips-2.0.16* - can be reproduced with previous versions
> 

Cygwin is not a supported platform for FIPS builds.


>- Since I don't know (I can't say that I tried very hard to find out)
>where the code for *openssl-fips* is on GitHub
> (which branch, or whether it's even
>there), in order to create a pull request, I'm going to use the old way:
>attaching a patch.

There are two branches relating to the FIPS 2.0 module:
OpenSSL-fips-2_0-dev and OpenSSL-fips-2_0-stable but since code changes have
to be approved via a change letter or a complete new validation for some
changes (both of which cost money) we can't just apply fixes.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows system cert store

[Dr. Stephen Henson]

On Thu, Jul 13, 2017, Matthew Stickney wrote:

> 
> You may have been looking at a different version of IE than what I've
> got on my Windows 7 VM, but at least here IE doesn't allow you to set
> certificate purposes: it has a dialog that looks just like that (under
> the "Advanced" button in the certificate list), but that's only used
> to select the set of usages you want to display if you choose
> "" in the "Intended Purpose" dropdown at the top
> (it's effectively just a customizable display filter).
> 

It's been a while since I looked at it yes. IIRC before when you selected
a root (or other) certificate under the Details tab you could select "Edit
Properties..." now the box is greyed out unless you run as administrator
or select a user added certificate.

> I've been reading through OpenSSL's verification code a bit, and from
> what I'm seeing it looks like purposes could be set for an existing
> certificate by setting the appropriate bits in the ex_kusage or
> ex_xkusage fields, at least for standard usages. Is that right?
> 

No those are just caches of the contents of the key usage and extended key
usage extensions. The function you need to call is X509_add1_trust_object()
for each trust setting. You could also call X509_alias_set1 to set the
friendly name of the certificate.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows system cert store

[Dr. Stephen Henson]

On Sun, Jul 09, 2017, Matthew Stickney wrote:

> The Certificate Manager in Windows does allow you to change the trust
> settings for root certs (including the purposes reported by openssl
> x509 -purpose), although those changes don't appear to be reflected in
> the cert dumped from the store (so they must be stored externally).
> 

Yes they're external properties. The certificate encoding returned can't be
modified of course because that would break the signature.

I think I did some experiments with CertGetEnhancedKeyUsage() and
CERT_FIND_PROP_ONLY_ENHKEY_USAGE_FLAG before. IIRC this reflected system
settings but not those visible in the MSIE dialogs: that is changing the
setting in MSIE didn't change the values returned by that API.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Dynamically adding a NID

[Dr. Stephen Henson]

On Sun, Jul 02, 2017, Salz, Rich via openssl-dev wrote:

> > I tried using OBJ_create() with NULL or an empty string for the OID, but 
> > currently it checks that the given OID is actually a valid one. Is there 
> > any workaround to avoid this other than issuing my own OID?
> 
> No.  Just get an OID ARC, such as from the IETF Enterprise MIB [it's free] 
> and throw it away.

If you create object without an OID it stops it being encoded or decoded as an
ASN1_OBJECT: this is sometimes useful. Unfortunately there is currently no way
to do this with OBJ_create().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Dynamically adding a NID

[Dr. Stephen Henson]

On Mon, Jun 26, 2017, Nicola Tuveri wrote:

> Hi,
> 
> I'm working on ENGINE development, and I have the need to add an NID for a
> custom message digest, and eventually for ciphers and PKEY methods.
> Some of the associated object don't (and won't ever) have an associated
> OID, but I need to add them dynamically to avoid requiring patches to the
> upstream OpenSSL code before being able to use my engine.
> 
> I'm currently (ab)using OBJ_create() [0], but it looks like it requires to
> specify a valid OID.
> I know it is possible to have NIDs associated with objects without OID
> (e.g. NID_siphash) when they are statically defined in OpenSSL source code,
> but I cannot find a way to declare similar objects without OID dynamically.
> 
> Before 1.1.0, when structures weren't opaque, I could manipulate the
> contents of the created object directly and somehow work around this
> limitation, but in 1.1.0 this is not possible.
> 
> Does anyone know of the right way to dynamically create an NID associated
> with an object without OID?
> 

What do you want to do with the NID? Does it need to have a valid short name
and/or long name associated with it (so OBJ_sn2nid etc work) but no valid OID
or do you just need a NID value?

You're right that currently OBJ_create() needs a valid OID passed to it: you
can't pass a NULL to create an "OIDless NID" as you can by editing
objects.txt.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] How to define EVP_EncryptUpdate and EVP_EncryptFinal functions for an AES engine? (and a separate question re: padding)

[Dr. Stephen Henson]

On Mon, Jun 26, 2017, Brett R. Nicholas wrote:

> AFAIK (and please correct me if this is wrong)  my init_key function is 
> invoked by the EVP interface when I call the EVP_[En/De]cryptInit_ex 
> function, and the do_cipher function is called upon EVP_[En/De]cryptUpdate. 
> But how should I handle the EVP_[En/De]cryptFinal functions? Should I not be 
> implementing them in my engine? Or am I missing something here
> 

The do_cipher function is normally the low level block cipher function: it
gets handed a multiple of the block size to encrypt/decrypt. The higher level
EVP_EncryptUpdate and EVP_EncryptFinal functions perform padding and buffering
internally and call the do_cipher function to encrypt a multiple of the block
size.

I saw "normally" because it is possible to specify the flag
EVP_CIPH_FLAG_CUSTOM_CIPHER in the EVP_CIPHER structure and handle padding
internally.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db

[Dr. Stephen Henson]

On Tue, Apr 11, 2017, Michael Reilly wrote:

> Hi,
> 
> commit 222333cf01e2fec4a20c107ac9e820694611a4db added a check that the size
> returned by EVP_PKEY_size(ctx->pkey) in M_check_autoarg() in
> crypto/evp/pmeth_fn.c is != 0.
> 
> We are in the process of upgrading from 1.0.2j to 1.0.2k and discovered that 
> the
> if (pksize == 0) check added in 1.0.2k breaks some of our applications.
> 
> We use an engine for the RSA sign operation.  The applications do not know
> anything about the keypair being used.  The keypair is kept private by the
> engine so the application couldn't determine the attributes of the keypair if 
> it
> wanted to do so.
> 
> If this check is necessary is there a way to bypass it when the application 
> does
> not have the keypair but the engine being used is holding the keypair?
> 
> I know we can simply remove this line from our copy of the code but we like to
> avoid modifying the openssl distributed code if at all possible.
> 

Well the point of that code is so an application knows how large a buffer to
allocate for the signature. If it returns zero I can't see how applications
can do that.

Note that you don't have to return the *precise* length of the signature just
an upper bound is sufficient.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Query about CRLDistributionPoints extension data

[Dr. Stephen Henson]

On Thu, Mar 30, 2017, Winter Mute wrote:

> Hello,
> All certificates I have encountered with this extension seem to have a
> problem with the encoding of the distributionPoint.
> According to the specs:
> 
>DistributionPointName ::= CHOICE {
> fullName[0] GeneralNames,
> nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
> 
> x509 implementations seem to confuse the "GeneralNames" with "GeneralName".
> The distinction is that the former is a sequence consisting of one or more
> instances of the latter, i.e:
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> Am I wrong about this? How does openssl parse this extension?

OpenSSL has never had a problem parsing this extension and it complies with
the specs. If it did have a problem it wouldn't be able to display the
contents of the extension.

Note that you wont see the SEQUENCE tag for the SEQUENCE OF GeneralName
because it is implicitly tagged.

Can you point to an example of a certificate where you think it is incorrectly
encoded?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Tue, Dec 13, 2016, David Woodhouse wrote:

> On Tue, 2016-12-13 at 13:09 +0000, 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 their use.
> > 
> > In this case the reason is different: the header doesn't contain the 
> > algorithm
> > type but a string which an ENGINE can handle. So it isn't a "legacy format"
> > but a custom one.
> > 
> > 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.
> 
> I am not entirely averse to the idea of saying that TPM, at least as of
> 2.0, should have a wrapped-key storage format which is based in PKCS#8
> rather than doing its own thing.
> 

If you go the PKCS#8 route then it would presumably be the unencrypted form.
One way to handle things would be to assign an OID for TPM and have an ASN.1
module unwrap the thing and return an EVP_PKEY structure.

That would work with any version of OpenSSL without modification if the ENGINE
included a TPM ASN.1 EVP_PKEY_ASN1_METHOD.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

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 encoded and it passes the decoded version to the relevant handler. So
if the data is of a textual form instead it cannot (currently) be handled but
that could be changed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Wed, Nov 30, 2016, James Bottomley wrote:

> One of the principle problems of using TPM based keys is that there's
> no easy way of integrating them with standard file based keys.  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 engine API callback which the first patch adds.  The second
> patch checks to see if the key can be loaded by any of the present
> engines.  Note that this requires that any engine which is to be used
> must be present and initialised via openssl.cnf.
> 
> I'll also post to this list the patch to openssl_tpm_engine that makes
> use if this infrastructure so the integration of the whole can be seen.
>  It should also be noted that gnutls has had this functionality since
> 2012.
> 
> The patch was done against 1.0.2h for easier testing and you can try it
> and the openssl_tpm_engine out (if you run openSUSE) here:
> 

I can see a couple of problems with this approach.

Firstly the BIO containing the private key may not be seekable: that is
BIO_reset() might not rewind it to the start. This could happen with a BIO
chain, a socket or a pipe for example. 

The second problem is that the file might contain multiple private keys so
(say) if you're reading the second private key in a file a reset will end up
taking you back to the beginning.

However the required functionality to support custom 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_read_bio_PrivateKey() it sees that the header ends in "PRIVATE KEY" and
then attempts to look up the key string: "RSA" in this case. It then
passes the decoded contents of the PEM file to the relavent algorithm ASN.1
method by looking for one that handles the appropriate string. Although all
current methods use ASN.1 for the private key data this shouldn't be necessary.

So for RSA this is rsa_ameth.c and the function is old_rsa_priv_decode. This
takes the encoded data and returns an EVP_PKEY structure containing the key.

So in theory if you wanted to handle a key of the form:

-BEGIN TPM PRIVATE KEY-
-END TPM PRIVATE KEY

you just create an almost empty ASN.1 method which handles the string "TPM"
and which only contains the PEM decoder. An ENGINE can also contain its own
custom methods so you could include an ENGINE which contains the relevant
handler. This would require no changes to OpenSSL to work.

There is however a snag. The relevant structure (EVP_PKEY_ASN1_METHOD) is
opaque and there is currently no way to set the pem decoder for a custom
string (the field is called "old_priv_decode"): only methods which are part of
OpenSSL can do that. 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 their use.

In this case the reason is different: the header doesn't contain the algorithm
type but a string which an ENGINE can handle. So it isn't a "legacy format"
but a custom one.

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.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [RFC 1/2] engine: add new flag based method for loading engine keys

[Dr. Stephen Henson]

On Wed, Nov 16, 2016, James Bottomley wrote:

> The assumption in all the current engine code is that key_id can be
> passed as something like a file name.

Well no it's a null terminated string whose meaning is engine specific. In
some cases it is a key ID, in others it is a more complex string indicating
multiple parameters.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
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

[Dr. Stephen Henson]

On Wed, Nov 16, 2016, Richard Levitte wrote:

> 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 with '-key' and if that file contains some kind of
> magic information that the engine can understand, it will dig out a
> reference to the hw protected key.
> 
> Many years ago, I was thinking of something along the same lines, but
> with a .pem file that would just have a few headers, holding the name
> of the intended engine and the key identity, something like this:
> 
> -BEGIN PRIVATE KEY-
> X-key-id: flarflarflar
> X-key-engine: foo
> -END PRIVATE KEY-
> 
> The intent was that the PEM code would be massaged to recognise these
> headers and would then use ENGINE_by_id() / ENGINE_load_private_key()
> with those data and that would be it.
> 

Yes me too. Though if you're doing that something like "ENGINE PRIVATE KEY"
or "OPENSSL ENGINE PRIVATE KEY" as just "PRIVATE KEY" is associated with
PKCS#8.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] custom X509_LOOKUP_METHOD in openssl 1.1.0 / load cert from memory

[Dr. Stephen Henson]

On Thu, Sep 15, 2016, Sebastian Andrzej Siewior wrote:

> Hi,
> 
> I've been looking at spice-gtk to get it compiled against openssl 1.1.0.
> One problem I have is that they are using a custom X509_LOOKUP_METHOD
> struct which is now not possible.
> It seems that this requirement was introduced [1] to able to load certs
> from within memory instead from file.
> 

While this isn't exactly the same, individual certificates (available in
memory as X509 structures) can be added using X509_STORE_add_cert().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Thu, Aug 04, 2016, Jim Carroll wrote:

> I had heard a patch was being worked on, but I do not believe it has been
> released (or if it is -- I can't find it).
> 
> I can confirm that "OpenSSL 1.1.0-pre7-dev" still has the bug which
> prevents PKCS7 sign-->encrypt->decrypt from working.
> 

This should'v e been fixed by commit abdb460d8abe68fedcf00 though some
issues remain which are currently being looked into.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Load secrets to context.

[Dr. Stephen Henson]

On Wed, Jul 27, 2016, john gloster wrote:

> Hi,
> 
> Can we use both the following APIs in the same application to load
> certificate to the SSL context?
> 
> *SSL_CTX_use_certificate_file()*
> *SSL_CTX_use_certificate_chain_file()*
> 

You should only use one. If you use SSL_CTX_use_certificate_chain_file() the
file needs to contains the certificates from EE to root in order in PEM
format.

If you want to do things differently you can load the PEM files manually and
use functions like SSL_CTX_use_certificate() and SSL_CTX_add0_chain_cert().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [TLS1 PRF]: unknown algorithm

[Dr. Stephen Henson]

On Wed, Jul 27, 2016, Catalin Vasile wrote:

> Hi,
> 
> I'm trying to use the EVP_PKEY_TLS1_PRF interface.
> 
> The first thing I do inside my code is:
> pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_TLS1_PRF, NULL);
> But pctx is NULL after that call.
> 
> I've watched test/evp_test.c and it does not seem it does anything special, 
> but it successful in running the TLS1-PRF tests.
> 
> Is there something I'm missing?
> 

Is it linking against an older version of OpenSSL?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Mon, Jul 25, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> I confess I did not test this with 1.1.x. But in 1.0.2h there???s a problem.
> 
> CMS man page says:
> 
> If the -decrypt option is used without a recipient certificate then an
> attempt is made to locate the
> recipient by trying each potential recipient in turn using the supplied
> private key. To thwart the MMA
> attack (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding) all recipients
> are tried whether they
> succeed or not and if no recipients match the message is "decrypted" using a
> random key which will
> typically output garbage. The -debug_decrypt option can be used to disable
> the MMA attack protection
> and return an error if no recipient can be found: this option should be used
> with caution.

That's a bug in the documentation. Currently that only works for RSA keys, not
EC or DH.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Clear X509 OBJECT cache

[Dr. Stephen Henson]

On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:

> On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:
> 
> > "X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates
> > and CRLs on demand, and caches them in memory once they are loaded. As of
> > OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer
> > CRLs are as soon as they appear in the directory. When checking for new CRLs
> > once one CRL for given hash value is loaded, hash_dir lookup method checks
> > only for certificates with sequence number greater than that of the already
> > cached CRL" - This certainly not happens. It should have stated that only
> > unique file names will be loaded for once from the disk and the new ones for
> > the same issuer will not be looked up even if you change the sequence
> > number.
> > 
> 
> They should be looked up: if they aren't this is a bug.
> 
> The problem is that unless the current time exceeds the nextUpdate field of
> the new CRL it wont be used: it will use the first one where the current time
> is between lastUpdate and nextUpdate.
> 
> When you added a new CRL was it just "newer" (i.e. thisUpdate later than the
> the new CRL wasn't used that's a bug which should be fixed.
> 

Argh... I mean "lastUpdate" not "lastUpdate".

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Clear X509 OBJECT cache

[Dr. Stephen Henson]

On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:

> On Wed, Jul 20, 2016, Dr. Stephen Henson wrote:
> 
> > On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:
> > 
> > > "X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates
> > > and CRLs on demand, and caches them in memory once they are loaded. As of
> > > OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that 
> > > newer
> > > CRLs are as soon as they appear in the directory. When checking for new 
> > > CRLs
> > > once one CRL for given hash value is loaded, hash_dir lookup method checks
> > > only for certificates with sequence number greater than that of the 
> > > already
> > > cached CRL" - This certainly not happens. It should have stated that only
> > > unique file names will be loaded for once from the disk and the new ones 
> > > for
> > > the same issuer will not be looked up even if you change the sequence
> > > number.
> > > 
> > 
> > They should be looked up: if they aren't this is a bug.
> > 
> > The problem is that unless the current time exceeds the nextUpdate field of
> > the new CRL it wont be used: it will use the first one where the current 
> > time
> > is between lastUpdate and nextUpdate.
> > 
> > When you added a new CRL was it just "newer" (i.e. thisUpdate later than the
> > the new CRL wasn't used that's a bug which should be fixed.
> > 
> 
> Argh... I mean "lastUpdate" not "lastUpdate".
> 

Oops.. ;-)

Err... I'll try that again. I meant "lastUpdate" not "thisUpdate".

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Clear X509 OBJECT cache

[Dr. Stephen Henson]

On Wed, Jul 20, 2016, Patel, Anirudh (Anirudh) wrote:

> "X509_LOOKUP_hash_dir  is a more advanced method, which loads certificates
> and CRLs on demand, and caches them in memory once they are loaded. As of
> OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer
> CRLs are as soon as they appear in the directory. When checking for new CRLs
> once one CRL for given hash value is loaded, hash_dir lookup method checks
> only for certificates with sequence number greater than that of the already
> cached CRL" - This certainly not happens. It should have stated that only
> unique file names will be loaded for once from the disk and the new ones for
> the same issuer will not be looked up even if you change the sequence
> number.
> 

They should be looked up: if they aren't this is a bug.

The problem is that unless the current time exceeds the nextUpdate field of
the new CRL it wont be used: it will use the first one where the current time
is between lastUpdate and nextUpdate.

When you added a new CRL was it just "newer" (i.e. thisUpdate later than the
current one) or had the current time exceeded nextUpdate? If the latter and
the new CRL wasn't used that's a bug which should be fixed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] pkcs12 settings, Was: Re: [openssl.org #4588] pkcs12 -info doesn't handle PKCS#12 files with PKCS#5 v2.0 PBE

[Dr. Stephen Henson]

On Tue, Jul 19, 2016, Hubert Kario wrote:

> I have few questions now though:
> 
> I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
> uses sha256
> 
> is there a way to set this?
> 

Not currently no (at least not from the command line, maybe by delving
into the pkcs12 internals). It's determined by the encryption algorithm (if it 
has a
preference: most don't) or the value is hard coded in p5_pbev2.c

> also, is there a way to report the MAC algorithm used over the whole
> file (the one set using -macalg)
> 

Not from the command line currently. The PKCS12_get0_mac() function can be
used to retrieve the X509_ALGOR structure corresponding to the MAC though.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] MGF1-OAEP with SHA2

[Dr. Stephen Henson]

On Thu, Jul 07, 2016, c.hol...@ades.at wrote:

> 
> I try to get RSA enryption/decryption (over the API) with MGF1
> OAEP-padding other then SHA1.
> 

You need to use the EVP_PKEY API and pass the required algotithm to
EVP_PKEY_CTX_set_rsa_oaep_md() which is currently undocumented (fix coming
up).

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Null Ciphers in FIPS mode

[Dr. Stephen Henson]

On Wed, Jun 01, 2016, Mody, Darshan (Darshan) wrote:

> 
> Does Openssl allows NULL ciphers when we put openssl in FIPS mode?
> 

If you mean NULL ciphersuites then yes though they're not enabled by default
just like non-FIPS mode.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Tue, May 31, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> 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
> ~/Documents/Certs/me_mouse_yubi_9d_.pem
> Error creating PKCS#7 structure
> 140735083847760:error:21082096:PKCS7
> routines:PKCS7_RECIP_INFO_set:encryption not supported for this key
> type:pk7_lib.c:542:
> 140735083847760:error:21073078:PKCS7 routines:PKCS7_encrypt:error adding
> recipient:pk7_smime.c:503:
> $ openssl version
> OpenSSL 1.0.2h  3 May 2016
> $
> 

The smime utility uses PKCS#7 which doesn't support anything other than RSA
for the enveloped data type.

Use the cms utility instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Signing Internet-Drafts and RFCs

[Dr. Stephen Henson]

On Thu, May 12, 2016, Matt Caswell wrote:

> 
> 
> On 11/05/16 22:03, Russ Housley wrote:
> > Today, the IETF uses OpenSSL to digitally sign Internet-Drafts.  If
> > you care about the details, please see RFC 5485.
> > 
> > We are looking to expand Internet-Draft signing, and start signing
> > RFCs as well.  Someone has suggested that we support RFC 5126, "CMS
> > Advanced Electronic Signatures (CAdES)?.  This would mean including
> > some signed attributes that we do not currently use.
> > 
> > A CAdES Basic Electronic Signature (CAdES-BES) must include these
> > signed attributes:
> > 
> > - Content-type ? I know OpenSSL supports this one. - Message-digest ?
> > I know OpenSSL supports this one. - ESS signing-certificate-v2 ? I
> > cannot tell if this is supported.
> > 
> > The ESS signing-certificate-v2 attribute is defined in RFC 5035.  I
> > am interested in using it with SHA-256.  Is it supported?  If not,
> > what would need to happen to get it supported?
> 
> With the caveat that I know nothing about CAdES and haven't reviewed the
> PR in question, you might want to look at this:
> 
> https://github.com/openssl/openssl/pull/206
> 
> If this PR were to be merged it would be a new feature and therefore
> would not get incorporated until after the up-coming 1.1.0 release.
> 

Note that that PR (which IMHO needs quite a bit of work before we should
consider merging it) applies to the timestamping protocol. Something more
suited to CMS would be better with command line support and automatic
processing in CMS_verify et al.

I'll look into that after 1.1.0 release.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Getting raw ASN1 data from X509 certificate

[Dr. Stephen Henson]

On Tue, Apr 26, 2016, Kurt Roeckx wrote:

> Hi,
> 
> I'm working on a tool that checks various things related to X509
> certificates.  I want to check that the encoding is actually
> correct DER.  With things like ASN1_TIME is seems easy to get to
> the raw data, it just seems to contain it.  But when I try it with
> an ASN1_INTEGER it doesn't seem to contain all the data.  For
> instance, if it's a number that starts with a byte >= 0x80, the
> encoding should have a 0x00 in front of it.  But in the
> ASN1_INTEGER it already seems to have removed that 0x00.
> 
> Is there a way I can get to raw encoding?  Or do I need to write
> my own parser (or use an other existing one) to be able to get to
> it?
> 

For ASN1_INTEGER you the structure contains the integer value in big endian
format stripping off any padding. If you call the i2d function you'll get the
encoding back but it does that by reencoding the value so it may not match the
original if it's isn't DER.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Dr. Stephen Henson]

On Mon, Mar 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> On 3/14/16, 14:45, "openssl-dev on behalf of Viktor Dukhovni"
> 
> wrote:
> 
> >On Mon, Mar 14, 2016 at 05:45:34PM +, Stephan Mühlstrasser via RT
> >wrote:
> >> I had written a message about this issue to openssl-users, but received
> >> no reaction.
> >
> >IIRC RC4 (more generally all stream ciphers) are not supported with
> >CMS, and the bug is that OpenSSL allowed you to use RC4, not that
> >the result failed to decrypt.
> 
> Is there any reason why stream ciphers are not supported with CMS?
> 

Well one reason is that I'm not aware of any standard which defines how to use
stream ciphers with CMS.

OpenSSL should really reject these with an appropriate error. 

> Along the same line, is there any reason why AE(AD) ciphers are not
> supported with ???openssl enc
> 

The require additional handling such setting parameters and how to handle the
tag. That functionality is not currently present in the enc utility.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] links to KDF functions from pkeyutl man are broken

[Dr. Stephen Henson]

On Fri, Mar 04, 2016, Dmitry Belyavsky wrote:

> Dear Rich,
> 
> Is it possible to add a command line option to select hash algorithm used
> in the PRF calculations?
> GOST ciphersuites, for example, use TLS1 PRF based on the GOST digest
> algorithms.
> 

I think it's already there -pkeyopt md:

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PHP openssl ext port for 1.1 - cert->name

[Dr. Stephen Henson]

On Tue, Mar 01, 2016, Jakub Zelenka wrote:

> Hello,
> 
> I'm just slowly porting PHP core openssl ext to work with OpenSSL 1.1 and
> just came across one thing that I can't find a function for.
> 
> We have got a part in openssl_x509_parse where we display cert->name (cert
> is X509 struct) if it is not NULL:
> 
> https://github.com/php/php-src/blob/715a198e1f4f6f79f596963727b1a1c92e7fed1b/ext/openssl/openssl.c#L1998
> 
> The X509 is now opaque and I can't find any function for that which I might
> be missing because it's quite late... :)
> 
> I tried to find it using
> 
> grep -rn '>name' crypto/x509
> 
> but it doesn't show any function that would return a cert name
> 
> Not sure if it's actually useful to show that but I see that the name is
> set in x509_cb when operation is ASN1_OP_D2I_POST
> as X509_NAME_oneline(ret->cert_info.subject, NULL, 0) .
> 
> Please could you let me know if there is a function for that or what I
> should use instead?
> 

It isn't really useful. It uses the ancient and quirky X509_NAME_oneline()
function to convert the certificate subject name to an old oneline format
(which mishandles things like multi byte characters).

If you really want it you can create it using X509_get_subect_name() and
X509_NAME_oneline() directly but you have to free it once you've finished with
it.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL 1.1.0 and FIPS

[Dr. Stephen Henson]

On Mon, Feb 22, 2016, Wall, Stephen wrote:

> I wonder if I could get the thoughts of some of you developers on how
> difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of
> the current (2.0.11?) fipscanister.o.  Also, opinions on if this would be a
> legitimate way to get FIPS in 1.1.0.
> 

Just to add a few thoughts to this.

It would be very tricky and rather messy. The 2.0.x module uses various
shortcuts (which were pretty much essential given the time pressure on its
development) such as keeping structure compatible with OpenSSL. For 1.1.0 many
structures have changed considerably and many are opaque so this wont work.

Add to that that it isn't just a case of having an external ENGINE. There
needs to be some extensive glue code in OpenSSL itself to (for example) ensure
that the correct imeplementation is used and to block unapproved APIs and
algorithms. 

So while I think it is theoretically possible I think handling this as part of
a new validation effort would be the best approach. We could then incorporate
some of the new FIPS 140-2 requirements and add some new algorithms.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Call for testing: OpenSSH 7.2

[Dr. Stephen Henson]

On Mon, Feb 15, 2016, The Doctor wrote:

> Just tested this on the old BSD/OS machine
> 
> works with openssl 1.0.2X
> 
> Openssl 1.1.X  issues
> 
> cipher.h  in openssl 1.1  needs to read
> 
> struct sshcipher;
> struct sshcipher_ctx {
> int plaintext;
> int encrypt;
> struct evp_cipher_ctx_st *evp;
> struct chachapoly_ctx cp_ctx; /* XXX union with evp? */
> struct aesctr_ctx ac_ctx; /* XXX union with evp? */
> const struct sshcipher *cipher;
> };
>
> 
> I am running into issues with sshkey.c
> 
> 
> line 3787  
> 
>   if (pk->type == EVP_PKEY_RSA &&
> 
> line 3802
> 
>   } else if (pk->type == EVP_PKEY_DSA &&
> 
> line 3814
> 
> } else if (pk->type == EVP_PKEY_EC &&
> 
> Now  
> 
>   EVP_PKEY *pk = NULL;
> 

The EVP_PKEY structure is now opaque and so you need to call the accessor
function EVP_PKEY_id(pk) instead. That function exists in OpenSSL 1.0 and
later though not 0.9.8.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PKCS12_Parse() no longer extract certificate

[Dr. Stephen Henson]

On Thu, Feb 11, 2016, Michel wrote:

> Hi,
> 
>  
> 
> I have a test program which is failing using version 1.1 because
> PKCS12_Parse() doesn't return the certificate, just the key. No error is
> signaled. 
> 
> I supposed it is not intended. Is it work in progress ?
> 

That's a bug which should be fixed by commit b3ca51559b1a6cd80d

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Thu, Feb 11, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

>   ^
> Probably correct IN THIS ONE CASE, because Most Significant Bit is zero
> even without the leading zero byte. See below.
> 
> >>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot
> >>contain
> >> leading zeroes. 
> 
> I???m pretty sure this is not correct. It???s been a while since I touched
> ASN.1, but I had quite a bit of experience with it back when.
> 

I should've been a bit clearer. I should have said additional or superfluous
leading zeroes which is the cases here because there is a leading zero and the
MSB of the second octet is also zero. Others have referenced the relevant
sections of the standards that require that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Wed, Jan 20, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> On 1/20/16, 5:10 , "Hubert Kario"  wrote:
> 
> It appears to me that pkeyutl is more an instrument to access those
> primitive operations, unlike dgst that provides access to the ???true???
> (complete) signature function that includes hashing. So no matter what
> draft-josefsson-eddsa-ed25519-02 says, the hashing would have to be done
> in software, and the result passed to the token for the actual signing.
> 
> >So, unless the above is false, I'd rather not add such absolute
> >statements.
> 
> I see your point. Would leave the decision to you, in light of the above.
> Because the exact purpose of pkeyutl is unclear to me, I can???t insist.
> 
> Assuming pkeyutl does provide access to the ???complete EdDSA function??? as
> specified in the draft above, one possibility is to add even more words,
> and explicitly state where the digest for sure is NOT invoked (RSA, DSA,
> ECDSA), and maybe where it is (EdDSA, maybe other future schemes)...
> 
> >But please correct me if I'm wrong.
> 
> Likewise. :-)
> 

Well pkeyutl along with pkey and genpkey are algorithm neutral versions of
rsautl, rsa, genrsa. Underneath they access the EVP_PKEY APIs so what pkeyutl
does is largely governed by how those behave. So while there is some common
behaviour (e.g. if a digest is specified the input will be a raw digest with
length sanity checks) what happens in detail is determined by the algortihms
themselves.

Support for EdDSA isn't in OpenSSL yet (there are some issues to resolve in
order to decide how the API will work) so how that will precisely behave is
not yet defined.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Keyed hashing APIs for EVP?

[Dr. Stephen Henson]

On Sat, Jan 16, 2016, Bill Cox wrote:

> 
> I feel keyed hashing is here to stay.  Keccak also has this feature.
> Assuming I'm reading the EVP API correctly, should add support for keyed
> digests to EVP.  What do you folks think?
> 

Support for MAC already exists in EVP. It's possible to access HMAC, CMAC and
GOST MAC algorithms using EVP. The interface isn't very friendly however and
could be tidied up a bit.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

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-boun...@openssl.org on behalf of st...@openssl.org> wrote:
> 
> >On Thu, Jan 14, 2016, Salz, Rich wrote:
> >
> >> Okay, how about this.  First, remove the NOTES subhead.  Add this to
> >>the end of the first paragraph:
> >> 
> >>This program does not hash the input data and requires the input data
> >>to be of the proper size, and must not be greater than the size of
> >>the public key field or modulus.  See dgst(1) for a unified
> >>Interace.
> >> 
> >
> >The comment about the public key field or modulus is only true for some
> >public
> >key algorithms (e.g. RSA).
> 
> Public key modulus would be true for RSA and DSA. Field would be true for
> ECDSA (and I daresay EdDSA). What other signatures do we have?

For RSA the maximum size depends on the padding mode and is typically
less than the modulus.

For ECDSA it can be exceed the field size: it is truncated in that case.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Wed, Jan 13, 2016, Blumenthal, Uri - 0553 - MITLL wrote:

> 
> 
> If the input to "pkeyutl ???sign??? is supposed to be digest output only ??? 
> then
> what???s the point of having command line arguments specifying the digest to
> use? And if the input can be an arbitrary file (like for ???dgst???), then why
> it doesn???t seem to work?
> 
> I???d appreciate comments, guidance, etc.
> 

The dgst utility performs hash+sign the pkeyutl utility is supplied with the
data to sign (which is usually but not always a hash).

The reason you can specify which hash the digest is for is that without that
the utility just sees binary data of a certain length. By specifying the
digest it can sanity check the length and in some schemes (e.g.  RSA) include
the digest algorithm in the data being signed (PKCS#1 DigestInfo structure
for some RSA padding modes).

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH] Declare/Implement ASN1_FUNCTIONS for NAME_CONSTRAINTS

[Dr. Stephen Henson]

On Sat, Jan 09, 2016, Paul Kehrer wrote:

> The ASN1 functions for NAME_CONSTRAINTS are not declared or implemented in 
> the current OpenSSL releases. This is inconsistent with other extension 
> structs and (I believe) means you either need to declare them yourself or 
> attempt to build NAME_CONSTRAINTS using nconf functions. Below is a patch to 
> current git master that adds support for these functions. 
> 
> If there's a preferred way to test that these macros behave as expected I'll 
> be happy to add the tests to this patch.
> 

Why do you need the i2d/d2i functions? It is possible to encode and decode the
extension using X509_get_ext_d2i() and X509_add1_ext_i2d().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Variable length of digest

[Dr. Stephen Henson]

On Thu, Dec 24, 2015, Dmitry Belyavsky wrote:

> 
> If you try to change the output length via the -macopt option of the dgst
> command, you'll see that the text output will be 4 bytes.
> It seems to happen because of the internal call to the EVP_MD_size()
> function.
> 
> If we change the EVP_MD_CTX_size() definition from a macro to a function
> trying to call the ctrl function and then to fallback to the result of the
> EVP_MD_size() function, it should improve the situation.
> 

If you're using it as a MAC via EVP_DigestSign*() you shouldn't need to do any
of that. The MAC size is indicated via EVP_DigestSignFinal, looking through
the code of the dgst application this should already work (though no current
MAC does this) as long as the digest implementation handles things
appropriately. By "appropriately" you have to specify "signctx" in the
underlying EVP_PKEY_METHOD: see the source for EVP_DigestSignFinal().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Variable length of digest

[Dr. Stephen Henson]

On Wed, Dec 23, 2015, Dmitry Belyavsky wrote:

> Hello OpenSSL Team,
> 
> I have a question.
> 
> I need to implement a digest with variable length of output. The length of
> output can be easily specified by the control function, but EVP functions
> expect the constant length of the digest result.
> 
> Is there a good solution how to fix it and will the patch providing such a
> solution be acceptable?
> 

That's an interesting question. What digest requires this? Is the output
length arbitrary or do the standards specify a maximum size?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ECDH engine

[Dr. Stephen Henson]

On Fri, Dec 18, 2015, Alexander Gostrer wrote:

> Hi Steve,
> 
> John and I completed writing an ECDH engine based on the
> OpenSSL_1_0_2-stable branch. We were planning to expand it to the master
> but found some major changes made by you recently. What is the status of
> this task? Is it stable enough to follow it? Are you planning another
> changes? Is there a design document that we can use in our work?
> 

The version in master shouldn't change much any more. Documentation will be
available in the near future. The changes were meant to remove some of the
weird "quirks" of ECC compared to other algortihms and to permit future
expansion to a wider range of curves.

In the meantime it shouldn't be too hard to follow how the new code works.
Instead of separate ECDH/ECDSA methods with weird locking and ex_data and
minimal ENGINE support everything is combined into a single EC_KEY_METHOD
which can contain ECDSA, ECDH and key generation (something which was
impossible with the old code) and be tied directly to an ENGINE.

Most of the primary APIs such as ECDH_compute_key can be redirected directly
through an engine supplied function in EC_KEY_METHOD.

Having said that the code is very new and may have the odd bug that needs to
be fixed. If you have any problems let me know and I'll look into them.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote:

> Much better now - but at this time I hit ???unsupported algorithm???. The key
> in question is RSA-2048, with SHA256.
> 
> $ LOAD_CERT_CTRL=true VERBOSE=7 openssl pkeyutl -engine pkcs11 -sign
> -keyform engine -inkey
> "pkcs11:object=SIGN%20key;object-type=private;pin-value=123456" -out
> config.status.sig -in config.status.hash
> engine "pkcs11" set.
> Error initializing context
> 140735296230224:error:260C0065:engine
> routines:ENGINE_get_pkey_meth:unimplemented public key
> method:tb_pkmeth.c:128:
> 140735296230224:error:0609D09C:digital envelope
> routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164:

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.

What we need is a way to load the private key from an ENGINE but not attempt
to use that for the actual operations. Temporary fix is to set the second
argument in EVP_PKEY_CTX_new to NULL in pkeyutl.c

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Thu, Dec 10, 2015, Blumenthal, Uri - 0553 - MITLL wrote:

> 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:
> 
> >
> >As I indicated the fix I suggested it temporary. Sometimes a user will
> >want
> >that behaviour so we'd need a new command line option indicating the
> >private
> >key engine only.
> 
> Ideally engine_pkcs11 should do it automatically, but I see your point.
> Perhaps the code in pkeyutl.c could check if (a) engine is set, and (b)
> the engine is PKCS11? And if so - automatically do the right thing? Do you
> envision other engines with similar needs? My assumption was that the only
> engine that talks to smart cards is pkcs11...

The CryptoAPI ENGINE can also talk to smart cards.

> 
> In the meanwhile, in your opinion should rsautl need a similar patch, or
> would it work out of box, like dgst did?
> 

It should yes: rsautl uses the lower level RSA functions only.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download)

[Dr. Stephen Henson]

On Fri, Dec 04, 2015, Carl Tietjen wrote:

> Folks,
> 
> It looks like the Windows x86_64  build for OpenSSL version 1.0.1q is broken. 
>  
> 
> I am building a FIPS capable version, and have verified that I have the 
> corrected download build:   SHA1 checksum: 
> c65a7bec49b72092d7ebb97a263c496cc1e1d6af
> FYI - I have successfully built on 3 Linux platforms with this tar file. 
> 
> Build steps:
> 1) perl Configure VC-WIN64A fips 
> --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 
> no-rc5
> 2) ms\do_win64a
> 3) nmake -f ms\nt.mak
> ...
> NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj'
> 

Fixed in commit 544058202be49a6

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows x86_64 build broken -- RE: [openssl-users] OpenSSL version 1.0.1q released (corrected download)

[Dr. Stephen Henson]

On Fri, Dec 04, 2015, Carl Tietjen wrote:

> Folks,
> 
> It looks like the Windows x86_64  build for OpenSSL version 1.0.1q is broken. 
>  
> 
> I am building a FIPS capable version, and have verified that I have the 
> corrected download build:   SHA1 checksum: 
> c65a7bec49b72092d7ebb97a263c496cc1e1d6af
> FYI - I have successfully built on 3 Linux platforms with this tar file. 
> 
> Build steps:
> 1) perl Configure VC-WIN64A fips 
> --with-fipslibdir=c:\FIPS\openssl-fips-ecp-2.0.9 no-ec2m no-idea no-mdc2 
> no-rc5
> 2) ms\do_win64a
> 3) nmake -f ms\nt.mak
> ...
> NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj'
> 
> 
> 
> It looks like the nt.mak file ends up different than the one from 1.0.1p. The 
> relevant changes are:
> 
> 1.0.1p:
> ...
> $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) 
> $(O_FIPSCANISTER) 
>   $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<<
>   $(EX_LIBS) $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) $(O_FIPSCANISTER) 
> $(EX_LIBS)
> ...
> 
> 1.0.1q
> $(PREMAIN_DSO_EXE): $(OBJ_D)\$(E_PREMAIN_DSO).obj $(CRYPTOOBJ) 
> $(O_FIPSCANISTER)  $(OBJ_D)\applink.obj
>   $(LINK) $(LFLAGS) /out:$(PREMAIN_DSO_EXE) @<<
>   $(EX_LIBS) $(OBJ_D)\applink.obj $(OBJ_D)\$(E_PREMAIN_DSO).obj 
> $(CRYPTOOBJ) $(O_FIPSCANISTER) $(EX_LIBS)
> 
> ___
> 
> I have tried to find any changes in the perl scripts that would cause this 
> change, but have been unsuccessful so far.
> 
> Thanks in advance for any help
> 

That update was to fix a linker error in some versions of VC++. I just tried
that on the latest 1.0.1 branch and can't reproduce your problem. What version
of VC++ are you using?

However you need to use --with-fipsdir not --with-fipslibdir and it need to
point to wherever the FIPS module was installed, not the source directory.
Alternatively you can set the FIPSDIR environment variable before building the
FIPS module and it will be installed to that location and the FIPS capable
OpenSSL will use that without the need to use --with-fipsdir.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Fri, Nov 13, 2015, Benjamin Kaduk wrote:

> 
> As another thread calls to mind, PKCS#12 could potentially just use
> triple-DES.  (BTW, the CMS tests fail when openssl is configured with
> no-rc2, due to this; I have a WIP patch sitting around.)
> 

The issue is that some cuurent software (including major web browsers) still
produce PKCS#12 files which include 40 bit RC2 for certificate "encryption"
and OpenSSL would fail to decrypt those if it removed RC2.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OCSP issues in master 2015-10-17

[Dr. Stephen Henson]

On Sat, Oct 17, 2015, Roumen Petrov wrote:

> Hello,
> 
> After embed  some attributes OCSP in master stop to work.
> 
> The current status is the client comment report "Cert Status:
> unknown" and "Nonce Verify error" for X.509 certificates used in my
> ssh regression tests.
> 
> The last known version to work is
> "47c9a1b5096be684c18335137284f0dfcefd12d6 : embed support for
> ASN1_STRING"
> (optionally with "Appease gcc's Wmaybe-uninitialized" if build fail
> due to pedantic compiler flags).
> 
> First regression is from "af170194a88d6127d447bea826845c23ca192727 :
> embed OCSP_CERTID" - status is missing.
> 

Should be fixed by commit 7f3e6f8c243710b8dc89f385196987ad83c7848d in the
master branch.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dr. Stephen Henson]

On Fri, Sep 11, 2015, Blumenthal, Uri - 0553 - MITLL wrote:

> I am trying to build the current Github version of openssl on Ubuntu-14.04
> LTS. Must add that this system has openssl-1.0.1f already installed (relict
> of Ubuntu software update process).
> 
> Everything seems to compile fine, but linking of ???openssl??? fails,
> complaining that it cannot find ???CMS_CompressedData_it??? reference. This 
> only
> happens when I configure openssl with ???zlib"
> 
> ./config ???prefix=/usr/local threads zlib
> 
> I observed that ???r CMS_CompressedData_it??? is present in cms_asn1.o in
> libcrypto.a.
> 
> This works fine and links everything correctly (and all the tests pass OK):
> 
> ./config ???prefix=/usr/local threads
> 
> Any help is appreciated.
> 

Fixed in commit bc2a15cdfb5a5a9

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3978] RE: Openssl 1.0.2c include the FIPS 140-2 Object Module

[Dr. Stephen Henson]

On Mon, Aug 17, 2015, Patil, Ashwini IN BLR STS via RT wrote:

 Hi Mr. Stephen N. Henson,
 
 
 
 Thankyou so much for the reply.
 
 
 
 We would like to use the option1 mentioned by you. But unfortunately the 
 dll's were not generated, only static lib's were generated.
 
 Please guide if we have missed any steps.
 
[snip]
 
 g. nmake -f ms\nt.mak
 

This builds the static libraries. If you do:

nmake -f ms\ntdll.mak

you will get the DLLs.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3978] RE: Openssl 1.0.2c include the FIPS 140-2 Object Module

[Dr. Stephen Henson]

On Mon, Aug 17, 2015, Patil, Ashwini IN BLR STS wrote:

 
 
 Please let me know if I need to make changes in ntdll.mak file to generate 
 the corresponding  fipslibeay32.dll .
 
 As I need to include this dll in my test application to turn on the fips 
 module.


There is no fipsleay32.dll library, link against libeay32.dll instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Localised Error

[Dr. Stephen Henson]

On Sun, Jul 19, 2015, The Doctor wrote:

 On Sun, Jul 19, 2015 at 06:05:26AM -0600, The Doctor wrote:
  What should I be looking at when
  
  signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify 
  error
  
  occurs?
 
 
 Further from the code
 
 i = X509_verify_cert(cert_ctx);
 if (i = 0)
 j = X509_STORE_CTX_get_error(cert_ctx);
 X509_STORE_CTX_cleanup(cert_ctx);
 if (i = 0) {
 PKCS7err(PKCS7_F_PKCS7_VERIFY,
  PKCS7_R_CERTIFICATE_VERIFY_ERROR);
 ERR_add_error_data(2, Verify error:,
X509_verify_cert_error_string(j));
 sk_X509_free(signers);
 return 0;
 } 
 
 I wonder what could cause such an error?
  

There should be two files cms.out and cms.err in the test directory if a CMS
test fails. What is in them?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] RSA SigVer (FIPS 186-4) Issue

[Dr. Stephen Henson]

On Mon, Jun 29, 2015, rst...@symsysresearch.com wrote:

 I am getting incorrect False-Negative results when performing tests
 with 186-4 vectors (generated by CAVS 17.6).
 
 This vector is being reported false while CAVS says they should pass.
 
 [mod = 1024]
 n = 
 d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009
 
 SHAAlg = SHA512
 e = 
 001f2acb
 Msg = 
 912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
 S = 
 122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3
 
 I've added some debug output and I get the following:
 
 DIGEST = 
 423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
 SIG = 
 122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
 N   = 
 D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
 RR  = 
 CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
 SUB = 
 CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921DAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
 IR  = 
 CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
 SigVer Result = 0
 
 RR is the result of the power-E-mod-N operation, and SUB is the
 computed (N-RR) value.  IR is the choice of RR or (N-RR) used for
 the remainder of verification.
 
 It seems clear to me that neither RR nor SUB has the correct form,
 and that this vector should not pass.
 
 The lab is saying this must be a bug in OpenSSL, but no modification
 has been made that would introduce such a bug.  It's my contention
 that this is a bug in CAVS.  Can anyone shed some additional light
 onto the issue?
 

Which padding mode is being used?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] RSA SigVer (FIPS 186-4) Issue

[Dr. Stephen Henson]

On Mon, Jun 29, 2015, rst...@symsysresearch.com wrote:

 I am getting incorrect False-Negative results when performing tests
 with 186-4 vectors (generated by CAVS 17.6).
 
 This vector is being reported false while CAVS says they should pass.
 
 [mod = 1024]
 n = 
 d915e54ecbf96e1daadb5faa22856c4544a80c03d4cabeb58f7558a2ac9e939d387f86eebfa32aa81d6624def50684b46855a7cb86a15305ea84f34e9c18b1ca2b77e26f616f464cc675a9628aa2bc847c7a9f4ec2a3c49809901aa9ef76e5c779f621ddc791565708e65ea97a786653c745573c34310f135e29322d304fc009
 
 SHAAlg = SHA512
 e = 
 001f2acb
 Msg = 
 912ca58670bda8a7d76c2f97bbeb76b1d795bc4ff2a6a29864a7d599d72dec984bc394a45d25ea71c8af28632c1484e90e53550c20e77848c33ef29acb6dd6da82226a4befda857158543b220545bce0474d7a66b92a8a81c62c4d216be84fb03e316fa2b044414e8f43b0fccfe5e83f896b738544d6a1ec74572e5740071fc2
 S = 
 122efd4d9f6dd746b959aebfe8e23fb0181afce8905cae19861da977aaff4c97792c488b065cc0a0f5c97f50f6545a77606d2e9b3e3533d3c54f6feb3670888238f3a58569a77f7a3178df599f637b13eaf13fa7a7706a7970aa3ab725b5e844d2861cc56cfed910328a8cf45b6f053e06f2b18c1a71ee48b38fed757a99b0c3
 
 I've added some debug output and I get the following:
 
 DIGEST = 
 423d03646e5e4105181a5d9815b7fe3d588c3097ce7109ae4635add1be5ec026eb6860198914d1eb7fb1e62d86f60b3929fc6549d1b6b445ecc7b61219bf90d3
 SIG = 
 122EFD4D9F6DD746B959AEBFE8E23FB0181AFCE8905CAE19861DA977AAFF4C97792C488B065CC0A0F5C97F50F6545A77606D2E9B3E3533D3C54F6FEB3670888238F3A58569A77F7A3178DF599F637B13EAF13FA7A7706A7970AA3AB725B5E844D2861CC56CFED910328A8CF45B6F053E06F2B18C1A71EE48B38FED757A99B0C3
 N   = 
 D915E54ECBF96E1DAADB5FAA22856C4544A80C03D4CABEB58F7558A2AC9E939D387F86EEBFA32AA81D6624DEF50684B46855A7CB86A15305EA84F34E9C18B1CA2B77E26F616F464CC675A9628AA2BC847C7A9F4EC2A3C49809901AA9EF76E5C779F621DDC791565708E65EA97A786653C745573C34310F135E29322D304FC009
 RR  = 
 CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
 SUB = 
 CC2F99E162D3D6DC0B2178C5231FBAA42C94B954E08558D7E365F95641207114E50B7B55C4F8D968CE26DA9C2BFE2C6FD15629C7B0634A9B18489309AAC8423189392BB42F91F06590AE5AA4B928077680E69EC399910FCD921DAE0E7EE1F3C7B5C4EB9BBD97E4B4CBAE6012E7F978EED55F78FC2FF0C0C7FB4D0824C15D
 IR  = 
 CE64B6D692597419FB9E6E4FF65B1A1181352AEF44565DDAC0F5F4C6B7E228853740B98FAAA513F4F3F4A42C908584496FF7E03D63E086AD23C6044F1506F98A23EB6BB31DD55E735C74EBDD17AB50DFB94008B2912B4CA77734DDC416866E5862E6C18DBF598BF243192FB1A657E5A4E5681DCBB34DF229D6136E0282AFEAC
 SigVer Result = 0
 
 RR is the result of the power-E-mod-N operation, and SUB is the
 computed (N-RR) value.  IR is the choice of RR or (N-RR) used for
 the remainder of verification.
 
 It seems clear to me that neither RR nor SUB has the correct form,
 and that this vector should not pass.
 
 The lab is saying this must be a bug in OpenSSL, but no modification
 has been made that would introduce such a bug.  It's my contention
 that this is a bug in CAVS.  Can anyone shed some additional light
 onto the issue?
 

The Unix dc utility produces the same result. That's suggesting a problem
with the test data.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Extended master secret goober in s3_srvr.c

[Dr. Stephen Henson]

On Fri, Jun 12, 2015, Bill Cox wrote:

 Here's some code in master starting at line 594 in s3_srvr.c:
 
 if (!s-s3-handshake_buffer) {
 SSLerr(SSL_F_SSL3_ACCEPT, ERR_R_INTERNAL_ERROR);
 return -1;
 }
 /*
  * For sigalgs freeze the handshake buffer. If we support
  * extms we've done this already.
  */
 if (!(s-s3-flags  SSL_SESS_FLAG_EXTMS)) {
 s-s3-flags |= TLS1_FLAGS_KEEP_HANDSHAKE;
 if (!ssl3_digest_cached_records(s))
 return -1;
 }
 
 The goober is that s-s3-flags does not have a flag for
 SSL_SESS_FLAG_EXTMS.  This flag is defined for s-session-flags, not
 s-s3-flags.  What happens is that s-s3-flags generally has bit 0 clear,
 because this iis the flag for SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS.
 Therefore, this generally runs, and we set TLS1_FLAGS_KEEP_HANDSHAKE even
 if we have extended master secret support enabled.
 
 I haven't figured out yet what this does in the code.  If it were really
 bad, we would have heard about it already.  What was this code supposed to
 do, and how should it get fixed?
 

Nice catch. That code only gets called when TLS 1.2 client authentication is
used: I think it just means we digest cached records twice instead of once.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL for windows with /fixed flag

[Dr. Stephen Henson]

On Sun, May 24, 2015, Dixon Xavier wrote:

 Hi,
 
 Going by the description in links:
 http://openssl.6102.n7.nabble.com/FIPS-Module-1-2-build-with-Visual-Studio-2010-fails-self-tests-td36372.html
 http://mailing.openssl.dev.narkive.com/HfYeReuA/fips-module-1-2-build-with-visual-studio-2010-fails-self-tests
 
 I understand that adding /fixed flag for linker has resolved the 'FIPS
 selftest failure issues' when OpenSSL is built for 32-bit mode in VS
 2010.
 
 I would like to understand why the same change (adding /fixed) is
 *not* required in case of OpenSSL 64-bit builds.
 

The integrity test performs an in core hash. If a DLL gets relocated to an
address other than the original location then the hashes will be different
and the test will fail.

For 64 bits Windows builds (and other platforms whether 32 or 64 bits) the
compilers can be persuaded to output position independent code so the data
hashed is independent of the load address.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing API features

[Dr. Stephen Henson]

On Tue, Apr 21, 2015, Richard Moore wrote:

 On 21 April 2015 at 12:50, Dr. Stephen Henson st...@openssl.org wrote:
 
  I think what would be useful here would be an API that can determine
  appropriate characterictics of an SSL_CIPHER. For example a NID
  corresponding to the key exchange algorithm, signer, cipher and MAC. We
  have
  to find this stuff out internally but there is no exposed API to do this.
 
  Enough for an application to write its own version of
  SSL_CIPHER_description
  for example.
 
 
 Yes, that would be ideal.
 

I've just added a couple of SSL_CIPHER utility functions to the master branch
which handle the cipher and MAC. More to follow.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing API features

[Dr. Stephen Henson]

On Mon, Apr 20, 2015, Richard Moore wrote:

 On 20 April 2015 at 21:25, Salz, Rich rs...@akamai.com wrote:
 
   What is the information you're looking for? kx=X25519 or kx=2KRSA
   or ... ?  I picked those because sometimes there's a keysize, and other
  times it's implicit, for example.  The internal table is going to need
  restructuring.
 
 
 In the case of Qt both of those would work - the API we provide looks like
 this: http://doc.qt.io/qt-5/qsslcipher.html
 The basic idea is to provide the information to people using the API so
 that they can use it when describing the cipher to users. To be honest, I'm
 not sure how much of this users will actually understand in practice, but
 that's a different problem.
 

I think what would be useful here would be an API that can determine
appropriate characterictics of an SSL_CIPHER. For example a NID
corresponding to the key exchange algorithm, signer, cipher and MAC. We have
to find this stuff out internally but there is no exposed API to do this.

Enough for an application to write its own version of SSL_CIPHER_description
for example.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] CMS: is there a support for authenticated encryption (aes-gcm, aes-cbc-cmac etc.) in CMS?

[Dr. Stephen Henson]

On Mon, Apr 13, 2015, Pawe?? Ka??mierczak wrote:

 Hello,
 
 is there a support for aes-gcm in openSSL CMS implementaion?
 Following code works when EVP_aes_128_cbc is used as CMS_encrypt param but
 fails with EVP_aes_128_gcm. Am I missing something (like setting the gcm
 header/tag) or authenticated encryption is not supported in CMS?
 

No it's not currently supported and it would require support for a new content
type so it's not trivial to add either.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OID with length zero related bug

[Dr. Stephen Henson]

On Thu, Apr 09, 2015, Juan Antonio Osorio wrote:

 Hi,
 
 I've recently encountered that OpenSSL is sending some unexpected errors
 when reading X.509 certificate requests, if the key is not specified, or
 the CSR is not signed.
 

Well if a key is not specified ot the CSR isn't signed then it isn't a valid
CSR and OpenSSl should reject it. Previous versions included a bogus OID when
generating such a CSR which meant it could be parsed (but it was still
invalid).

The encoder should really reject this and refuse to encode it but applications
might not expect an error from the encoder.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] EC based certificates not supported in CMS - why?

[Dr. Stephen Henson]

On Thu, Apr 09, 2015, Pawe?? Ka??mierczak wrote:

 I am affraid EC certs do not work in CMS openSSL 1.0.2. I just wrote a
 simple test procedure:
 
 void cmsTest()
 {
   //this RSA works
   //auto certFileBio = BIO_new_file(c:\\a\\simplersa_noPem.cer, rb);
   //auto prvKeyFileBio = BIO_new_file(c:\\a\\simplersa_pkey.openssl,
 rb);
 
   //this EC not
   auto certFileBio = BIO_new_file(c:\\a\\advancedbr256r1_noPem.cer, rb);
   auto prvKeyFileBio = BIO_new_file(c:\\a\\advancedbr256r1_pkey.pkcs8,
 rb);
 
   auto evpPkey = d2i_PrivateKey_bio(prvKeyFileBio, 0);
   auto cert = d2i_X509_bio(certFileBio, 0);
   stack_st_X509* certStack = sk_X509_new_null();
   sk_X509_push(certStack, cert);
   X509_STORE* store = X509_STORE_new();
   X509_STORE_add_cert(store, cert);
 
   //sign
   auto inFileBio = BIO_new_file(c:\\tmp\\0_inContent.txt, rb);
   CMS_ContentInfo *cms = CMS_sign(cert, evpPkey, 0, inFileBio, 0);
   auto cmsOutFileBio = BIO_new_file(c:\\tmp\\1_signedCms.txt, wb);
   auto res = PEM_write_bio_CMS_stream(cmsOutFileBio, cms, 0, 0);
   BIO_free(inFileBio);
   BIO_free(cmsOutFileBio);
 
   //encrypt
   inFileBio = BIO_new_file(c:\\tmp\\1_signedCms.txt, rb);
   cms = CMS_encrypt(certStack, inFileBio, EVP_aes_128_cbc(), 0);
   auto ecnryptedCmsOutFileBio =
 BIO_new_file(c:\\tmp\\2_encryptedSignedCmsOut.txt, wb);
   res = PEM_write_bio_CMS_stream(ecnryptedCmsOutFileBio, cms, 0, 0);
   BIO_free(inFileBio);
   BIO_free(ecnryptedCmsOutFileBio);
 
   //decrypt
   inFileBio = BIO_new_file(c:\\tmp\\2_encryptedSignedCmsOut.txt, rb);
   cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0);
   auto decryptedCmsOutFileBio =
 BIO_new_file(c:\\tmp\\3_decryptedSignedCmsOut.txt, wb);
   res = CMS_decrypt(cms, evpPkey, cert, 0, decryptedCmsOutFileBio, 0); //
 ERROR HERE **
   BIO_free(decryptedCmsOutFileBio);
   BIO_free(inFileBio);
 
   //verify/read content CMS
   inFileBio = BIO_new_file(c:\\tmp\\3_decryptedSignedCmsOut.txt, rb);
   cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0);
   auto decodedCmsOutFileBio = BIO_new_file(c:\\tmp\\4_inContext.txt,
 wb);
   res = CMS_verify(cms, certStack, store, 0, decodedCmsOutFileBio, 0);
   auto signers = CMS_get0_signers(cms);
   BIO_free(inFileBio);
   BIO_free(decodedCmsOutFileBio);
 
   //deinit
   EVP_PKEY_free(evpPkey);
   sk_X509_free(certStack);
   X509_STORE_free(store);
   BIO_free(certFileBio);
   BIO_free(prvKeyFileBio);
 }
 
 and it works perfectly if RSA certificate is used but It fails during
 decrypt if I use the brainpool based certificates.
 The error occurs in cms_env.c, cms_env_asn1_ctrl function
 
 int cms_env_asn1_ctrl(CMS_RecipientInfo *ri, int cmd)
 {
 EVP_PKEY *pkey;
 int i;
 if (ri-type == CMS_RECIPINFO_TRANS)
 pkey = ri-d.ktri-pkey;
 else if (ri-type == CMS_RECIPINFO_AGREE) {
 EVP_PKEY_CTX *pctx = ri-d.kari-pctx;
 if (!pctx)
 return 0;
 pkey = EVP_PKEY_CTX_get0_pkey(pctx);
 if (!pkey)
 return 0;
 } else
 return 0;
 if (!pkey-ameth || !pkey-ameth-pkey_ctrl)
 return 1;
 i = pkey-ameth-pkey_ctrl(pkey, ASN1_PKEY_CTRL_CMS_ENVELOPE, cmd, ri);
 // this returns 0 *
 if (i == -2) {
 CMSerr(CMS_F_CMS_ENV_ASN1_CTRL,
CMS_R_NOT_SUPPORTED_FOR_THIS_KEY_TYPE);
 return 0;
 }
 if (i = 0) {
 CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_CTRL_FAILURE);
 return 0;
 }
 return 1;
 }
 
 the i = pkey-ameth-pkey_ctrl call returns 0 and error
 CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_CTRL_FAILURE is set.
 

The standard OpenSSL CMS tests in 1.0.2 include an ECDH test but using P-256.

Does the cms utility do the same?

Hmm... that might be something related to the use of brainPool: I'll check.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] EC based certificates not supported in CMS - why?

[Dr. Stephen Henson]

On Thu, Apr 09, 2015, Pawe?? Ka??mierczak wrote:

 Hi,
 
 currently openssl in CMS supports only RSA based certificates but EC based
 certificates are supported in openssl TLS... so I assume that there is
 already a code that can sing/verify and perform key agreement (ECKA-EG
 ECKA-DH) using eliptic curves.
 
 Can someone please tell me if this will be a lot of work to use that code
 in CMS in a way that CMS could work with EC based certificates?
 

OpenSSL 1.0.0 and later should support ECDSA in CMS. The use of ECDH is quite
rare: most implementations just use RSA key exchange. OpenSSL 1.0.2 does
support ECDH though.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Using TLSv1.2

[Dr. Stephen Henson]

On Tue, Mar 24, 2015,  ?? wrote:

 I use the openssl library in the project and use client certificate
 verification. When using protocol TLSv1.2 I have a problem with data
 encryption, using the private key of the client certificate. This is due to
 the fact that the certificate validation server selected encryption
 algorithm that is not supported by the crypt used to encrypt the signature
 on the client certificate (failure in method capi_rsa_sign of e_capi.c
 file).
 Now I have corrected the behavior as follows:
 - the method ssl3_send_client_certificate after selecting a client
 certificate makes cleaning pkeys [i].digest
 - the method ssl_set_cert if pkeys [i] .digest not specified, specify it.
 
 After that I worked with an application protocol TLSv1.2
 
 Is this correct or am I wrong to fix the library using openssl?

There are two ways to address this. One is to fix e_capi.c to use more digest
algorithms (though this wont help if the underlying CSP doesn't support them).
There is a fix in RT for this but it isn't in OpenSSL itself yet.

The other requires OpenSSL 1.0.2 where you can set a list of supported
signature algorithms for client authentication and OpenSSL will only use those
common to server and client for client authentication.

For that latter solution you  can use SSL_CTX_set1_client_sigalgs_list() which
takes a string argument in the same format as that used for the
SignatureAlgorithms command of SSL_CONF:

The value argument should be a colon separated list of signature
algorithms in order of decreasing preference of the form algorithm+hash.
algorithm is one of RSA, DSA or ECDSA and hash is a supported
algorithm OID short name such as SHA1, SHA224, SHA256, SHA384 of
SHA512. Note: algorithm and hash names are case sensitive.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Heap corruption in asn1_item_ex_combine_new()

[Dr. Stephen Henson]

On Tue, Mar 31, 2015, Julien Kauffmann wrote:

 
 if (!combine)
 *pval = NULL;
 

I'd suggest deleting the two lines above. The structure should be cleared
without this and the above line is wrong for non pointer fields anyway.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Heap corruption in asn1_item_ex_combine_new()

[Dr. Stephen Henson]

On Tue, Mar 31, 2015, Julien Kauffmann wrote:

 
 Basically what happens is that, somewhere inside the call to
 PEM_write_bio_ECPrivateKey(), an ASN1 sequence of 3 elements is
 allocated. The corresponding code is as follow (in
 crypto/asn1/tasn_new.c:181):
 
 if (!combine) {
 *pval = OPENSSL_malloc(it-size);
 if (!*pval)
 goto memerr;
 memset(*pval, 0, it-size);
 asn1_do_lock(pval, 0, it);
 asn1_enc_init(pval, it);
 }
 for (i = 0, tt = it-templates; i  it-tcount; tt++, i++) {
 pseqval = asn1_get_field_ptr(pval, tt);
 if (!ASN1_template_new(pseqval, tt))
 goto memerr;
 }
 
 In the sample I gave, at some point OPENSSL_malloc allocates 12
 bytes for a 3-elements ASN1 SEQUENCE. The for-loop then initializes
 every element: ASN1_template_new() calls in turn
 asn1_item_ex_combine_new() which, at line 103, does:
 

Can you determine the value of it-sname where this happens? That will
indicate the precise structure where this is a problem. From your description
I'd say it is X9_62_PENTANOMIAL.

 if (!combine)
 *pval = NULL;
 
 The problem is that pval at this point points to an element of the
 SEQUENCE that is only 4 bytes long. On 64 bits systems this causes
 the next 4 bytes to be set to 0x. For the first two elements
 of the sequence, this gets recovered by the next element being
 initialized. However for the last element, this affectation happens
 to write 4 bytes past the allocated memory, corrupting the heap.
 

This should only be a problem where sizeof(long)  sizeof(ASN1_VALUE *) on
many 64 bit platforms they are the same. I'd guess this is 64 bit Windows
you're testing on?

 I'm not sure what is the best place to fix this. Do you have any hints ?
 

I'll look into it.

In the meantime I'd suggest you add a call to use the named curve version of
EC parameters: this is only a problem with the explicit form which is very
rarely used but for historical compatibility reasons it is the default.
If you want to use the key for TLS you need the named curve form anyway.

To do this call:

EC_GROUP_set_asn1_flag(group, OPENSSL_EC_NAMED_CURVE);

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ASN1_UTCTIME_cmp_time_t behavior changed from 0.9.8 to 1.0.2 ?

[Dr. Stephen Henson]

On Tue, Mar 24, 2015, Susumu Sai wrote:

         time_t t;
         time(t);
 
         ASN1_TIME *tmptm = ASN1_TIME_new();
         X509_gmtime_adj(tmptm, 0);
 
         // ? With 0.9.8, the return value ret = 1 
         // ? With 1.0.2, the return value ret = -1
         int ret = ASN1_UTCTIME_cmp_time_t(tmptm, t);
 
 0.9.8 and 1.0.2 return different values. Is this as expected?

This is a bug in 1.0.2 which is fixed in 1.0.2a.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.0.2a released

[Dr. Stephen Henson]

On Thu, Mar 19, 2015, Randall S. Becker wrote:

 On March 19, 2015 10:09 AM OpenSSL wrote:
  To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML
  Subject: [openssl-dev] OpenSSL version 1.0.2a released
 OpenSSL version 1.0.2a released
 ===
  
 OpenSSL - The Open Source toolkit for SSL/TLS
 http://www.openssl.org/
  
 The OpenSSL project team is pleased to announce the release of
 version 1.0.2a of our open source toolkit for SSL/TLS. For details
 of changes and known issues see the release notes at:
 
 Will there be a git tag on the official commit openssl 1.0.2a released
 commit? The openssl_1_0_2_stable branch is a moving target. Happily, the
 1.0.1 versions all had tags. If not, would someone mind posting the official
 commit id from the github repo for this?
 

All releases have tags. In this case it is OpenSSL_1_0_2a I've just checked
and it is on the git.openssl.org repo. If it hasn't shown up on github the
commit ID is 1cf0ad8601847cf40d

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Dr. Stephen Henson]

On Thu, Mar 19, 2015, Erik Tkal wrote:

 
 If I do not send a sessionID in the clientHello but do send a valid
 sessionTicket extension, the server goes straight to changeCipherSpec and
 the client generates an UnexpectedMessage alert.
 

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Intent of the private_ wrappers

[Dr. Stephen Henson]

On Tue, Mar 10, 2015, Steve Schefter wrote:

 On 3/10/2015 8:03 PM, Dr. Stephen Henson wrote:
 On Fri, Mar 06, 2015, Steve Schefter wrote:
 
 
 Which OS and version of OpenSSL are you using?
 
 I am using 1.0.1j on Linux.  I've not tried to build 1.0.2, but I
 see the same use of the private_ wrappers in that code too.
 

Well in the case of 1.0.1 the private_ functions call the normal algorithms
in OpenSSL itself: i.e. not the validated ones at all. The low level functions
in the fips module being fips_* but as I said an application which calls the
low level APIs is not compliant.

 The intent of the private_ wrappers is to block the accidental use of low
 level APIs in appllications in FIPS mode. In FIPS mode you can only use EVP:
 so if an application did use low level APIs it would not be compliant.
 
 Okay, so that is mostly what I thought I understood.  Except for the
 accidental part.  I thought it was to block access altogether.
 
 Unfortunately, the use of the private_ wrappers doesn't work on
 Linux, or at least with my Linux.  If I run nm on libcrtypto, the
 private_ functions have a lower case t for the symbol type, meaning
 that they are within the local text (code) section.  They are not
 global.  So when it tries to build the OpenSSL-provided
 applications, the linker can't find the private_ functions.  This
 results in errors like, apps/speed.c: undefined reference to
 private_AES_set_encrypt_key.
 
 It would be possible to resolve this by adding the private_ wrappers
 to openssl.ld which would make them global within the library and
 not local.  But I'm not sure if their use should be more discouraged
 than that implies.
 

Well if the application is to be compliant it cannot use the low level APIs at
all. That's why the block is for accidental usage. If an application decides
to ignore than and bypass the blocking and use the private_* wrappers it's
free to do so with all the non-compliant consequences. 

I just built OpenSSL 1.0.1 from source using the normal build procedure on
Ubuntu Linux 14.04.2 and it *did* make the private_* symbols global in
libcrypto.so for example:

000e2180 T private_AES_set_decrypt_key
000e1eb0 T private_AES_set_encrypt_key

So I'm not sure why they're not global in your case.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Intent of the private_ wrappers

[Dr. Stephen Henson]

On Fri, Mar 06, 2015, Steve Schefter wrote:

 Hi.
 
 I am compiling OpenSSL with the FIPS options and seeing a build
 error. My question is more about the intent than the problem.
 
 One example:  When apps/speed.c is compiled with FIPS enabled,
 OPENSSL_FIPS is defined and DES_set_key_unchecked gets defined to be
 private_DES_set_key_unchecked.
 
 The use of the private_ function means that fips_cipher_abort is not called.
 
 Am I correct that the intent is to allow the OpenSSl-provided apps
 to use the low level APIs (like DES) while user applications linking
 with libcrypto.so can not?
 
 The problem is that the OpenSSL-provided apps also link with that
 library and the private_ functions are not global (they are not in
 openssl.ld).  So the OpenSSL-provided apps fail to link.  In the
 above example, apps/speed.c can't find
 private_DES_set_key_unchecked().
 
 Or am I not understanding the intent?
 

Which OS and version of OpenSSL are you using?

The intent of the private_ wrappers is to block the accidental use of low
level APIs in appllications in FIPS mode. In FIPS mode you can only use EVP:
so if an application did use low level APIs it would not be compliant.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3734] question about 0.9.7 branch

[Dr. Stephen Henson]

On Sat, Mar 07, 2015, Allauddin Ahmad via RT wrote:

 Dear Concerned:
 
 Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by:
 

As Viktor mentioned 0.9.7 is no longer being maintained. 

However the following two issues will be present in 0.9.7:

 
 *RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
 
 *Certificate fingerprints can be modified (CVE-2014-8275)
 

And possibly this one too:

 *Bignum squaring may produce incorrect results (CVE-2014-3570)
 

It is quite likely that thare are many more problems with 0.9.7 too.

Please don't post questions to the bug tracker.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] FIPS / RSA / ENGINE bug?

[Dr. Stephen Henson]

On Fri, Feb 27, 2015, Hong Cho wrote:

 Hi,
 
 I generated OpenSSL libcrypto (1.0.1l) with the OpenSSL FIPS crypto module
 (2.0.8) on FreeBSD 8.4 amd64.
 
 It seems to build fine, and with OPENSSL_FIPS, it seems to behave correctly
 (e.g., MD5 is refused, DH with 512-bit key is refused, etc.).
 
 However, genrsa(1) is failing with the following message.
 
 --
 # /usr/bin/openssl genrsa -out rsa1 2048
 Generating RSA private key, 2048 bit long modulus
 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
 method:[...]/openssl/crypto/rsa/rsa_gen.c:88:
 --
 
 So, I put some debugging printf's, and this is what I found.
 
 --
 # /usr/bin/openssl genrsa -out rsa1 2048
 XXX MAIN: engine = 0x0
 Generating RSA private key, 2048 bit long modulus
 XXX MAIN: e = 0x0
 XXX RSA_get_default_method: returning FIPS_rsa_pkcs1_ssleay()
 XXX RSA_new_method: ret-meth = 0x800b4a7e0
 XXX RSA_new_method: engine = 0x0
 XXX RSA_new_method: ret-engine = 0x800e28100
 XXX RSA_new_method: ret-meth = 0x800b2ee40
 XXX MAIN: rsa-meth = 0x800b2ee40
 XXX RSA_generate_key_ex: rsa-meth = 0x800b2ee40
 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
 method:/usr/home/hongch/ns_depot/TOT/usr.src/crypto/openssl/crypto/rsa/rsa_gen.c:88:
 --
 
 ???So, it seems like the FIPS RSA_METHOD gets overridden by the default
 ENGINE (the machine does not have any hardware crypto module), which does
 not have??? the RSA_FLAG_FIPS_METHOD flag set.
 
 I understand that I can rebuild the library with ./config no-engine, but
 I haven't seen this mentioned in the FIPS guide.
 
 Is this the right way to do it? Or can the interaction between FIPS and
 (the default) ENGINE be better?
 

Can you work out which ENGINE it is that is doing that? If you print out
ENGINE_get_id(engine) that will show it. I'm guessing it's the cryptodev
ENGINE?

Using no-engine is the only way I can immediately think of to address this
without modifying OpenSSL or making some API calls to disable the ENGINE.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Need Help with BIO callback and/or BIO filter chain

[Dr. Stephen Henson]

On Fri, Feb 20, 2015, W Smith wrote:

 Thanks, Rich.
 
 Does anyone know how to walk through a BIO stack that includes a BIO pair 
 and get to the ultimate source/sink BIO? If I can get that, I'll be in good 
 shape. Anybody?
 

Not sure I follow you. A BIO pair is the ultimate source/sink BIO. The data
read from or written to the BIO may come from another BIO (or any source
whatsoever) but that depends on application code and the BIO pair doesn't
contain any information about where its data comes from.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Need Help with BIO callback and/or BIO filter chain

[Dr. Stephen Henson]

On Fri, Feb 20, 2015, W Smith wrote:

 Rich,
 
 Yeah, I have industrial strength Tylenol standing by. I'm expecting this to 
 be painful, but not insurmountable for the handshake. If I'm unable to even 
 get at the ultimate source/sink, I can't get anywhere.
 
 I can deal with the HTTP side and the plethora of application-specific and 
 threading issues, but I'm lost on the BIO part. I'll take any pointers or 
 suggestions you can offer.
 

If I understand what you're trying to do I can see a couple of options.

One is to write your own BIO which looks like an ordinary BIO to the TLS
library but does all the translation under the hood. You could start with the
socket BIO and adapt it to your needs, making sure you handle non-blocking I/O
correctly.

The other is a BIO pair where this I/O can be handled at an application level
but you have to be careful to get everything right so there aren't any
deadlocks. You mentioned a BIO pair in the other message though. Are you
already using a BIO pair?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Dr. Stephen Henson]

On Fri, Feb 13, 2015, Viktor Dukhovni wrote:

 On Fri, Feb 13, 2015 at 11:59:13AM +, Salz, Rich wrote:
 
   Some time ago, I had submitted a patch which allows administrators, but
   most importantly OS distributors to set their own strings in the 
   configuration
   file, which software can then rely on, to provide a consistent security 
   level:
   https://github.com/openssl/openssl/pull/192
  
  And my intent is to pull this into master pretty soon.
 
 And applications would need to opt-in to having this new profile
 apply, or more usefully need to be able to choose which
 application-specific file contains the desired profile.  there's
 no such thing as a universal profile that works for all software.
 
 We may not need a patch for this, I thought we were about to deprecate
 OpenSSL_config() with its void return status and encourage folks
 to use the NCONF API, which should be able to handle this, or be close
 in any case.
 

Just clarification. The initialisation we're recommending I normally refer
to as config modules. NCONF is a more general API for configuration files.

Config modules were intended to be used for application setup so would
be a good place to add a system cipher string instead of a whole new mechanism.
The only problem is that it would only work with application that supported
config modules.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Proposed cipher changes for post-1.0.2

[Dr. Stephen Henson]

On Tue, Feb 10, 2015, Viktor Dukhovni wrote:

 
 We should also recall that the master branch has introduced security
 levels, which may still need some work to become production-ready,
 but are likely a better mechanism for applications to move to more
 secure settings than incompatible changes in existing interfaces.
 

I'd agree that the best approach is to use security levels. This covers
a far wider set of parameters than just ciphersuites.

For example on the master branch the default security level is 1:

   The security level corresponds to a minimum of 80 bits of security.
   Any parameters offering below 80 bits of security are excluded. As
   a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys
   shorter than 160 bits are prohibited. All export ciphersuites are
   prohibited since they all offer less than 80 bits of security. SSL
   version 2 is prohibited. Any ciphersuite using MD5 for the MAC is
   also prohibited.

This happens no matter what the cipher string is set to (unless it forcibly
lowers the security level). So an application setting ALL will get the
above conditions.

In the light of poodle this could be ammended to make SSLv3 disabled at level
1 or above.

Currently level 1 is the only real general purpose default (due to widespread
use of SHA1 in certificates which offer less than 80 bits of security).

The levels could be extended so there is more than one usable level.

Security levels can currently only completely disable ciphersuites: this
could be extended so they can prioritise them instead. For example that
would allow the use of PFS+AEAD ciphersuites first, PFS not AEAD second
and as a last resort RC4 at some levels.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] FIPS compliant digital signature

[Dr. Stephen Henson]

On Wed, Feb 04, 2015, Rex Bloom wrote:

 Can someone help me understand what type of digital signature I can use for 
 FIPS compliance.
 
 I used this command:
 
 openssl genrsa -aes128 -passout pass:mypassphrase -out privkey.pem 2048
 
 to generate a pem file but when I tried to load this as follows:
 
 RSA *rkey = PEM_read_bio_RSAPrivateKey( bio, 0, 0, (void*)mypassphrase);
 
 I receive this error
 
 error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips'.
 
 Can you point to anything I am doing wrong here?
 

This is an openssl-users question not openssl-dev.

You need to be in FIPS mode when you create the key. So if you do:

OPENSSL_FIPS=1 openssl genrsa ...

It should work.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Disabling SSLv3 in OpenSSL 0.9.8a

[Dr. Stephen Henson]

On Fri, Jan 23, 2015, Thirumal, Karthikeyan wrote:

 Team,
 In order to fix the Poodle vulnerability on SSLv3, I tried to disable my 
 SSLv3 cipher using the below cipher set, but did not even initiate SSL in 
 0.9.8a.
 
 SSL_CTX_set_cipher_list(ssl_ctx,SHA1+HIGH:!SSLv2:!SSLv3:!aNULL:!eNULL:@STRENGTH);
 
 Without !SSLv3 - by SSL connection is working fine by blocking just SSLv2.
 
 Can you advise if the above cipher list is right ?
 

You can't disable SSL 3.0 using a cipher list. The string SSLv3 indicates
ciphers which require a minimum of SSL 3.0 and so includes ciphersuites 
which can be used for SSL 3.0 or TLS 1.0. There aren't any ciphersuites
suitable for TLS 1.0 and not SSL 3.0 so when you use !SSLv3 you disable
all TLS 1.0 and SSL v3.0 ciphersuites.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Pausing TLS negotiation after client hello

[Dr. Stephen Henson]

On Fri, Jan 23, 2015, Susan Hinrichs wrote:

 Hello All,
 
 I work with Apache Traffic Server.  Many of our users use the SNI
 callback to select the certificate that the proxy will present to
 the client.  This selection can take some time.  Rather than
 blocking the callback thread, we would like to pause the negotiation
 from the SNI callback.  After the certificate has been selected,
 SSL_accept can be called again to continue the processing.
 
 Looking at documentation and code, I did not see a way to do this,
 so I created a small patch on 1.0.1f.  I'll say a few words about
 the patch below.
 
 But first, is there another way to achieve this in the existing
 1.0.x API or the proposed 1.1 API?
 

OpenSSL 1.0.2 has a certificate callback which can be used for both client
and server certificates. It also supports non-blocking I/O so you can
pause in the manner you describe.

See:

https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] unloading certificates

[Dr. Stephen Henson]

On Tue, Dec 30, 2014, satish.kumarya...@cognizant.com wrote:

 Hi
 Is there any way to unload client certificate and private key from SSL 
 context?
 I could not find any openss api to unload client cert from SSL object.
 

There is a function SSL_certs_clear() but it is only in OpenSSL 1.0.2+

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Dr. Stephen Henson]

On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote:

 
 are hard (not only to parse) for users but there is a lot of
 information for good in very few bytes; sad is
 
   Received SIGPIPE during IMAP operation
   IMAP write error: error::lib(0):func(0):reason(0)
 

OpenSSL itself should never generate that error through (for example)
ERR_print_errors(): if anyone can do that I'd like details and it will be
fixed. If ERR_get_error() returns zero it indicates there is no error in
the error queue if an application doesn't check for that value
and attempts to interpret it as an error code you get the result above...

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [openssl-dev] Openssl Shared library mode compilation

[Dr. Stephen Henson]

On Thu, Dec 11, 2014, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES 
LIMITED at Cisco) wrote:

 
 Hi Team,
 
 For Vulnerability issue, we are indeed to upgrade the openssl version to 
 0.9.8zc version. We have downloaded the source from 
 www.openssl.orghttp://www.openssl.org site. While compiling we have 
 followed the below steps including environment variables setting ready for 
 compilation. But we are unable to compile with shared basis. Previously we 
 have used this option but with this openssl version we are unable to compiled 
 in shared basis.
 
 Steps followed:
 =
 VCVARS32.BAT
 perl Configure VC-WIN32 no-idea shared --prefix=c:/openssl  -- Shared 
 option is giving the problem. Without shared option compilation get 
 successful.
 ms\do_masm
 nmake -f ms\ntdll.mak
 
 Can anyone help us to compile with Shared option for this openssl 
 version(0.9.8zc) ?
 

You don't use the shared option for VC builds. Two makefiles are
generated: ms\ntdll.mak creates shared libraries while ms\nt.mak creates 
static ones.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev

Re: [PATCH] Add API to set minimum and maximum protocol version.

[Dr. Stephen Henson]

On Thu, Dec 04, 2014, Tomas Hoger wrote:

 On Wed, 3 Dec 2014 22:55:06 +0100 Kurt Roeckx wrote:
 
 Maybe applications may benefit from an API where they can pass string
 set by the end user and let OpenSSL parse version number from that.
 If mod_ssl had configuration directives as SSLProtocolMin and
 SSLProtocolMax, it could e.g. use the following while used with OpenSSL
 1.0.0:
 
 SSLProtocolMin TLSv1.0
 
 instead of
 
 SSLProtocol all -SSLv2 -SSLv3
 
 If TLS 1.2 is undesired after rebase to OpenSSL 1.0.1, this can be
 added:
 
 SSLProtocolMax TLSv1.1
 
 The httpd could be able to treat SSLProtocolMin/Max strings as opaque,
 just like SSLCipherSuite.
 

This can already be done in the SSL_CONF API for OpenSSL 1.0.2+. Apache
httpd (and hopefully other applicacations at some point) includes support
so we'd just need to add a new command value.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3606] Need RSA_pubkey_digest()

[Dr. Stephen Henson]

On Tue, Nov 25, 2014, Philip Prindeville via RT wrote:

 
 On 11/25/2014 07:48 AM, Matt Caswell via RT wrote:
  On Thu Nov 20 21:35:45 2014, phil...@redfish-solutions.com wrote:
  Can the following function please be added:
 
  int RSA_public_digest(const RSA* key, const EVP_MD *type, unsigned
  char *md, unsigned int *len);
 
  which would use ???type??? to generate a digest over the DER encoding of
  the public portion of ???key???, and deposit ???len??? bytes into the
  buffer starting at ???md???.
 
  A similar function:
 
  int RSA_private_digest() would take the same parameters as
  RSA_public_digest(), but for the DER encoding of the private key.
  This function is less useful than the first, but is useful for
  symmetry in the API and some corner cases.
  This could be done quite simply using i2d_RSA_PUBKEY (or i2d_RSAPublicKey
  depending on what flavour of public key you want) and then using the
  EVP_Digest* functions.
 
  Closing this ticket.
 
  Matt
 
 
 Okay, but why not include a convenience wrapper to do it, whether it's 
 easy or not?
 
 It seems to be a frequent construct.
 

I'm curious: I've not seen the private key version before, where is it used?

You can actually perform the encode and digest operation all in one go using
the ASN1_item_digest function. Something like this should work:

rv = ASN1_item_digest(ASN1_ITEM_rptr(RSAPublicKey), mdtype, rsa,
md, 
mdlen);

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Low Level Digest if Fips mode

[Dr. Stephen Henson]

On Mon, Nov 24, 2014, Philip Bellino wrote:

 Hello,
 I am looking for some help  and I do not profess to be an expert in this 
 area, so forgive me for asking the following.
 
 I am running openssl-fips-2.0.7 with openssl-1.0.1j in my application(in FIPs 
 mode) and am trying to figure out how to get around the following issue:
 
 
 sha_locl.h(128): OpenSSL internal error, assertion failed: Low level API call 
 to digest SHA1 forbidden in FIPS mode!
 
 
 From the openssl-1.0.1j CHANGES file, I see the following entry:
 
 Low level digest APIs are not approved in FIPS mode: any attempt
  to use these will cause a fatal error. Applications that *really* want
  to use them can use the private_* version instead.
  [Steve Henson]
 
 Does this mean that if I want to use  low level digest APIs that I would 
 comment out the  ' if (FIPS_mode())' test below?
 If this is correct, am I now violating FIPS?
 
 From crypto/crypto.h:
 
 #ifdef OPENSSL_FIPS
 #define fips_md_init_ctx(alg, cx) \
  int alg##_Init(cx##_CTX *c) \
  { \
  if (FIPS_mode()) OpenSSLDie(__FILE__, __LINE__, \
Low level API call to digest  #alg  forbidden in FIPS mode!); \
  return private_##alg##_Init(c); \
  } \
  int private_##alg##_Init(cx##_CTX *c)
 
 
 If I am barking up the wrong tree(so to speak), what would be the correct 
 course of action for me to take?
 

BIG DISCLAIMER: This is a rather complex topic with many differing opinions so
I'll only give mine FWIW.

During the design of the FIPS module it was hoped that changing applications
to support FIPS mode would be a relatively simple process. However it was also
realised that existing applications could perform operations which would
normally be prohibited in FIPS mode. For example use of weak or unapproved
algorithms or APIs that bypass some of the FIPS requirements.

If these were allowed by default then each application would have to be
carefully checked to see if it didn't use any prohibited algorithms or APIs
a tedious error prone process which could result in some applications claiming
compliance when they weren't.

To partly resolve this a form of blocking was introduced which returns
errors or in some cases hard asserts failures.

[The reason for the hard assert failures is that some APIs which need to be
blocked have no mechanism to return an error *or* they would always
succeed so applications might not even check errors with potentially severe
consequences]

That however isn't the complete story. There are some unusual circumstances
under which the use of an unapproved algorithm or API might be acceptable even
in FIPS mode. An internal example of that is the use of MD5 for TLS in the PRF.
As a result a mechanism was included to bypass the algorithm or API blocking.
The fact that this isn't done by default means an application writer
(hopefully!) has to think very hard before decidicing to override the
blocking.

TL;DR: in your case it's highly likely you'll have to use the EVP APIs for SHA1
use.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Openssl 1.0.1h | RHEL-6 | x86_64 | Crash in lh_retrieve

[Dr. Stephen Henson]

On Wed, Aug 06, 2014, arun11299 wrote:

 Hello Folks,
 I am experiencing a hard to debug crash in openssl crypto library within our
 process. 
 We have a client and server which communicates using SSL with NULL
 encryption. The client when it connects to the server sends a Certificate
 signing request, the server responds by sending the server certificate. All
 works fine during test and even under load using openssl version 0.9.8 and
 also 1.0.1f I believe, but we are experiencing crash with version 1.0.1h
 under load setup (Once every day).
 
 The simulator which we use to simulate a client disconnects and connects
 back to the server many times, each time asking for the certificate from the
 server. The crash was seen just once the entire day. So I dont think its
 anywhere close to broken functionality. Looks like more of a race issue.
 
 Similar references:
 http://openssl.6102.n7.nabble.com/Crash-in-libcrypto-so-1-0-0-td42043.html
 
 Also, I have verified the data sent by the client from the core dump using a
 test program.
 Also from openssl command:
 openssl req -inform DER -in filebin -verify
 verify OK
 ...
 
 
 
 So it is not that the client is sending corrupt data, even if it was
 sending, it should have failed in d2i_X509_REQ which we call before
 calling X509_REQ_verify.
 
 This is the stack trace we get (Top half only):
 
 Thread 1 (Thread 0x7fa62851d700 (LWP 19528)):
 #0  0x7fa62657f2d6 in __strcmp_sse42 () from /lib64/libc.so.6
 #1  0x7fa6276f5b4a in ?? () from /usr/lib64/libcrypto.so.10
 #2  0x7fa6276f5b8c in lh_retrieve () from /usr/lib64/libcrypto.so.10
 #3  0x7fa62767c758 in OBJ_NAME_get () from /usr/lib64/libcrypto.so.10
 #4  0x7fa62770d49d in ASN1_item_verify () from
 /usr/lib64/libcrypto.so.10
 #5  0x008a1fd7 in ca::CA::process_cert_request(unsigned char const*,
 unsigned long, std::vectorunsigned char, std::allocatorunsigned char *)
 ()
 

It's hard to tell from that description but it could be a race condition
relating to algorithm tables. That might happen if you add all algorithms and
remove them on every invocation of a function instead of adding them just once
on application startup.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Openssl 1.0.1h | RHEL-6 | x86_64 | Crash in lh_retrieve

[Dr. Stephen Henson]

On Thu, Aug 07, 2014, Arun Muralidharan wrote:

 Thanks Stephen for your reply. I am doing OpenSSL_add_all_digests in
 one of my class initialization routine, so it gets called whenever an
 instance of this class gets created (I am now building my code with
 this removed). But I am not removing digests/algorithm as you mention,
 I am just adding them. Can it still be the reason  for this race ?
 

It could be yes. The algorithm tables should be initialised when the
application starts up. If they could be modified when other threads are
attempting to read from the tables that could result in the problem you are
seeing.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Should this got a CVE number assignment or is it not a real security issue?

[Dr. Stephen Henson]

On Thu, Aug 07, 2014, Tomas Mraz wrote:

 Hi,
 during the review of OpenSSL commits I found this one:
 https://github.com/openssl/openssl/commit/22a10c89d7c3f951339c385d57cc8fd23c0a800b
 
 There is unfortunately not much detail in the commit message. Could this
 be a possible security issue? Can you please clear that up?
 

The commit log message is somewhat unfortunate ;-)

The commit combines some cosmetic changes with a correction to see if there
is enough room for two extensions: renegotiation and SRTP.

In practice an overrun is not possible becaue at most a few bytes is written
to a BUF_MEM structure which is grown to 16k calling BUF_MEM_grow which
actually ends up allocating additional space making it 21848 bytes in length.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: Need guidance to replace HMAC-SHA1 implementation via engine

[Dr. Stephen Henson]

On Tue, Jul 29, 2014, Jitendra Lulla wrote:

 Hi Steve,
 
 Please refer the following mail from you:
 
 http://www.mail-archive.com/openssl-dev%40openssl.org/msg32918.html
 
 ...
 The high level MAC (including HMAC) interfaces go through EVP_PKEY treating it
 as a signing operation. It *is* possible to redirect HMAC in that way but only
 if the application uses the EVP_PKEY MAC interface. Anything using the HMAC_*
 functions directly wont use the ENGINE.
 
 There is a big gotcha though. The lucky 13 attack fix had to bypass EVP
 entirely and reimplement HMAC (and SSLv3 MAC) in constant time. That means
 that the record MAC operations for SSL/TLS can no longer be redirected through
 an ENGINE. At some point this will be addressed but it requires support at the
 ENGINE (and associated hardware) too: to implement the appropriate constant
 time algorithms.
 
 Steve
 ..
 
 
 could you please help me find the changeset that fixed the lucky 13 attack?
 I am in need of testing my engine which is supposed to take care of the 
 following command:
 ./openssl dgst -engine af_alg -sha1 -mac hmac -macopt 
 hexkey:f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff data_32.txt
 
 The command gives the correct hmac but without going through the engine!

Only the SSL/TLS code goes through the lucky 13 fix so if the command line
utility isn't using your HMAC implementation it isn't anything to do with
that.

Redirecting HMAC is currently rather more complex than it should be.

There is an example in eng_openssl.c which redirects HMAC: look at the code
near TEST_ENG_OPENSSL_HMAC.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org