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

[Blumenthal, Uri - 0553 - MITLL]

On 1/19/18, 12:52, "Salz, Rich"  wrote:

 >> It appears to me that you could use openssl-dev instead of openssl-project, 
 >> saving cycles on killing
>> one and creating the other.
>
>  We discussed that, but it would be harder to “undo” if things don’t work 
> out, we wanted
>   to make it very clear that this is a new way of operating, and 
> openssl-project is a
>   moderated list.  Make sense?

I don’t know. I’d still do as I said. But since you guys discussed it (i.e., 
debated this option), I’ll defer to your judgment.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

It appears to me that you could use openssl-dev instead of openssl-project, 
saving cycles on killing one and creating the other.

--
Regards,
Uri Blumenthal

On 1/19/18, 12:35, "openssl-dev on behalf of Salz, Rich via openssl-dev" 
 wrote:

There’s a new blog post at 
https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

It contains some important policy changes we decided at our meeting last 
month.  This includes:
- Closing the openssl-dev mailing list; use GitHub for issues
- New mailing list openssl-project for project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who 
uses OpenSSL.  Thanks for your interest, and all your efforts to help improve 
the project!



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type deviation from spec

[Blumenthal, Uri - 0553 - MITLL]

I think the change is justified.
—
Regards,
Uri

> On Jan 16, 2018, at 14:31, Sands, Daniel  wrote:
> 
> On Tue, 2018-01-16 at 14:50 +, Salz, Rich via openssl-dev wrote:
>> OpenSSL defines it as a SET OF and the spec says it’s a SEQUENCE
>> OF.  Ouch!  Will that cause interop problems if we change it?  (I
>> don’t remember the DER encoding rules)
>> 
>> 
>> 
> 
> Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a
> quick reference I found.  So that could be an interoperability concern.
> But maybe this is the first actual use of nested safecontents, since
> this difference flew under the radar for so long :)
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

I think being able to interoperate with IoT devices using SPECK is a good idea.

I'd like to know what kind of key exchange is likely to be used there.

Regards,
Uri

Sent from my iPhone

> On Jan 9, 2018, at 04:58, Richard Levitte  wrote:
> 
> I'm not terribly savvy regarding IoT, but I imagine that they do talk
> to something bigger.  A server end, perhaps?  What do we expect to run
> on that end?  What happens, in that case, if SPECK makes its way into
> the TLS cipher suites?  Would it be interesting to have OpenSSL
> interop with such devices?
> 
> Note: I'm not terribly partial either way, just thought that we need
> to look at it from a broader perspective...
> 
> Cheers,
> Richard
> 
> In message  on Mon, 8 Jan 2018 
> 13:58:59 -0800 (PST), Paul Dale  said:
> 
> paul.dale> I'm wondering if one of the more specialised embedded 
> cryptographic toolkits mightn't be a better option for your lightweight IoT 
> TLS stack.  There is a wide choice available: CycloneSSL, ECT, Fusion, 
> MatrixSSL, mbedTLS, NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others.  All 
> of them claim to be the smallest, fastest and most feature laden :)  To sell 
> to the US government,  your first selection criteria should be "does the 
> toolkit have a current FIPS validation?"  From memory this means: ECT, 
> nanoSSL or WolfSSL.
> paul.dale> 
> paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less 
> suitable for embedded applications, especially tightly resource constrained 
> ones.  It is possible to cut OpenSSL down in size but it will never compete 
> with the designed for embedded toolkits.  Plus, the FIPS module is fixed and 
> cannot be shrunk.
> paul.dale> 
> paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds 
> currently.  FIPS is on the project plan for 1.1 but it isn't available at the 
> moment.  The US government is forbidden to purchase any product that contains 
> cryptographic operations unless the product has a FIPS validation.  No FIPS, 
> no sale.
> paul.dale> 
> paul.dale> 
> paul.dale> Pauli
> paul.dale> -- 
> paul.dale> Oracle
> paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> paul.dale> Phone +61 7 3031 7217
> paul.dale> Oracle Australia
> paul.dale> 
> paul.dale> -Original Message-
> paul.dale> From: William Bathurst [mailto:wbath...@gmail.com] 
> paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
> paul.dale> To: openssl-dev@openssl.org
> paul.dale> Cc: llamour...@gmail.com
> paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL
> paul.dale> 
> paul.dale> Hi Hanno/all,
> paul.dale> 
> paul.dale> I can understand your view that "more is not always good" in 
> crypto. The reasoning behind the offering can be found in the following 
> whitepaper:
> paul.dale> 
> paul.dale> 
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
> paul.dale> 
> paul.dale> I will summarize in a different way though. We wish to offer an 
> optimized lightweight TLS for IoT. A majority of devices found in IoT are 
> resource constrained, for example a device CPU may only have 32K of RAM. 
> Therefore security is an afterthought by developers. For some only AES 128 is 
> available and they wish to use 256 bit encryption. Then Speck
> paul.dale> 256 would be an option because it has better performance and 
> provides sufficient security.
> paul.dale> 
> paul.dale> Based on the above scenario you can likely see why we are 
> interested in OpenSSL. First, OpenSSL can be used for terminating lightweight 
> TLS connections near the edge, and then forwarding using commonly used 
> ciphers.
> paul.dale> 
> paul.dale> [IoT Device] -TLS/Speck>[IoT Gateway]-TLS> 
> [Services]
> paul.dale> 
> paul.dale> Also, we are interested in using OpenSSL libraries at the edge for 
> client creation. One thing we would like to do is provide instructions for an 
> highly optimized build of OpenSSL that can be used for contrained devices.
> paul.dale> 
> paul.dale> I think demand will eventually grow because there is an initiative 
> by the US government to improve IoT Security and Speck is being developed and 
> proposed as a standard within the government. Therefore, I see users who wish 
> to play in this space would be interested in a version where Speck could be 
> used in OpenSSL.
> paul.dale> 
> paul.dale> It is my hope to accomplish the following:
> paul.dale> 
> paul.dale> [1] Make Speck available via Open Source, this could be as an 
> option or as a patch in OpenSSL.
> paul.dale> [2] If we make it available as a patch, is there a place where we 
> would announce/make it known that it is available?
> paul.dale> 
> paul.dale> We are also looking at open-sourcing the client side code. This 
> would be used to create light-weight clients that use Speck and currently we 
> 

Re: [openssl-dev] Certificate Limitation Profile

[Blumenthal, Uri - 0553 - MITLL]

I'm wondering how you think that policy will be distributed and
why it needs signed. …

For instance it might come as part of some software distribution (like a 
browser), and either
you trust all the files in that distribution or you don't.

 

I agree that an unsigned variant of CLP makes sense.

But it seems to me that if CLP is signed by the certificate that can be 

verified using standard chain of trust, it has some advantages. 

 

I think it makes perfect sense to sign CLP, because it allows you to separate 
trust in the server you’re downloading the content from and the content itself.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

[Blumenthal, Uri - 0553 - MITLL]

Matt and Steve,

Thank you! I indeed fancied creating a PR to add those: 
https://github.com/openssl/openssl/pull/4452

;-)
--
Regards,
Uri Blumenthal

On 10/2/17, 12:41, "openssl-dev on behalf of Dr. Stephen Henson" 
<openssl-dev-boun...@openssl.org on behalf of st...@openssl.org> wrote:

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

[Blumenthal, Uri - 0553 - MITLL]

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?

--

Regards,

Uri Blumenthal

 

From: Uri Blumenthal <u...@ll.mit.edu>
Date: Sunday, October 01, 2017 at 19:59
To: <openssl-us...@openssl.org>
Subject: Re: [openssl-users] Missing EVP_PKEY method to set engine?

 

Thank you! 

 

I observe that in 1.1.x everything's fine - the structure evp_pkey_methods_st 
is opaque, but both getters and setters are defined and available. 

 

In 1.0.2 the structure is already opaque, the setters are present, but some 
getters are absent. Which makes it quite hard to work with members of this 
structure.

 

I think this is a bug, and two possible remedies INHO are: add getter functions 
for the members, or add/move this structure from evp-int.h to evp.h (so it's no 
longer opaque).

 

What is your opinion? 

 

Thanks!

 

Regards,

Uri

 

Sent from my iPhone


On Oct 1, 2017, at 18:54, Dr. Stephen Henson <st...@openssl.org> wrote:

On Fri, Sep 29, 2017, Blumenthal, Uri - 0553 - MITLL wrote:



Apologies in advance for cross-posting ??? but I???m not sure which of the two 
mailing lists this belongs to.

 

A key (say, private key) is loaded from the pkcs11 engine via privkey = 
ENGINE_load_private_key(engine, ); and this operation succeeds.

 

However the resulting key handle has its engine == NULL. I looked for a method 
or a macro to explicitly set that value to the pointer to the engine that this 
key is bound to, but couldn???t find any. I define new methods such as 
pkcs11_pkey_rsa_decrypt(), and  try to make OpenSSL aware of them via:

 

EVP_PKEY_METHOD *orig_pmeth = EVP_PKEY_meth_find(EVP_PKEY_RSA);

 

   EVP_PKEY_METHOD *pmeth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 
EVP_PKEY_FLAG_AUTOARGLEN);

 

   EVP_PKEY_meth_copy(pmeth, orig_pmeth);

 

   EVP_PKEY_meth_get_decrypt(orig_pmeth, _init, );

 

   EVP_PKEY_meth_set_decrypt(pmeth, pdecr_init, pkcs11_pkey_rsa_decrypt);

 


There doesn't seem to be any easy way to do that for an existing method. If
the ENGINE has its own ASN.1 method things become easier.

A workaround might be to use a copy of an existing A workaround might be to
create a copy of an existing ASN.1 method but I've not tried that.



 

In ENGINE_set_pkey_meths(engine, pkey_meths) what should pkey_meths() actually 
be? Is it documented? 

 

 


Not currently but it similar to the cipher/digest functions but handles
EVP_PKEY_METHOD instead.

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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

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.

Since hardware tokens I’m dealing with do not perform any public key operations 
(the engine in this case is used to merely pull and provide the public key  to 
the requestor) I’m somewhat ambivalent about writing engine Encrypt function 
specifically for handling the NULL argument case. On the one hand, it’s the 
simplest solution, and it avoids going through OpenSSL modification process.;) 
On the other hand, it’s not as clean as I’d like.

Where would I set this flag ? And would it work when the public key is on the 
token, and needs to be retrieved via engine?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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 fix should be adding something like

 

  if (out == NULL) {

   int klen = RSA_size(ctx->pkey->pkey.rsa);

   *outlen = klen;

   return 1;

  }

 

right before the call to RSA_public_encrypt().

 

P.S. It’s more critical in pkey_rsa_encrypt(), because it’s more likely that 
the engine would handle the decryption operation completely by itself.

--

Regards,

Uri Blumenthal



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Bug: digest parameter is rejected

[Blumenthal, Uri - 0553 - MITLL]

See crypto/rsa/rsa_pmeth.c pkey_rsa_ctrl_str for the options.
There is also rsa_oaep_label

Thank you!! That saved the day:
. . . . .
Where can I see the complete list of the options that “-pkeyopt” supports 
now?

I missed the crypto/rsa/rsa_pmeth.c pkey_rsa_ctrl_str part. ;-(
Apology for not paying attention.

The label is supplied as the initial hash, hex-encoded, right?

Oh, it would be nice to add “rsa_oaep_md:digest” and “rsa_oaep_label:hexstring” 
to the man page. ;-)




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Bug: digest parameter is rejected

[Blumenthal, Uri - 0553 - MITLL]

RSA-OAEP supports different hash functions and MGF. SHA-1 is the default.

 

OpenSSL implementation of OAEP wrongly refuses to set the hash algorithm, 
preventing one from using SHA-2 family:

 

$ openssl version

OpenSSL 1.0.2l  25 May 2017

$ openssl pkeyutl -encrypt -in t1264.dat -out t1264.dat.enc2.oaep -keyform DER 
-pubin -inkey rsa3072pub.der -pkeyopt rsa_padding_mode:oaep

$ openssl pkeyutl -encrypt -in t1264.dat -out t1264.dat.enc2.oaep -keyform DER 
-pubin -inkey rsa3072pub.der -pkeyopt rsa_padding_mode:oaep -pkeyopt 
digest:sha256

parameter setting error

140736155067400:error:06089094:digital envelope 
routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:376:

$ ~/openssl-1.1/bin/openssl version

OpenSSL 1.1.0g-dev  xx XXX 

$ ~/openssl-1.1/bin/openssl pkeyutl -encrypt -in t1264.dat -out 
t1264.dat.enc2.oaep -keyform DER -pubin -inkey rsa3072pub.der -pkeyopt 
rsa_padding_mode:oaep

$ ~/openssl-1.1/bin/openssl pkeyutl -encrypt -in t1264.dat -out 
t1264.dat.enc2.oaep -keyform DER -pubin -inkey rsa3072pub.der -pkeyopt 
rsa_padding_mode:oaep -pkeyopt digest:sha256

pkeyutl: Can't set parameter:

140736155067328:error:06089094:digital envelope 
routines:EVP_PKEY_CTX_ctrl:invalid operation:crypto/evp/pmeth_lib.c:312:

$

 

It seems that OpenSSL tries to enforce the incorrect assumption that 
digest/hash is only applicable to signature padding, but not to encryption 
padding?

--

Regards,

Uri Blumenthal



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

[Blumenthal, Uri - 0553 - MITLL]

Fix confirmed, thank you!

Regards,
Uri

Sent from my iPhone

> On Sep 4, 2017, at 10:25, Matt Caswell <m...@openssl.org> wrote:
> 
> 
> 
>> On 04/09/17 08:59, Matt Caswell wrote:
>> 
>> 
>>> On 03/09/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote:
>>> MacOS 10.12.6, Xcode-8.3.3. Current Github master:
>>> 
>>> Test Summary Report
>>> ---
>>> ../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1
>>> Failed: 1)
>>>  Failed test:  1
>>>  Non-zero exit status: 1
>>> Files=136, Tests=1266, 461 wallclock secs ( 2.58 usr  0.48 sys + 221.36
>>> cusr 135.66 csys = 360.08 CPU)
>>> Result: FAIL
>>> make[1]: *** [_tests] Error 1
>>> make: *** [tests] Error 2
>> 
>> Fix here:
>> 
>> https://github.com/openssl/openssl/pull/4331
> 
> This is now merged, so this issue should be fixed.
> 
> 
>> 
>> 
>> Matt
>> 
>>> 
>>> Config & build script (feel free to suggest improvements, BTW):
>>> #!/bin/bash -ex
>>> 
>>> make distclean || true
>>> # For OpenSSL-1.1.1 master (development branch)
>>> ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc
>>> --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2
>>> enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3
>>> enable-tls13downgrade
>>> # For OpenSSL-1.1.0-stable
>>> #./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc
>>> enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers
>>> enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade
>>> make depend && make clean && make -j 2 all && make test && make install
>>> 
>>> 
>>>> On Sep 2, 2017, at 21:15, Blumenthal, Uri - 0553 - MITLL
>>>> <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote:
>>>> 
>>>> All my builds include "make distclean" at the start of the process.
>>>> However when I repeated that cleanup and re-run the build,
>>>> 1_1_0-stable error disappeared. A fluke?!
>>>> 
>>>> Regards,
>>>> Uri
>>>> 
>>>> Sent from my iPhone
>>>>> 
>>>>> Yes, the branch is OpenSSL_1_1_0-stable. Apparently it does not
>>>>> complain seeing these un-realizable parameters. And error is “genuine”.
>>>>> 
>>>>> 1.1 master also fails tests:
>>>>> 
>>>>> Test Summary Report
>>>>> ---
>>>>> ../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1
>>>>> Failed: 1)
>>>>>  Failed test:  1
>>>>>  Non-zero exit status: 1
>>>>> Files=136, Tests=1266, 480 wallclock secs ( 2.72 usr  0.55 sys +
>>>>> 226.57 cusr 144.10 csys = 373.94 CPU)
>>>>> Result: FAIL
>>>>> make[1]: *** [_tests] Error 1
>>>>> make: *** [tests] Error 2
>>>>> $ 
>>>>> 
>>>>> Config:
>>>>> 
>>>>> ./config --prefix=$HOME/openssl-1.1
>>>>> --openssldir=$HOME/openssl-1.1/etc --with-rand-seed=rdcpu enable-aria
>>>>> enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
>>>>> enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3
>>>>> enable-tls13downgrade
>>>>> 
>>>>> As you see, for 1.1.1 master I’m enabling ARIA and setting default
>>>>> entropy source to RDRAND. ;-)
>>>>> 
>>> 
>>> 
>>> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

I like this PR. Thank you!

> On Sep 3, 2017, at 17:53, Dr. Matthias St. Pierre 
>  wrote:
> 
>> 
>> The 'RAND_add()/RAND_bytes()' pattern is broken
>> ===
>> 
>> In OpenSSL, the classical way for the RNG consumer to add his own randomness 
>> is to call 'RAND_add()' before
>> calling 'RAND_bytes()'. If the new 'RAND_OpenSSL()' method (the 
>> "compatibility layer" hiding the public
>> RAND_DRBG instance)  is the default, then this does not work as expected 
>> anymore:
>> 
>> The reason is that a call to 'RAND_add()' adds the provided randomness only 
>> to a global buffer
>> ('rand_bytes'), from which it will be pulled during the next reseed. But no 
>> reseed is triggered. So the next
>> RAND_bytes() call will be unaffected from the RAND_add(), which is not what 
>> the consumer expected. (The same
>> holds for 'RAND_seed()', since 'drbg_seed()' only calls into 'drbg_add()')
>> 
>> Reseeding of DRBGs occurs only at the following occasions:
>> 
>> * immediately after a 'fork()' (new)
>> * if the 'reseed_counter' exceeds the 'reseed_interval'
>> * if 'RAND_DRBG_generate()' is called requesting 'prediction_resistance'
>> * 'RAND_DRBG_reseed()' is called explicitely
>> 
>> *Note:* Currently it looks like the situation is even worse: if 'RAND_add()' 
>> is called multiple times before
>> a reseed occurs, then the result of the previous call is overwritten.
> 
> 
> I just posted GitHub PR #4328 related to this issue
> 
>   [openssl/openssl] WIP: Fix the RAND_add() reseeding issue (#4328)
> 
> 
> Matthias St. Pierre
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

[Blumenthal, Uri - 0553 - MITLL]

MacOS 10.12.6, Xcode-8.3.3. Current Github master:

Test Summary Report
---
../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=136, Tests=1266, 461 wallclock secs ( 2.58 usr  0.48 sys + 221.36 cusr 
135.66 csys = 360.08 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make: *** [tests] Error 2

Config & build script (feel free to suggest improvements, BTW):
#!/bin/bash -ex

make distclean || true
# For OpenSSL-1.1.1 master (development branch)
./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
--with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 
enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 
enable-tls13downgrade
# For OpenSSL-1.1.0-stable
#./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers 
enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade
make depend && make clean && make -j 2 all && make test && make install


> On Sep 2, 2017, at 21:15, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> 
> wrote:
> 
> All my builds include "make distclean" at the start of the process. However 
> when I repeated that cleanup and re-run the build, 1_1_0-stable error 
> disappeared. A fluke?!
> 
> Regards,
> Uri
> 
> Sent from my iPhone
>> 
>> Yes, the branch is OpenSSL_1_1_0-stable. Apparently it does not complain 
>> seeing these un-realizable parameters. And error is “genuine”.
>> 
>> 1.1 master also fails tests:
>> 
>> Test Summary Report
>> ---
>> ../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1 
>> Failed: 1)
>>   Failed test:  1
>>   Non-zero exit status: 1
>> Files=136, Tests=1266, 480 wallclock secs ( 2.72 usr  0.55 sys + 226.57 cusr 
>> 144.10 csys = 373.94 CPU)
>> Result: FAIL
>> make[1]: *** [_tests] Error 1
>> make: *** [tests] Error 2
>> $ 
>> 
>> Config:
>> 
>> ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
>> --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 
>> enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 
>> enable-tls13downgrade
>> 
>> As you see, for 1.1.1 master I’m enabling ARIA and setting default entropy 
>> source to RDRAND. ;-)
>> 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

[Blumenthal, Uri - 0553 - MITLL]

All my builds include "make distclean" at the start of the process. However 
when I repeated that cleanup and re-run the build, 1_1_0-stable error 
disappeared. A fluke?!

Regards,
Uri

Sent from my iPhone

> On Sep 1, 2017, at 21:10, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> 
> wrote:
> 
> On Sep 1, 2017, at 18:48, Matt Caswell <m...@openssl.org> wrote:
>>>> *Subject:* *openssl 1-1-0-stable fails*
>>>> 
>>>> OpenSSL_1_1_0-stable current Github
>>>> 
>>>> Test Summary Report
>>>> ---
>>>> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1)
>>>>  Failed test:  4
>>>>  Non-zero exit status: 1
>>>> Files=95, Tests=561, 165 wallclock secs ( 1.13 usr  0.30 sys + 84.96
>>>> cusr 42.27 csys = 128.66 CPU)
>>>> Result: FAIL
>>>> 
>>>> Config:
>>>> 
>>>> ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc
>>>> enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
>>>> enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3
>>>> enable-tls13downgrade
>> 
>> Errrthis config line is using options only available in master
>> (enablet-tls1_3 enable-tls13downgrade). Did you give the right line?
> 
> Yes, the branch is OpenSSL_1_1_0-stable. Apparently it does not complain 
> seeing these un-realizable parameters. And error is “genuine”.
> 
> 1.1 master also fails tests:
> 
> Test Summary Report
> ---
> ../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1 Failed: 
> 1)
>   Failed test:  1
>   Non-zero exit status: 1
> Files=136, Tests=1266, 480 wallclock secs ( 2.72 usr  0.55 sys + 226.57 cusr 
> 144.10 csys = 373.94 CPU)
> Result: FAIL
> make[1]: *** [_tests] Error 1
> make: *** [tests] Error 2
> $ 
> 
> Config:
> 
> ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
> --with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 
> enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 
> enable-tls13downgrade
> 
> As you see, for 1.1.1 master I’m enabling ARIA and setting default entropy 
> source to RDRAND. ;-)
> 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

[Blumenthal, Uri - 0553 - MITLL]

On Sep 1, 2017, at 18:48, Matt Caswell  wrote:
>>> *Subject:* *openssl 1-1-0-stable fails*
>>> 
>>> OpenSSL_1_1_0-stable current Github
>>> 
>>> Test Summary Report
>>> ---
>>> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1)
>>>  Failed test:  4
>>>  Non-zero exit status: 1
>>> Files=95, Tests=561, 165 wallclock secs ( 1.13 usr  0.30 sys + 84.96
>>> cusr 42.27 csys = 128.66 CPU)
>>> Result: FAIL
>>> 
>>> Config:
>>> 
>>> ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc
>>> enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5
>>> enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3
>>> enable-tls13downgrade
> 
> Errrthis config line is using options only available in master
> (enablet-tls1_3 enable-tls13downgrade). Did you give the right line?

Yes, the branch is OpenSSL_1_1_0-stable. Apparently it does not complain seeing 
these un-realizable parameters. And error is “genuine”.

1.1 master also fails tests:

Test Summary Report
---
../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=136, Tests=1266, 480 wallclock secs ( 2.72 usr  0.55 sys + 226.57 cusr 
144.10 csys = 373.94 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
make: *** [tests] Error 2
$ 

Config:

./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
--with-rand-seed=rdcpu enable-aria enable-ec_nistp_64_gcc_128 enable-md2 
enable-rc5 enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 
enable-tls13downgrade

As you see, for 1.1.1 master I’m enabling ARIA and setting default entropy 
source to RDRAND. ;-)

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Fwd: openssl 1-1-0-stable fails

[Blumenthal, Uri - 0553 - MITLL]

Begin forwarded 

> Subject: openssl 1-1-0-stable fails
> 
> OpenSSL_1_1_0-stable current Github
> 
> Test Summary Report
> ---
> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1)
>   Failed test:  4
>   Non-zero exit status: 1
> Files=95, Tests=561, 165 wallclock secs ( 1.13 usr  0.30 sys + 84.96 cusr 
> 42.27 csys = 128.66 CPU)
> Result: FAIL
> 
> Config:
> 
> ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
> enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 enable-weak-ssl-ciphers 
> enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade
> --
> Uri Blumenthal
> u...@mit.edu
> 


smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

>> I would do exactly the opposite. “Normal” entropy is fetched from the 
default sources (/dev/urandom). But
>> when a sensitive (aka long-term) keys are generated, a (portable :) 
hardware RNG is plugged in and used with
>> RAND_add() equivalent. Reason – in my setup reliable trusted hardware 
RNG is not always on. If it were, I’d
>> use it as the main entropy source and be done with it.
>
>In general, I would agree with you. In our case, it was a requirement 
of the
>   government to trust only the SmartCard RNG. Since we use it for VPN
>   connections with SmartCard authentication this was no problem, because
>   the SmartCard must be present in order to initiate the IKEv2 exchange. 

Ah, that makes a lot of difference. 

>  The only tricky part was to deal with temporary failures of the entropy 
> source.

Did you experience that often? How did you deal with it?



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

On 8/30/17, 00:59, "openssl-dev on behalf of Paul Dale" 
 wrote:

>My thoughts are that the new RNG API should be made public once it has
>been properly designed.  We've a chance to get this right, let's take the 
> time
>and make an effort to do so.  There is no rush.

Not quite. If there is an RNG involved in generating long-term keys now – users 
better be able to control/affect it now.

>   I also feel that having an engine interface to the new RNG API is 
> worthwhile.

+1

>   It allows hardware sources to be used via the same API.

I rather doubt this. For example, my smartcard (accessible via PKCS#11) is a 
hardware source, which I occasionally use. How do you see it used with the same 
API?

>I would like to see an entropy argument to the equivalent to RAND_add.
>   Anyone is welcome to always pass zero in but there should be the option to 
> not. 
>   Consider an hardware source with _provable_ output quality, why shouldn't 
> it be
>   allowed to meaningfully contribute?

What’s the purpose of passing the entropy argument? How is the callee (the RNG) 
going to use it? Why should the OpenSSL code in general trust the received 
value (how can OpenSSL tell that the received randomness is indeed from a 
hardware source with provable output quality)? Finally, what does it matter? 

And they all “meaningfully contribute”. The only question is whether this 
contribution should prevent RNG from acquiring more entropy from other sources. 
My opinion is resounding no.

>   I like the idea of two independent global RNGs.

+1  ;-)

>  This does increase seeding requirements however.

If you can seed one, you can seed two.



-Original Message-
From: Dr. Matthias St. Pierre [mailto:matthias.st.pie...@ncp-e.com] 
Sent: Tuesday, 29 August 2017 7:45 PM
To: openssl-dev@openssl.org
Subject: [openssl-dev] Plea for a new public OpenSSL RNG API

Hi everybody,

on the [openssl-dev] mailing list, there has been a long ongoing discussion 
about the new RAND_DRBG API and comparing it with the old RAND_METHOD API (see 
"[openssl-dev] Work on a new RNG for OpenSSL"). Two of the most controversal 
questions were:

 - Do we really need a new RNG API? Should the RAND_DRBG API be made public 
or kept private? (Currently, it's exported from libcrypto but only used 
internally by libssl.)
 - How much control should the user (programmer) be given over the 
reseeding process and/or should he be allowed to add his own additional 
randomness?

Many developers seem to be realizing the interesting possibilities of the 
DRBG API and are asking for public access to this new and promising API. One of 
the driving forces behind it is the question about how to do seeding and 
reseeding right. Among others, Uri Blumenthal asked for making the DRBG API 
public.

Currently, the OpenSSL core members seem to be reluctant to make the API 
public, at least at this early stage. I understand Rich Salz's viewpoint that 
this requires a thorough discussion, because a public interface can't be easily 
changed and wrong decisions in the early phase can become a heavy burdon.

Nevertheless, I agree with Uri Blumenthal that the DRBG API should be made 
public. So here comes my

==
Plea for a new public OpenSSL RNG API:
==

The new RAND_DRBG is the superior API. It shouldn't be kept private and 
hidden behind the ancient RAND_METHOD API.
The philosophy of the two APIs is not very well compatible, in 
particular when it comes to reseeding and adding
additional unpredictable input. Hiding the RAND_DRBG behind the 
RAND_METHOD API only causes problems.
Also, it will force people to patch their OpenSSL copy if they want to 
use the superior API.

The RAND_DRBG API should become the new public OpenSSL RNG API and the 
old RAND_METHOD API should be deprecated
in the long run. This transition does not need to be rushed, but it 
would be good if there would be early consent
on the road map. I am thinking of a smooth transition with a phase of 
coexistence and a compatibility layer
mapping the default RAND_METHOD to the default public RAND_DRBG 
instance. (This compatibility layer already exists,
it's the 'RAND_OpenSSL()' method.)



Historical Background
=

As Rich already mentioned in his blog post, the RAND_DRBG isn't new. It's 
been a part of OpenSSL for a long time, hidden in the FIPS 2.0 Object Module.

I have been working with the FIPS DRBG for quite a while now, using a 
FIPS-capable OpenSSL 1.0.2x crypto library. The reason why our company switched 
to the FIPS DRBG is that one of our products runs on a small hardware device 
which does not have a reliable 

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

[Blumenthal, Uri - 0553 - MITLL]

>> I *don’t want* OpenSSL to make *any* estimation of the amount of provided 
>> entropy. All I want it to do is to mix these bits into the RNG state. It’s 
>> *my* business how much entropy I’m providing – but I don’t want OpenSSL to 
>> make any decision regarding pull from other entropy sources based on my 
>> input.
>> 
>> Does it sound reasonable? (He, it does to me ;)
> 
> But that is not the API that RAND_add() provides.

Yes, I realize that, sort of. But nonetheless, that’s the interface/behavior 
that I think an RNG should offer.

> It's a push not
> a pull API. With the DRBG you can do this, assuming using it's an
> extraction / derivative function.

Not sure I understand. But “…you can do this…” sounds encouraging. ;-)

> One of the suggestions I did before is to have RAND_poll_ex() take
> a parameter about how much randomness is needed, but I think it's
> also a wrong API and I'm thinking about removing it.

There are two aspects:

The RNG itself keeping track of how much entropy it has in its pool/state, and 
thus when to pull its (standard) entropy sources for more (and specifically for 
how much more). I don’t want to interfere with this part.
The user-visible/accessible interface to RNG that allows:
Forcing the “reseed”, making the RNG to to its sources for “fresh” entropy 
regardless of what’s up with its internal state;
Telling the RNG to immediately mix the given bits into its state, without 
adjusting its count of available/present entropy.



>> If I had my way, you’d assume that every bit contains 0 bits of entropy, but 
>> mix it in regardless because that’s what the user is asking you to do.
> 
> Which is why I suggested we use this for the additional data.

Yes, precisely. That’s exactly what I plan to use this interface for - mixing 
in additional data. NIST 800-90A Rev1 has “additional input” only as part of 
Reseed() or Generate(). I can live with that (i.e., with the fact that right 
before my randomness is mixed in, the entire state s replaced). Though ideally 
we’d have “RAND_add_ex()” or such that does not require replacing the entire 
state with fresh data from entropy source (because if that capability is 
needed, it is easy to emulate by issuing two calls: “Reseed(); Add_ex();"


> But
> I think that as long as we have both APIs we might actually need
> it for the entropy input. If there is no other way to add
> randomness, RAND_add() is our current documented way to add it,
> and it will need to keep working.

It’s perfectly OK for me if RAND_add() keeps working. What I’d like to change 
about it is exactly when the mixing occurs. I’d like the state updated 
immediately upon RAND_add(), not when the RNG in question decides that it needs 
to replenish its entropy supply. I think this change would only improve 
security of applications that use it.

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

[Blumenthal, Uri - 0553 - MITLL]

> If, based on its value, OpenSSL may decide that it now got “enough” entropy 
> and doesn’t need to
> pull more from other sources before serving randomness to requestors – then 
> it is harmful.
> “Over-confidence” in this value by the caller can negatively impact the 
> quality of the produced
> random numbers.

As long as you have sources that don't provide 1 bit of randomness
per bit that you provide you need to have an estimate of how much
randomness it really contains. And you should probably seriously
underestimate it so that you're sure that you collect enough.

So let me underestimate it to 0. ;-)  
  
The problem with ignoring an existing parameter is that people
could be calling it with for instance the value of 0, knowing it
contains as good as none entropy. Or they could feed the unwithened
output of an TRNG in that with an estimate of randomness it provides.
And OpenSSL used to do the right thing with that.

I *don’t want* OpenSSL to make *any* estimation of the amount of provided 
entropy. All I want it to do is to mix these bits into the RNG state. It’s *my* 
business how much entropy I’m providing – but I don’t want OpenSSL to make any 
decision regarding pull from other entropy sources based on my input.

Does it sound reasonable? (He, it does to me ;)

But now we just ignore it and assume every bit with get contains 1
bit of randomness and we're sundenly seriously overestimating the
amount of randomness we're getting.

If I had my way, you’d assume that every bit contains 0 bits of entropy, but 
mix it in regardless because that’s what the user is asking you to do.


This is a documented public API, you can't just go and ignore this 
parameter.

:-)



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

On 8/29/17, 15:22, "openssl-dev on behalf of Salz, Rich via openssl-dev" 
 wrote:
➢ I’d like to suggest that any approach other than “immediately mix the 
received randomness into the RNG state” is bad. If a user does RAND_add() now, 
as opposed to 100 source code lines before, there may be a reason for that.

>I think the only way to do that in the DRBG model is to treat it as 
> “additional input” and
>do a generate call.  I think that would achieve the same effect, but it 
> wouldn’t delay any
>possible seeding of randomness that the DRBG itself needs at some point.
   
That is OK if the application manually invokes generate(). If it’s the RNG 
responsible for feeding key generators (who would call generate() transparently 
to user), then the only way I see is DRBG reseed(). Even though it implies a 
complete state replacement.

AFAIK, there are three cases when randomness source(s) is pulled:

a. At the instantiation time (page 29 of NIST SP 800-90A Rev1 draft).
b. Upon reseed call (pages 30-31).
c. During generation call(pages 32-36).

“Additional input” (i.e., what I’m after :) is present in two of the above: 
reseeding, and generation (pages 19 and 23).

The draft is very clear that this “additional input” shall not be counted 
towards the “official” entropy (aka calculations when to pull the “official” 
entropy sources). Which suits my purposes just fine. ;-)

I realize that reseed() not only mixes my “additional input” but also replaces 
the entire state. NIST does not specify interface to “just” mix the “additional 
input” into the state without replacing the whole state with some fresh entropy 
by calling Get_entropy_input(). Maybe we can provide such a function call 
(that’s what I think RAND_add() is supposed to do), but I’m not certain here… 

Wonder what others think? Do you believe that if you want to mix some more 
randomness into the RNG state to improve upon less-than-perfect entropy 
sources, you must also replace the entire state with the fresh pull from those 
sources? Or is it OK to just “spice” the current state with “additional input”?

Note that regardless of the answer to the above, IMHO reseed() should be able 
to take “additional input”. (NIST considers it optional, but sensitive/critical 
applications don’t. ;)

➢One “API” is how to get a reference/pointer/instance/whatever to the 
DRBG object responsible for the operation I’m now concerned with,
➢  and that I want to influence/improve. This would probably differ between 
per-SSL DRBG and per-thread DRBG, etc. I haven’t even
➢  thought about this part of the API (and I’m sure others on the team have 
more experience and understanding of the OpenSSL code
➢  to do it better than I would anyway).

 > Yes, it is separate.  But I want to make sure that if we are doing a 
 > comprehensive RAND overhaul that this is included in the requirements.

Yes, it should be included. But don’t let it stop us from defining/reviewing 
the “clearer” part of the API.  ;-)


smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

On 8/29/17, 11:33, "openssl-dev on behalf of Salz, Rich via openssl-dev" 
 wrote:

Could you please be more specific wrt. DRBG organization that in your 
opinion could impact the UI? 

 >   From your use-case:  you want to add entropy into a specific DRBG. 

Yes.

  >  You want to push it, as opposed to the DRBG “pull when needed” model.  

I’d like to suggest that any approach other than “immediately mix the received 
randomness into the RNG state” is bad. If a user does RAND_add() now, as 
opposed to 100 source code lines before, there may be a reason for that.

Would you agree? Besides possible but probably negligible performance 
difference – why would you ever want to delay mixing the received “additional 
input” in?

  >  That’s an additional API.  

I wouldn’t call it “additional”. It may be a change from the current behavior – 
but I think everybody would welcome such a change. IMHO it can only help, never 
hurt.

   >  Also from your use-case: you want to specify which DRBG instance gets 
that entropy. 

Yeah, but that probably isn’t a part of the API that DRBG “object” exposes. 

One “API” is how to get a reference/pointer/instance/whatever to the DRBG 
object responsible for the operation I’m now concerned with, and that I want to 
influence/improve. This would probably differ between per-SSL DRBG and 
per-thread DRBG, etc. I haven’t even thought about this part of the API (and 
I’m sure others on the team have more experience and understanding of the 
OpenSSL code to do it better than I would anyway).

Another “API” is how to tell this specific DRBG instance what exactly I want 
from it now. E.g., mix more randomness that I provide into its state, give me 
some random bits, whatever. This part probably can stay close to what it 
currently is. I think 90A would be satisfied with 3-4 interface calls here…

   >   If we move to a pair per thread, as opposed to one per SSL and two in 
the global space, how do we make sure that API still works and does the right 
thing.

Yeah. That’s the “other” part of the API. I think the two API “groups” are 
pretty (completely?) orthogonal – independent from each other.

   >Does that makes sense, and does it answer your question?

 Yeah… What do you think of my reasoning above?



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

IMHO this interface is a way for the user to improve the quality of the 
randomness it would get from the given RNG, *not* to replace (or diminish) its 
other sources. My proposal is to abolish this parameter, especially since now 
it is simply ignored (and IMHO – for a good reason).

That's a fine proposal ... it just can't be implemented until a major release 
boundary, when our ABI stability policy permits such breaking changes.


And that is fine. The sooner the better, but ABI stability makes sense too. 

 

My main point is:  RAND_add() and whatever similar in purpose interface calls 
we may define in the future should exhibit the following behavior:

 
Mix the provided randomness into the RNG state *immediately*, and
Keep pulling other sources and mixing them into the state – don’t subtract from 
the “needed entropy” count the amount you presumably got from the user.


Frankly, the need to provide double entropy argument doesn’t bother me all that 
much – especially if the value 0 is accepted there. ;-)



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

uri> Could you please be more specific wrt. DRBG organization that in your 
opinion could impact the UI? 

Are you talking about the UI API or something else?

No-no-no, just the UI API. 

I used the term “UI” to emphasize that this is the “public” part of the API, 
exposed to the user, expected to be called by the user, and (probably) designed 
to be stable for some (hopefully considerable) time.



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev" 
 wrote:

➢ An other problem with the current implemenation is that the
➢ randomness parameter that's now given to RAND_add() is just
➢ ignored, it assumes it's the same as the length.

For what it’s worth, this was done deliberately, make RAND_add and 
RAND_seed equivalent.

I am skeptical of the ability to get that estimate correct.

Someone on GH there is a conversation thread about turning that into a 
percentage, which seems like the best thing to do for any new API.


 What’s the point of having this potentially harmful parameter? If it weren’t 
ignored – how would OpenSSL use it?

If, based on its value, OpenSSL may decide that it now got “enough” entropy and 
doesn’t need to pull more from other sources before serving randomness to 
requestors – then it is harmful. “Over-confidence” in this value by the caller 
can negatively impact the quality of the produced random numbers.

If this value is not used to guide OpenSSL when to stop pulling entropy sources 
and start serving randomness – then it causes no harm, but what’s its purpose?

IMHO this interface is a way for the user to improve the quality of the 
randomness it would get from the given RNG, *not* to replace (or diminish) its 
other sources. My proposal is to abolish this parameter, especially since now 
it is simply ignored (and IMHO – for a good reason).




smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

Could you please be more specific wrt. DRBG organization that in your opinion 
could impact the UI? 

NIST 90Ar1 seems specific enough on what functionality DRBG can provide to 
users, and it doesn't seem like a very elaborate or rich interface. Why would 
it change, regardless of what you may need to do with it internally?

Regards,
Uri

Sent from my iPhone

> On Aug 29, 2017, at 10:03, Salz, Rich via openssl-dev 
>  wrote:
> 
> 
>dev asap. If there are problems with it we can always revert it before
>it makes it into a release.
> 
> Someone on the OMC called that “flip-flopping” and seemed to be against this 
> kind of thing.
> 
> If we are going to have an additional API, then we should at least see a 
> draft of the header file first.
> 
> Keep in mind that the current DRBG organization might change, and we don’t 
> want to lose that freedom.
> 
> 
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>> Even opaque objects usually have some public interface. I think exposing 
>> RAND_add_ex()
>> would be a good idea for 1.1..1, and it’s likely to serve as an acceptable 
>> “live forever” API.
>
>  That’s my point.  API decisions live forever. 

Point well taken. Nonetheless…

> Suppose we move around the DRBG’s so that they are per-thread, or
> per-SSL_CTX or per-SSL object?  Will that API still work?  Or will we
> need a A “RAND_ex_ex” function? 

The *API* probably still would work. The *implementation* of it (which is 
supposed to stay under the hood) may need to change.

Offhand, I don’t see why the user-level API call would have to be different 
depending on whether the relevant DRBG is thread-local, or SSL-object-local. 
The only difficulty would be if you want to have *both*…

But my point is – this (“reseeding assistant”) is a needed capability. So it 
should be available to the users rather sooner than later…

> We don’t have even consensus on when and how to reseed.

Luckily, for the interface(s) I’m asking for it’s simple – reseed upon explicit 
request. ;-)
I understand the concerns for the reseeding in general.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>>I personally see no harm if these RNG objects are made available to 
>> applications that need/use them
>
> But decisions like this live forever.   It is therefore VERY important to 
> spend time thinking about what
> becomes part of the public API and what remains hidden so that we can change 
> things later when we
> have a better understanding.
 
No argument here, especially since I can’t claim to understand all the 
implications of exposing RNG (yet ;).
But it is clear that at least some applications need to work with an RNG more 
closely than others, and would want more control over its behavior. 

>   This concept is new to OpenSSL :)

:-) :-)

> But we just put out a 1.1.0 release that made things opaque, so it’s more 
> fresh in the minds of at
> least some of the dev team.

In general, making things opaque is a good idea, RNG included. But:

> Personally, since DRBG is new in 1.1.1 I would be quite happy if we didn’t 
> expose anything public
> until the release after that.

Even opaque objects usually have some public interface. I think exposing 
RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an 
acceptable “live forever” API.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

On 8/24/17, 09:45, "openssl-dev on behalf of Steffen Nurpmeso" 
 wrote:
 >> …  But I think a new API, 
 >> RAND_add_ex() that took a flag 
 >> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE,
 >> RAND_LOCAL_PRIVATE indicating which to seed.   
 >
 > If you say it and continue like that then let me wonder why the
>  objects as such cannot be accessed like
>
> RAND_object_get(SPECIAL_CONSTANT_OR_NULL), or
> RAND_object_create(SPECIAL_CONSTANT_OR_NULL), plus
> RAND_object_bytes() and RAND_object_add().  And all the current
> could be macros or inline functions to the corresponding new
> object based functions.

My take and motivation is this:

- OpenSSL is designed to run on all kinds of architectures, CPU, and OS. Some 
have better entropy sources then others.
- The current blog essentially says that regardless of how many RNGs you 
defined – if the first one provides “enough” entropy, other RNGs won’t be asked 
to contribute. Some applications may not want to rely on one RNG for tasks they 
consider critical.
- Applications that need better entropy guarantees may want to contribute to 
the entropy pool by mixing in entropy from sources other than the default RNG. 
- NIST SP 800-90A Rev 1 understood this need and defined interface “Additional 
input” that can be applied to both reseeding and generation. Since not every 
application has such need, NIST made this interface optional. 
- OpenSSL is not developed with one specific application in mind, therefore it 
make sense to implement and provide that optional interface, allowing so 
applications to mix in randomness from whatever other sources they trust and 
have available.

I personally see no harm if these RNG objects are made available to 
applications that need/use them. But my first priority is being able to add to 
the RNG entropy pool more randomness from a source I trust.

 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>So I guess you want an interface that can both add things to the
>   "entropy" pool, and to the "additional data" pool? It shouldn't
>be that hard, I'll try to come up with some proposal soon.
  
I’d say the interface that  Rich Salz proposed would be good enough:

> …  But I think a new API, RAND_add_ex() that took a flag that had values like
> RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE,
> RAND_LOCAL_PRIVATE indicating which to seed. Thoughts?

It exposes what’s necessary, but nothing more. Another benefit – malicious 
input would not compromise the entropy pool.

> We should think carefully about what API’s we are exposing, and might want to 
> wait for 1.1.2

Nothing wrong with thinking about what API to expose, and how. Since 1.1.1 is 
what’s currently being shaped – there’s no reason to postpone that thinking. 
Especially since the RNG/DRBG work is being done on 1.1.1 now, and this is a 
part of it.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

Forgot to add that the adversary would have to compromise not only Intel but 
also AMD CPUs. Not sure about ARM - but if it implements RDRAND then it must be 
compromised too, otherwise the enemy victory wouldn be incomplete. ;-)
And think of the chips powering mobile devices...

Regards,
Uri

Sent from my iPhone

> On Aug 21, 2017, at 20:06, Paul Dale  wrote:
> 
> Uri wrote:
>>>   It might also use things like RDRAND / RDSEED which we don't trust.
>> ...
>> From cryptography point of view, it cannot hurt, but may help a lot
> 
> There is a scenario where it does hurt: 
> https://www.lvh.io/posts/2013/10/thoughts-on-rdrand-in-linux.html
> 
> This attack wouldn't be difficult to implement given all the out of order 
> execution and look ahead that CPUs do.   It requires a compromised RDRAND 
> instruction changing the behaviour of a subsequent XOR into a copy.  Not only 
> would it not be producing random bits but it would remove any randomness from 
> the bits you already have.
> 
> 
> Pauli
> -- 
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

My offhand knee-jerk reaction would be that if you have a CPU compromised to 
that extent - the battle has been lost with no reason to continue.

Going into more details, I checked that post, and disagree with the author (and 
I'm in a good company, as Linus seems to hold the same opinion). According to 
the author (as I understood him), not only RDRAND must be compromised (i.e., 
produce bad output), but the CPU would have to switch to a "special" processing 
mode when RDRAND instruction is detected. And this malicious CPU would have to 
understand how RNG is implemented in Linux, Mac, Windows, FreeBSD (at what 
point it calls RDRAND and what instructions follow)... And it's betting on 
RDRAND being the last in the chain of RNG inputs (otherwise it would wipe out 
previous entropy, but would in turn be replaced by something good from the next 
source). Also, usually mixing = XOR, but some prefer arithmetic addition - so 
RDRAND would be crafted to replace any subsequent operation to copy. Plus, it 
would have to track a bunch of the following instructions because it's common 
but not certain that the RDRAND output is mixed in immediately (in the very 
next instruction)...

To summarize, I don't have enough tin-foil for a hat of that size.

But regardless, a good solution IMHO is to offer an interface to mix in (add to 
the pool) whatever data the user wants as an additional input (in terms of SP 
800-90A that defined "additional input" to mix during reseeding and 
generation). That data could be an output of RDRAND, of an external RNG 
(including hardware TRNG), or... It would be up to the user to pick the 
additional source that he trusts. Also, nobody forces the user to employ that 
interface at all (just like on a decent OS nobody now is forced to use 
RAND_add()) - but it would be there for those who need/want it. 

Regards,
Uri

Sent from my iPhone

> On Aug 21, 2017, at 20:06, Paul Dale  wrote:
> 
> Uri wrote:
>>>  It might also use things like RDRAND / RDSEED which we don't trust.
>> ...
>> From cryptography point of view, it cannot hurt, but may help a lot
> 
> There is a scenario where it does hurt: 
> https://www.lvh.io/posts/2013/10/thoughts-on-rdrand-in-linux.html
> 
> This attack wouldn't be difficult to implement given all the out of order 
> execution and look ahead that CPUs do.   It requires a compromised RDRAND 
> instruction changing the behaviour of a subsequent XOR into a copy.  Not only 
> would it not be producing random bits but it would remove any randomness from 
> the bits you already have.
> 
> 
> Pauli
> -- 
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> Phone +61 7 3031 7217
> Oracle Australia
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>I at least have a plan to add additional data, but probably not in
>the current idea was probably not the way you would like to see it.

:-)  

>My idea was to query at least various sources that we don't
>attribute any entropy to, like getpid(), gettimeofday(),
>clock_gettime(), the TSC, ...

>From my point of view – adding these doesn’t add a whole lot, but it doesn’t 
>hurt. IMHO – add away. ;-)

>It might also use things like RDRAND / RDSEED which we don't trust.

Some don’t trust these, some think that they would add a good amount of 
entropy. I for one would certainly like to see the output of these mixed in. 
>From cryptography point of view, it cannot hurt, but may help a lot. Consider 
it as a lottery ticket you don’t have to pay for. ;-)

>So I guess you want an interface that can both add things to the
>"entropy" pool, and to the "additional data" pool?

That is correct. Especially because some of us have “real” nice/fancy hardware 
RNG (TRNG) available, and some like to mix in the output from RNGs on hardware 
tokens - maybe not as impressive as a “real” fancy TRNG, but as they say, every 
bit helps – in this case literally.

> It shouldn't be that hard, I'll try to come up with some proposal soon.

Thank you!!


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>> P.S. I wonder if it's feasible to have a configuration parameter that would 
>> allow me to tell the TLS code to invoke RAND_add_ex() before generating 
>> session keys?
>
> Either you accept that NIST SP 90A is right, or you just bypass it 
> completely.  We’re in the first camp.  

You mean NIST SP 800-90A, released Jan 2012 and withdrawn Jun 2015? With Rev 1 
*draft* currently available (released Jun 2015)?  ;-)

I’m glad you agree that “it is right”, because in our argument it supports my 
side over yours. Let’s go through the 90A Rev 1 draft 
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf:

Page 11 Section 7 provides a functional model of a DRBG (Figure 1), clearly 
showing “additional input” for both the Reseed Function and the Generate 
Function.  The text says “… and may include additional optional sources, 
including … additional input.”

Page 12 Sec 7.2: “Additional input may also be provided during reseeding and 
when pseudorandom bits are requested.”

Page 22 Sec 8.7.2: “Additional input may optionally be provided to the reseed 
and generate functions during requests. The additional input may be obtained 
from inside or outside a cryptographic module, and may include secret or public 
information. ... Additional input is optional for both the DRBG and the 
consuming application, and the ability to enter additional input may or may not 
be included in an implementation.”

Same place: “The use of additional input may be a means of providing more 
entropy for the DRBG internal state that will increase assurance that the 
entropy requirements are met. If the additional input is kept secret and has 
sufficient entropy, the input can provide more assurance when recovering from 
the compromise of the entropy input, the seed or one or more DRBG internal 
states.”

The last quote explains exactly why people (myself included) may want that 
interface. The draft does not *mandate* making this interface available, but 
blesses it nonetheless. I’m one of those who falls into the category of “need 
to increase assurance that the entropy requirements are met”.

In other words, the standard clearly does allow the implementer to *include* 
additional input. The standard also allows the implementer to “weasel out” of 
it, but I cannot imagine why a security-cautious implementer would want to. 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

Offhand, I'd say it's a perfect solution. It allows me to mix in additional 
randomness when I want to the RNG that I think may need it. Exactly what I 
need. 

Thanks! 

P.S. I wonder if it's feasible to have a configuration parameter that would 
allow me to tell the TLS code to invoke RAND_add_ex() before generating session 
keys?

Regards,
Uri

Sent from my iPhone

> On Aug 18, 2017, at 19:42, Salz, Rich via openssl-dev 
>  wrote:
> 
> ➢ But I’d like the development team to comment on (and ideally – accept) my 
> request to add RAND_add() method to the RNG that is used in generation of 
> private keys.
> 
> Well, I’ve been thinking about this for a bit, since you first raised it.  I 
> am still not sure of the need.  And as the blog post says, we’re not 
> convinced that the current DRBG arrangement is something that will never 
> change.  But I think a new API, RAND_add_ex that took a flag that had values 
> like RAND_ADD_GLOBAL, RAND_ADD_LOCAL, RAND_ADD_PRIVATE, RAND_LOCAL_PRIVATE 
> indicating which to seed. Thoughts?
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

All the items discussed are important.

But I’d like the development team to comment on (and ideally – accept) my 
request to add RAND_add() method to the RNG that is used in generation of 
private keys.
Reason/justification: to be able to improve the available randomness by mixing 
in output from hardware-based TRNG(s).
--
Regards,
Uri Blumenthal



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

I have only one issue with the current design: the apparent absence of 
RAND_add() interface for the "private" RNG.

I request that it is added (no pun intended, really :).

Regards,
Uri

Sent from my iPhone

> On Aug 17, 2017, at 09:18, Salz, Rich via openssl-dev 
>  wrote:
> 
> \
>> somewhere someone is.  And then it’s not about just reseeding, but
>> what about when (if) we add other things, like whether or not the
>> secure arena gets zero’d in a child?
> 
>It's difficult to think of what circumstances this might break existing
>code? What scenario did you have in mind?
> 
> As excerpted above in my post.
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

   >>> Modify the source :)
>>   
>>Very bad answer. 
   >
   >And also a wrong one.  Your application can always call RAND_add().  
Sorry for mistake.
 
And this is a very good answer. Perhaps this guidance deserves being documented 
somewhere besides this mailing list? Something along the lines of 

“RNG Seed Sources can be set by --with-rand-seed. “os” is the default source. 
Sources are tried until enough bits of randomness have been collected. If you 
want to mix data from a particular source into the seed, but don’t want to make 
that source exclusive – use RAND_add() method.”
   
 > This is a mostly volunteer open source project. 

Yeah, I realize and appreciate that.

> We are unlikely to commit to something that requires so much effort

I’m not sure I agree here. What effort are you talking about? In order to 
select an order in which available sources are queried, the developers had to 
think (hopefully :). Those thought could be documented in a few lines of text. 

> when, frankly, most of the consumers aren’t interested, or qualified, to make 
> an assessment.

So they’ll be happy with the default. Fine with me. ;-)

>  I am sorry if that sounds obnoxious or conceited.  It shouldn’t; there are 
> many things that I know I’m not qualified to comment on :)  And also, we 
> reserve the right to make changes.

No offense taken. But you “freeze” interface to and behavior of ciphers and 
cipher modes, for example. This (how you seed RNG that provides keys to those) 
is at least equally important. It’s not a minute detail that nobody should care 
about or nose in.

So while the team clearly has the right to make changes (especially before the 
interface became public ;), but I’d rather that such changes  are guided by an 
informed consent from the public (such as yours truly ;). 

 >   I expect that the FIPS project, just starting, will be of interest to you. 
   
Thank you – indeed it is of  interest. (Though I see FIPS more as a curse than 
as a blessing ;-).
 
One important thing I missed earlier:

>  We also added a separate global DRBG for private key generation and added 
> API’s to use it.
> This object isn’t reachable directly, but it is used by the new BN_priv_rand 
> and BN_priv_rand_range API’s.
> Those API’s, in turn, are used by all private-key generating functions.

I think it is *imperative* for a user to be able to RAND_add() to the DRBG that 
gnerates private keys. I cannot emphasize enough how critical this is.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

>> 1. What’s the default if “with-rand-seed” was not provided? All of the 
>> listed supported types? None of them? Some of them…?
>  
>   As the first bullet says, it’s “os”.   

OK, thanks.

> As for the second part of your question, it is deliberately not answered.   
> If you care, you’ll have to read the source.  (It’s clean and easy to do so, 
> now.)  We’re not documenting everything.

I think it’s a bad approach to not document this important behavior. It has to 
be security-analyzed, then frozen & published.

>>2. What is the order in which the seed sources are tried (both when 
>>“with-random-seed” was and was not given)? 
>
> Read the source.

Likewise. It has to be published, and the developers need to figure out the 
right way here and commit to it (no pun intended).

>> 3. What should I do if I want a given source to be used in addition to the 
>> other sources, regardless of whether openssl thinks it got “enough bits” of 
>> randomness or not?
>
> Modify the source :)

Very bad answer. 

When randomness is involved, adding more of diverse sources can only improve 
the outcome. Therefore there must be a way to tell OpenSSL to *not* stop when 
it got what it believe to be “enough” but mix in more from other sources. And 
that mechanism must *not* be an individual hack – but a standard reviewed 
maintained access method.

> For a few reasons, we’re deliberately not documenting all the details.  
> Interested parties will have to read the source.

I have no problem reading the source code. I do have a problem with (a) 
important decisions like this not “formalized” and documented, and (b) 
mechanisms to tune the RNG seeding not provided and clearly and comprehensively 
documented.

I urge the developers to reconsider.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

Thanks everyone for the discussion (mainly in June) about this.  There’s a blog 
post describing what we’ve done for the 1.1.1 release: 
https://www.openssl.org/blog/blog/2017/08/12/random/

 

Nice. But some important things could be made clearer.

 

We added a new configuration parameter, --with-rand-seed, which takes a 
comma-separated list of values for seed sources. Each method is tried in turn, 
stopping when enough bits of randomness have been collected.

 
What’s the default if “with-rand-seed” was not provided? All of the listed 
supported types? None of them? Some of them…?
What is the order in which the seed sources are tried (both when 
“with-random-seed” was and was not given)? 
What should I do if I want a given source to be used in addition to the other 
sources, regardless of whether openssl thinks it got “enough bits” of 
randomness or not?



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Current master fails to build

[Blumenthal, Uri - 0553 - MITLL]

On Aug 3, 2017, at 15:46, Salz, Rich via openssl-dev  
wrote:
> 
>> After that is fixed, test 80-test_new_ssl.t fails (wstat 256, 0x100).
> 
> Do you have core file?  The failure is not repeatable, at least on my system 
> :(

Alas, I don’t. 

But Travis CI fails this master 4 out of 14 jobs, see this for example: 
https://travis-ci.org/mouse07410/openssl/jobs/260690849 



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Current master fails to build

[Blumenthal, Uri - 0553 - MITLL]

See https://github.com/openssl/openssl/issues/4080 


 First, ssl/s3_lib.c file 
misses “#include ” in the beginning. This prevents 
successful linking of libssl.

After that is fixed, test 80-test_new_ssl.t fails (wstat 256, 0x100).
—
Regards,
Uri



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

[Blumenthal, Uri - 0553 - MITLL]

Instead of "make clean" try "make distclean", then reconfigure and rebuild 
(don't forget "make depend").

Regards,
Uri

Sent from my iPhone

> On Jul 27, 2017, at 23:24, Matthew Stickney  wrote:
> 
>> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte  wrote:
>> Have you tried a 'make clean' and then rebuild?
> 
> Yep, and building from the 1.1.0 stable branch (failed with different
> errors), and from a new master.
> 
>> On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk  wrote:
>> Can you paste the actual linker invocation that is failing?
> 
> I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work
> quite correctly under MSYS2, so I have a build log, and errors,
> separately. This looks like the relevant part of the build log:
> make -f ./Makefile.shared -e \
>ECHO=echo \
>PLATFORM=mingw64 \
>PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \
>INSTALLTOP='/usr/local' LIBDIR='lib' \
>LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \
>LIBNAME=crypto SHLIBVERSION=1.1 \
>STLIBNAME=libcrypto.a \
>SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \
>CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN
> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
> -D_WINDLL' \
>LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \
>RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \
>link_shlib.mingw-shared
> make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
> --target=pe-x86-64 -o rc.o
> LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
> -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN
> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
> -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic
> -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o
> libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
> -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32
> 
> The error messages also contain these, which seem interesting:
> Error: _num does not have a number assigned
> Cannot export MD2: symbol not defined
> Cannot export MD2_Final: symbol not defined
> Cannot export MD2_Init: symbol not defined
> Cannot export MD2_Update: symbol not defined
> Cannot export MD2_options: symbol not defined
> Cannot export RC5_32_cbc_encrypt: symbol not defined
> Cannot export RC5_32_cfb64_encrypt: symbol not defined
> Cannot export RC5_32_decrypt: symbol not defined
> Cannot export RC5_32_ecb_encrypt: symbol not defined
> Cannot export RC5_32_encrypt: symbol not defined
> Cannot export RC5_32_ofb64_encrypt: symbol not defined
> Cannot export RC5_32_set_key: symbol not defined
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1
> make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2
> make: *** [Makefile:139: all] Error 2
> 
> -Matt Stickney
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Master: test fails

[Blumenthal, Uri - 0553 - MITLL]

CI does not seem to flag/manifest this error any more.

 

--

Regards,

Uri 

 

From: openssl-dev  on behalf of Uri Blumenthal 

Reply-To: openssl-dev 
Date: Sunday, July 23, 201730 at 21:06
To: Rich Salz 
Cc: openssl-dev 
Subject: Re: [openssl-dev] Master: test fails

 

On Jul 23, 2017, at 09:17, Salz, Rich  wrote:

 

So what are your exact config options?  Just the “./config” line. 

 

 

Simple:

 

./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Master: test fails

[Blumenthal, Uri - 0553 - MITLL]

On Jul 23, 2017, at 09:17, Salz, Rich  wrote:
> 
> So what are your exact config options?  Just the “./config” line. 


Simple:

./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 enable-tls13downgrade

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Master: test fails

[Blumenthal, Uri - 0553 - MITLL]

Sure looks like that...

Regards,
Uri

Sent from my iPhone

> On Jul 22, 2017, at 14:41, Salz, Rich via openssl-dev 
>  wrote:
> 
> Wow that green is hard to read J
>  
> So your config options change the tests for 70-test-tls13messages, but the 
> plan isn’t updated, right?
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Master: test fails

[Blumenthal, Uri - 0553 - MITLL]

$ make distclean || true
$ ./config --prefix=$HOME/openssl-1.1 --openssldir=$HOME/openssl-1.1/etc 
enable-aria enable-ec_nistp_64_gcc_128 enable-md2 enable-rc5 
enable-weak-ssl-ciphers enable-zlib-dynamic enable-tls1_3 
enable-tls13downgrademake depend && make clean && make -j 4 all && make test
. . . . .

../test/recipes/99-test_fuzz.t . ok 

Test Summary Report
---
../test/recipes/70-test_tls13messages.t  (Wstat: 13 Tests: 13 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 16 tests but ran 13.
Files=130, Tests=1257, 392 wallclock secs ( 2.60 usr  0.50 sys + 190.86 cusr 
109.06 csys = 303.02 CPU)
Result: FAIL
make[1]: *** [_tests] Error 1
—
Regards,
Uri

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] what's possible and what's not ... including RNGs

[Blumenthal, Uri - 0553 - MITLL]

Knowledge of the platform is a required part of the OpenSSL configuration. If 
the platform supports HRNG (usually in the form of CPU instructions), use it: 
let OpenSSL mix its output with whatever other randomness sources it picks on 
that platform/system. IMHO that’s the best strategy.

Thankfully, many of the newer platforms support those instructions. For those 
that don’t – you’d have to either rely on the OS, or try to play OS (which is 
difficult if the OS is not friendly, and impossible if the OS is hostile). 

PGP used to collect randomness from the user keyboard input. That may be fine 
for some applications – but a no-go for a library, IMHO.
--
Regards,
Uri Blumenthal
 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

Defence in depth seems prudent: independent sources with agglomeration and 
whitening.

As Kurt noted, [on modern OSes,] it is really unclear what sources are 
available to us that are not already being used by the kernel.

 

I would turn to hardware. Since OpenSSL already has assembly-level optimization 
for various CPU types, accessing instructions like RDSEED and RDRAND (when 
available) doesn’t sound too hard. Mix their output into the seed. It can only 
improve the result.

 

So, [on these same modern OSes,] what benefit do we really get from using 
multiple "independent" sources?  They are unlikely to actually be independent 
if the kernel is consuming them as well and we consume the kernel.

 

Depends on what you mean by “independent”. A completely different mechanism – 
probably not. A mechanism whose output bits/bytes are not (tractably) 
correlated? Probably yes.



We shouldn't trust the user to provide entropy. 
 
Definitely. 

 

No.  We shouldn’t trust the user to provide all entropy – but should welcome 
user’s contribution to the entropy pool.




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

> Pseudorandomness of the output has been a design goal/requirement only
> in SHA-3 family. Any prior hash function’s exhibition of this property is
> coincidental.
> 
> Therefore I suggest using SHA3 instead.

Is pseudorandomness a requirement?  Or is it the "50% chance of a bitflip"?

For [P]RNG?! In one word: yes. 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Blumenthal, Uri - 0553 - MITLL]

  My thoughts.

  Randomness should be whitened.  Anything feed into an randomness pool, 
should be mixed in and run through SHA256.
pool = SHA256(pool || new-randomness)

Pseudorandomness of the output has been a design goal/requirement only in SHA-3 
family. Any prior hash function’s exhibition of this property is coincidental.

Therefore I suggest using SHA3 instead.
 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 5/15/17, 1:20 PM, "openssl-dev on behalf of Benjamin Kaduk via openssl-dev" 
 wrote:

> On a semi-related note, I want able to locate mann.h file either.


`man mmap` will list any headers needed for the mmap() declaration and flag 
values.
On the random OS X machine I have handy, it claims  is needed, 

and a /usr/include/sys/mman.h is present.


Thanks – I confirm that `man mmap` mentions /usr/include/sys/mman.h, and that 
file does exist (how could my first `find` miss it?!). 

This file does not contain MLOCK_ONFAULT though.

 

It has MAP_ANON:

 

/*

 * Mapping type

 */

#define MAP_FILE0x  /* map from file (default) */

#define MAP_ANON0x1000  /* allocated from memory, swap space */

#define MAP_ANONYMOUS   MAP_ANON

 

And as I already mentioned, it has a world-accessible (figuratively speaking :) 
/dev/zero that can be opened read/write.

 

Also, with #3455 applied the problem disappeared (thankfully :).

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

Yes and yes. :-)

Regards,
Uri

Sent from my iPhone

> On May 15, 2017, at 13:18, Short, Todd <tsh...@akamai.com> wrote:
> 
> s/want/wasn’t/ ?
> 
> So, no MLOCK_ONFAULT for you? That’s only included on Linux systems, which 
> makes sense if you’re on a Mac.
> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
> 
>> On May 15, 2017, at 1:15 PM, Blumenthal, Uri - 0553 - MITLL 
>> <u...@ll.mit.edu> wrote:
>> 
>> My disk is SSD, but computer load is pretty high. Which probably explains 
>> that recovery doesn't take place in 200-400 seconds...
>> 
>> On a semi-related note, I want able to locate mann.h file either.
>> 
>> Regards,
>> Uri
>> 
>> Sent from my iPhone
>> 
>>> On May 15, 2017, at 13:09, Short, Todd <tsh...@akamai.com> wrote:
>>> 
>>> The time of the hang actually seems dependent on the number of applications 
>>> running and your disk.
>>> 
>>> Since a large amount of memory becomes wired, there is very little 
>>> available for programs and the OS to use (in some instances I have seen 
>>> ~4MB non-wired memory). Things slow down due to swapping, etc. 
>>> 
>>> In my testing:
>>> 
>>> With almost no additional programs open, the hang-time is short, ~200 
>>> seconds.
>>> With a lot of programs open, the hang-time is increased, ~400 seconds; 
>>> twice as long. And the number of swapins is 25x and the swapouts is ~34x 
>>> the original test period.
>>> 
>>> This is on a machine with an SSD (late-2013 MBP)
>>> If you have a spinning HDD, the swapins and swapouts will be significantly 
>>> more expensive in terms of performance/time.
>>> 
>>> If you quit all your programs, (other than Terminal), I suspect the hang 
>>> may eventually recover; but if you have a hard disk that time might be 
>>> quite long.
>>> 
>>> --
>>> -Todd Short
>>> // tsh...@akamai.com
>>> // "One if by land, two if by sea, three if by the Internet."
>>> 
>>>> On May 15, 2017, at 11:51 AM, Blumenthal, Uri - 0553 - MITLL 
>>>> <u...@ll.mit.edu> wrote:
>>>> 
>>>> I’m tracking the current OpenSSL master only on El Capitan 10.11.6. I 
>>>> could try it on Sierra 10.12.4, if you really expect it to make a 
>>>> difference.
>>>>  
>>>> In my case the hang is not for a short time. It lasts for more than 10 
>>>> minutes, so I’m forced to interfere. For how long did it hang for you?
>>>> — 
>>>> Regards,
>>>> Uri
>>>>  
>>>>  
>>>> On 5/15/17, 11:47 AM, "openssl-dev on behalf of Short, Todd via 
>>>> openssl-dev" <openssl-dev-boun...@openssl.org on behalf of 
>>>> openssl-dev@openssl.org> wrote:
>>>>  
>>>> We’ve been able to get some Macs (10.11.6, 8GB and 16GB) to hang for a 
>>>> short period of time with the unit-tests, but it eventually recovers. 
>>>>  
>>>> What MacOS version are you running? I can try 10.12 later today.
>>>> --
>>>> -Todd Short
>>>> // tsh...@akamai.com
>>>> // "One if by land, two if by sea, three if by the Internet."
>>>>  
>>>>> On May 12, 2017, at 4:50 PM, Short, Todd via openssl-dev 
>>>>> <openssl-dev@openssl.org> wrote:  
>>>>>  
>>>>> Uri: 
>>>>>  
>>>>> Look at https://github.com/openssl/openssl/pull/3455
>>>>>  
>>>>> I limited the test that hung your machine to Linux.
>>>>>  
>>>>> Rich: this removes the OpenSSL_assert() you see.
>>>>>  
>>>>> --
>>>>> -Todd Short
>>>>> // tsh...@akamai.com
>>>>> // "One if by land, two if by sea, three if by the Internet."
>>>>>  
>>>>>> On May 12, 2017, at 4:46 PM, Short, Todd via openssl-dev 
>>>>>> <openssl-dev@openssl.org> wrote:
>>>>>>  
>>>>>> It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...
>>>>>> --
>>>>>> -Todd Short
>>>>>> // tsh...@akamai.com
>>>>>> // "One if by land, two if by sea, three if by the Internet."
>>>>>>  
>>>>>>> On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL 
>>>>>>> <u...@ll.mit.edu> wrote:
>>>>>>>  
>>>>>>> Todd> Yes, it’s likely this is due to the amount of memory available in 
>>>>>>> the machine. I tried to use reasonable values, but apparently not 
>>>>>>> reasonable enough
>>>>>>>  
>>>>>>> Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of 
>>>>>>> stuff, besides these tests :).
>>>>>>> -- 
>>>>>>> openssl-dev mailing list
>>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>>>>> 
>>>>>>  
>>>>>> -- 
>>>>>> openssl-dev mailing list
>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>>>> 
>>>>>  
>>>>> -- 
>>>>> openssl-dev mailing list
>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>>> 
>>>>  
>>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

My disk is SSD, but computer load is pretty high. Which probably explains that 
recovery doesn't take place in 200-400 seconds...

On a semi-related note, I want able to locate mann.h file either.

Regards,
Uri

Sent from my iPhone

> On May 15, 2017, at 13:09, Short, Todd <tsh...@akamai.com> wrote:
> 
> The time of the hang actually seems dependent on the number of applications 
> running and your disk.
> 
> Since a large amount of memory becomes wired, there is very little available 
> for programs and the OS to use (in some instances I have seen ~4MB non-wired 
> memory). Things slow down due to swapping, etc. 
> 
> In my testing:
> 
> With almost no additional programs open, the hang-time is short, ~200 seconds.
> With a lot of programs open, the hang-time is increased, ~400 seconds; twice 
> as long. And the number of swapins is 25x and the swapouts is ~34x the 
> original test period.
> 
> This is on a machine with an SSD (late-2013 MBP)
> If you have a spinning HDD, the swapins and swapouts will be significantly 
> more expensive in terms of performance/time.
> 
> If you quit all your programs, (other than Terminal), I suspect the hang may 
> eventually recover; but if you have a hard disk that time might be quite long.
> 
> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
> 
>> On May 15, 2017, at 11:51 AM, Blumenthal, Uri - 0553 - MITLL 
>> <u...@ll.mit.edu> wrote:
>> 
>> I’m tracking the current OpenSSL master only on El Capitan 10.11.6. I could 
>> try it on Sierra 10.12.4, if you really expect it to make a difference.
>>  
>> In my case the hang is not for a short time. It lasts for more than 10 
>> minutes, so I’m forced to interfere. For how long did it hang for you?
>> — 
>> Regards,
>> Uri
>>  
>>  
>> On 5/15/17, 11:47 AM, "openssl-dev on behalf of Short, Todd via openssl-dev" 
>> <openssl-dev-boun...@openssl.org on behalf of openssl-dev@openssl.org> wrote:
>>  
>> We’ve been able to get some Macs (10.11.6, 8GB and 16GB) to hang for a short 
>> period of time with the unit-tests, but it eventually recovers. 
>>  
>> What MacOS version are you running? I can try 10.12 later today.
>> --
>> -Todd Short
>> // tsh...@akamai.com
>> // "One if by land, two if by sea, three if by the Internet."
>>  
>>> On May 12, 2017, at 4:50 PM, Short, Todd via openssl-dev 
>>> <openssl-dev@openssl.org> wrote:  
>>>  
>>> Uri: 
>>>  
>>> Look at https://github.com/openssl/openssl/pull/3455
>>>  
>>> I limited the test that hung your machine to Linux.
>>>  
>>> Rich: this removes the OpenSSL_assert() you see.
>>>  
>>> --
>>> -Todd Short
>>> // tsh...@akamai.com
>>> // "One if by land, two if by sea, three if by the Internet."
>>>  
>>>> On May 12, 2017, at 4:46 PM, Short, Todd via openssl-dev 
>>>> <openssl-dev@openssl.org> wrote:
>>>>  
>>>> It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...
>>>> --
>>>> -Todd Short
>>>> // tsh...@akamai.com
>>>> // "One if by land, two if by sea, three if by the Internet."
>>>>  
>>>>> On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL 
>>>>> <u...@ll.mit.edu> wrote:
>>>>>  
>>>>> Todd> Yes, it’s likely this is due to the amount of memory available in 
>>>>> the machine. I tried to use reasonable values, but apparently not 
>>>>> reasonable enough
>>>>>  
>>>>> Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of 
>>>>> stuff, besides these tests :).
>>>>> -- 
>>>>> openssl-dev mailing list
>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>>> 
>>>>  
>>>> -- 
>>>> openssl-dev mailing list
>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>> 
>>>  
>>> -- 
>>> openssl-dev mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>> 
>>  
> 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

I’m tracking the current OpenSSL master only on El Capitan 10.11.6. I could try 
it on Sierra 10.12.4, if you really expect it to make a difference.

 

In my case the hang is not for a short time. It lasts for more than 10 minutes, 
so I’m forced to interfere. For how long did it hang for you?

— 

Regards,

Uri

 

 

On 5/15/17, 11:47 AM, "openssl-dev on behalf of Short, Todd via openssl-dev" 
<openssl-dev-boun...@openssl.org on behalf of openssl-dev@openssl.org> wrote:

 

We’ve been able to get some Macs (10.11.6, 8GB and 16GB) to hang for a short 
period of time with the unit-tests, but it eventually recovers. 

 

What MacOS version are you running? I can try 10.12 later today.

--

-Todd Short

// tsh...@akamai.com

// "One if by land, two if by sea, three if by the Internet."

 

On May 12, 2017, at 4:50 PM, Short, Todd via openssl-dev 
<openssl-dev@openssl.org> wrote:  

 

Uri: 

 

Look at https://github.com/openssl/openssl/pull/3455

 

I limited the test that hung your machine to Linux.

 

Rich: this removes the OpenSSL_assert() you see.

 

--

-Todd Short

// tsh...@akamai.com

// "One if by land, two if by sea, three if by the Internet."

 

On May 12, 2017, at 4:46 PM, Short, Todd via openssl-dev 
<openssl-dev@openssl.org> wrote:

 

It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...

--

-Todd Short

// tsh...@akamai.com

// "One if by land, two if by sea, three if by the Internet."

 

On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> 
wrote:

 

Todd> Yes, it’s likely this is due to the amount of memory available in the 
machine. I tried to use reasonable values, but apparently not reasonable enough

 

Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of stuff, 
besides these tests :).

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

 

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

 

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

The obvious candidate for closer inspection is a few commits previous,

commit 7031ddac94d0ae616d1b0670263a9265ce672cd2
Author: Todd Short 
Date:   Thu May 11 15:48:10 2017 -0400

which adds test cases intended to trigger the edge cases being fixed.



Point well-taken. ;-)

 

It seems that there should also be a bug report against OS X, as regular 
userspace code running as non-root should not be able to hang a machine like 
that.

I’m not sure. It may well be that it “simply” takes all the memory over, so 
there is no way for anything else to start and do the clean-up…

 

>From just looking at the code, the only question that comes to mind is whether 
>you have a 32- or 64-bit size_t in the build environment in question, which is 
>unlikely to cause a eureka moment :(

 

I can tell you that size_t is 64-bit here. It’s certainly not an “eureka” 
moment for me.

 

Some other information to check: do you have MAP_ANON defined by your mman.h?


/**

 * @addtogroup apr_platform

 * @ingroup APR 

 * @{

 */

 

#define APR_HAVE_SHMEM_MMAP_TMP 1

#define APR_HAVE_SHMEM_MMAP_SHM 1

#define APR_HAVE_SHMEM_MMAP_ZERO0

#define APR_HAVE_SHMEM_SHMGET_ANON  1

#define APR_HAVE_SHMEM_SHMGET   1

#define APR_HAVE_SHMEM_MMAP_ANON1

#define APR_HAVE_SHMEM_BEOS 0

 

#define APR_USE_SHMEM_MMAP_TMP 0

#define APR_USE_SHMEM_MMAP_SHM 0

#define APR_USE_SHMEM_MMAP_ZERO0

#define APR_USE_SHMEM_SHMGET_ANON  0

#define APR_USE_SHMEM_SHMGET   1

#define APR_USE_SHMEM_MMAP_ANON1

#define APR_USE_SHMEM_BEOS 0

 

And this system does not seem to have a straight “mmap.h”. The above is from 
/usr/include/apr-1/apr_mmap.h file.

 

Do you have a /dev/zero that can be opened read/write?

 

Yep:

 

$ ll /dev/zero

crw-rw-rw-  1 root  wheel3,   3 May 12 14:14 /dev/zero

$ 

 

Todd> Yes, it’s likely this is due to the amount of memory available in the 
machine. I tried to use reasonable values, but apparently not reasonable enough

 

Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of stuff, 
besides these tests :).



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 5/12/17, 2:49 PM, "openssl-dev on behalf of Benjamin Kaduk via openssl-dev" 
 wrote:

➢ I’m sorry to report that in the current OpenSSL 1.1 master running “make test”
➢  freezes up the machine. Mac OS X 10.11.6, Xcode-8.2, current Github master. 
➢ Here’s the configuration:

  A commit hash would be more useful than "current github master"

I thought you know what’s in the current master right now. But here’s the last 
few hashes for your pleasure:

$ git log
commit 80a2fc4100daf6f1001eee33ef2f9b9eee05bedf (HEAD -> master, origin/master, 
origin/HEAD)
Author: Todd Short 
Date:   Wed May 10 11:44:55 2017 -0400

Clean up SSL_OP_* a bit

Reviewed-by: Matt Caswell 
Reviewed-by: Rich Salz 
(Merged from https://github.com/openssl/openssl/pull/3439)

commit 33242d9d79e7f06151e905b83dc8f995006fa7cd
Author: Rich Salz 
Date:   Thu May 11 20:42:32 2017 -0400

Use scalar, not length; fixes test_evp

Reviewed-by: Stephen Henson 
Reviewed-by: Richard Levitte 
(Merged from https://github.com/openssl/openssl/pull/3452)


  I can understand not wanting to have to power-cycle the machine again,
  but the 'make TESTS=test_secmem V=1 test' output (or some dtruss/similar)
  would be helpful in tracking things down.

Sorry.

  How locked up is the machine?  Can you get memory usage stats or is it 
completely unresponsive?

Completely unresponsive. Totally. No memory usage. The only thing that works at 
this point is the power button.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

I’m sorry to report that in the current OpenSSL 1.1 master running “make test” 
freezes up the machine. Mac OS X 10.11.6, Xcode-8.2, current Github master. 
Here’s the configuration:

 

./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib 
enable-ec_nistp_64_gcc_128 enable-rfc3779 enable-rc5 enable-tls1_3 
--prefix=/Users/uri/src/openssl-1.1 --openssldir=/Users/uri/src/openssl-1.1/etc

 

Then of course “make depend && make clean && make all && make test”

 

../test/recipes/90-test_ige.t . ok   

../test/recipes/90-test_memleak.t . ok   

../test/recipes/90-test_overhead.t  skipped: Only supported in 
no-shared builds

../test/recipes/90-test_secmem.t .. 

 

At this point the machine has to be power-cycled.

— 

Regards,

Uri

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 4/13/17, 5:58 PM, "openssl-dev on behalf of Richard Levitte" 
 wrote:

deengert> > uri> $ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt 
-inkey
deengert> > 
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep
deengert> > -in t256.dat.enc -out t256.dat.dec


Replacing, as Richard suggested, rsautl with pkeyutl resulted in a successful 
decryption of the previously encrypted message:

$ openssl pkeyutl -engine pkcs11 -keyform ENGINE -decrypt -inkey 
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -pkeyopt 
rsa_padding_mode:oaep -in t256.dat.enc -out t256.dat.dec
engine "pkcs11" set.
Enter PKCS#11 token PIN for PIV Card Holder pin (PIV_II):
$ cmp t256.dat t256.dat.dec 
$

. . . . . rsautl is a poor choice, as it uses the RSA
API.  For something more general and with a whole lot more
functionality, pkeyutl is the better choice.

Your suggestion worked perfectly – I didn’t even need to provide any 
parameters, besides specifying the padding mode.


Does it mean that rsautl is pretty much deprecated, and pkeyutl superseded it? 
Or is it still worth bringing it “up to snuff”?


Incidently, for decryption, it will end up calling exactly the code
you're citing,

( What a coincidence!

and with -pkeyopt, you can specify the padding mode and
its necessary data.

Yep, and thanks for the great suggestion! Now whether rsautl.c is fixed or not 
- is no longer critical (though since it’s still included in the codebase, 
perhaps it could be made more capable?).

Thanks!


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 4/13/17, 5:18 PM, "Richard Levitte"  wrote:

uri> . . . . .
uri> libp11 does not know how to deal with OAEP padding, so it returns an 
error.
uri> 
uri> Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the 
engine (aka to libp11), and strip the padding using OpenSSL mechanisms.
uri> 
uri> I’d like to see that fixed in both 1.1 and 1.0.2 branches.

Wouldn't it be much easier to add the following lines [to 
libp11/src/p11_rsa.c]:

case RSA_PKCS1_OAEP_PADDING:
mechanism->mechanism = CKM_RSA_PKCS_OAEP;
break;


I’m afraid not – because currently OpenSSL does have full support for OAEP, and 
OpenSC has none. This is what causes the problem: OpenSSL expects the engine 
(libp11 and OpenSC) to handle OAEP, which they cannot do.

What you propose for OpenSSL is quite a lot harder to implement well,

I agree that it’s harder to implement *well*, but it is a lot simpler and 
shorter to implement in rsautl.c (a few lines of code), as compared to adding 
the whole support for OAEP to OpenSC (which – I agree – would be great to have, 
but let’s be realistic: it’s not there now).

and one might also wonder why the OAEP padding should have that
special treatment and no other?

I’d say the same treatment is applicable to any padding that is supported by 
OpenSSL but not by (the majority of) PKCS#11 devices (and OpenSC). 

What OpenSSL does programmatically with this is (IMHO) perfect. This code works 
correctly with the token that only does raw RSA (the original had a lot more of 
error checking stuff ():

privkey = ENGINE_load_private_key(e, KeyManPrivKey, NULL, _data);

ctx = EVP_PKEY_CTX_new(privkey, NULL);
EVP_PKEY_free(privkey);

rv = EVP_PKEY_decrypt_init(ctx);
if (rv <= 0) goto end;
rv = EVP_PKEY_CTX_set_rsa_padding(ctx, PADDING);

*olen = 0;
rv = EVP_PKEY_decrypt(ctx, NULL, olen, in, inlen);

*out = OPENSSL_malloc(*olen);
rv = EVP_PKEY_decrypt(ctx, *out, olen, in, inlen);
end:

Perhaps rsautl.c could do the same? Instead of what it’s doing now (aka calling 
RSA_private_decrypt())?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

I am trying to use “openssl rsautl” to wrap/unwrap symmetric keys in a script. 
Decryption (and encryption too, but that isn’t relevant) is done using a token 
accessible via pkcs11 engine (libp11).

The problem is: “rsautl” appears to assume that if “-oaep” flag is given, then 
the engine is going to handle OAEP padding. This is the screen log:

$ openssl rsautl -engine pkcs11 -keyform ENGINE -encrypt -pubin -inkey 
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20pubkey;type=public" -oaep -in 
t256.dat -out t256.dat.enc
engine "pkcs11" set.
$ ls -l t256.dat.enc 
-rw-r--r--  1 mouse   256 Apr 10 17:34 t256.dat.enc
$ openssl rsautl -engine pkcs11 -keyform ENGINE -decrypt -inkey 
"pkcs11:manufacturer=piv_II;object=KEY%20MAN%20key;type=private" -oaep -in 
t256.dat.enc -out t256.dat.dec
engine "pkcs11" set.
PKCS#11 token PIN: 
PKCS#11: Unsupported padding type
RSA operation error
$

libp11 does not know how to deal with OAEP padding, so it returns an error.

Desired solution: in case of “-oaep” pass “RSA_NO_PADDING” to the engine (aka 
to libp11), and strip the padding using OpenSSL mechanisms.

I’d like to see that fixed in both 1.1 and 1.0.2 branches.
— 
Regards,
Uri



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Blumenthal, Uri - 0553 - MITLL]

I personally think this issue is being blown way out of proportion and beyond 
the boundary of reason. 

Regards,
Uri

Sent from my iPhone

> On Mar 24, 2017, at 05:07, Otto Moerbeek <o...@drijf.net> wrote:
> 
>> On Fri, Mar 24, 2017 at 09:40:16AM +0100, Kurt Roeckx wrote:
>> 
>>> On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote:
>>>> On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote:
>>>> 
>>>>> On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote:
>>>>>> On Fri, Mar 24, 2017 at 04:11:48AM +, Blumenthal, Uri - 0553 - MITLL 
>>>>>> wrote:
>>>>>> 
>>>>>> Apache license is fine for me, while GPL could be problematic. 
>>>>>> Incompatibility with GPLv2 is not a problem for us. 
>>>>>> 
>>>>>> If it is a problem for somebody - feel free to explain the details. 
>>>>>> Though I think the decision has been made, and the majority is OK with 
>>>>>> it. 
>>>>> 
>>>>> I like to mention that any license change cannot be made based on a
>>>>> majority vote or any other method other than getting each author (or
>>>>> its legal representative) to *explicitly* allow the change. The method
>>>>> of "nothing heard equals consent" is not valid in any jurisdiction I
>>>>> know of.
>>>>> 
>>>>> While I'm not a contributor (I think I only sent in a small diff years
>>>>> ago), I would like to stress that the planned relicensing procedure is
>>>>> not legal and can be challenged in court.
>>>> 
>>>> Well, emails were sent yesterday out to _all_ contributors for ack/deny 
>>>> the change.
>>> 
>>> Read the last line of the mail, it says the no reactions equals
>>> consent. That is the illegal part.
>> 
>> The legal advice we got said that we should do our best to contact
>> people. If we contacted them, they had the possibility to say no.
>> We will give them time and go over all people that didn't reply to
>> try to reach them.
>> 
>> But if they don't reply, as said, we will assume they have no
>> problem with the license change. If at some later point in time
>> they do come forward and say no, we will deal with that at that
>> time.
>> 
>> 
>> Kurt
> 
> Probably illegal and definitely immoral, in my opinion. Copyright law
> exists to protect authors from these kind of practises.
> 
>-Otto
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] License change agreement

[Blumenthal, Uri - 0553 - MITLL]

Apache license is fine for me, while GPL could be problematic. Incompatibility 
with GPLv2 is not a problem for us. 

If it is a problem for somebody - feel free to explain the details. Though I 
think the decision has been made, and the majority is OK with it. 

Regards,
Uri

Sent from my iPhone

> On Mar 23, 2017, at 22:27, Quanah Gibson-Mount  wrote:
> 
> --On Friday, March 24, 2017 1:37 AM + Peter Waltenberg 
>  wrote:
> 
>> 
>> OpenSSL has a LOT of commercial users and contributors. Apache2 they can
>> live with, GPL not so much.
>> There's also the point that many of the big consumers (like Apache :))
>> are also under Apache2.
>> 
>> Least possible breakage and I think it's a reasonable compromise. Of
>> course I am biased because I work for the one of the commercial users.
> 
> Zero people that I know of are saying to switch to the GPL.  What is being 
> pointed out is that the incompatibility with the current OpenSSL license with 
> the GPLv2 has been a major problem.  Switching to the APLv2 does nothing to 
> resolve that problem.  As has been noted, the current advertising is a huge 
> problem with the existing license.  One of the reasons that has been a big 
> problem is that it makes the license incompatible with the GPLv2.  So on the 
> one hand, getting rid of that clause is great.  On the other hand, getting 
> rid of it by switching to the APL is not great, because it doesn't resolve 
> the fundamental problem of being incompatible with the GPLv2.
> 
> As was noted back when this was brought up in 2015, there are other, better, 
> licenses than the APLv2 which are also GPLv2 compatible.  The MPLv2 being an 
> example of such a license.  There is also BSD, MIT/X11, etc.  The GPLv2 
> incompatibility of OpenSSL is a major problem.
> 
> --Quanah
> 
> --
> 
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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

 

Or am I missing something?

— 

Regards,

Uri

 

 

On 1/10/17, 2:19 PM, "openssl-dev on behalf of Benjamin Kaduk" 
 wrote:

 

On 01/10/2017 12:31 PM, Richard Levitte wrote:

 
Benjamin Kaduk  skrev: (10 januari 2017 18:48:32 CET)
On 01/09/2017 10:05 PM, Salz, Rich wrote:
Should we move to using SIPHash for the default string hashing
function in OpenSSL?  It’s now in the kernel
https://lkml.org/lkml/2017/1/9/619
 
Heck, yes! 
-Ben
I fail to see what that would give us. OPENSSL_LH_strhash() is used to get a 
reasonable index for LHASH entries. Also SIPhash gives at least 64 bits 
results, do we really expect to see large enough hash tables to warrant that? 
 

We don't need to use the full output width of a good hash function.


My main point is, "why would we want to ignore the last 20 years of advancement 
in hash function research?"  Section 7 of the siphash paper 
(https://131002.net/siphash/siphash.pdf) explicitly talks about using it for 
hash tables, including using hash table indices H(m) mod l.

-Ben



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

I confirm that this fix (currently in the master) resolves the issue.

Thanks!
— 
Regards,
Uri


On 11/29/16, 4:53 AM, "openssl-dev on behalf of Matt Caswell" 
<openssl-dev-boun...@openssl.org on behalf of m...@openssl.org> wrote:



On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote:
> > The problem is in the test. Version negotiation happens before 
cipher
> > selection. The test creates a connection which negotiates TLSv1.3. 
It
> > then attempts to select a cipher. However no TLSv1.3 ciphers are 
offered
> > by the test so the connection aborts. In truth the test is all about
> > mac-then-encrypt which doesn't apply to TLSv1.3 anyway, so the test
> > should just disable negotiation of that protocol version.
> 
> Thanks for explaining! 
> 
> Would you be able to push a fix for this test?

Fix is in github:

https://github.com/openssl/openssl/pull/2013

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

>> So why is it better to say “…engine –key /some/weird/path/weird
>> -file.pem” than “…engine –key pkcs11:id=02” (or such)?
>
> There appears to be some confusion here.  pkcs11 is a representation
> for defined tokens. 

Well, I did not mean *specifically* pkcs11 – just as an example of something 
that currently works.


> However, for TPM, there's also file representation
> of an unloaded key (it has to be parented or "wrapped" to one of the
> loaded storage keys, usually the SRK). 

So this PEM wrapping is needed just to load keys into TPM? How do you refer to 
those keys when they are already loaded?


> The point here is that because there's a pem file representation of the
> key, it can be used anywhere a PEM file can be *without* having to tell
> openssl what the engine is (the PEM guards being unique to the key
> type).

Well, I think I can see your point (except for the above question), but frankly 
I don’t like this approach very much.



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" 
 wrote:

> One of the principle problems of using TPM based keys is that there's
> no easy way of integrating them with standard file based keys. 

Why should token- and/or TPM-based keys be integrated with file-based keys? 
OpenSSL and its engines need/should accept URI pointing at the keys. Pointing 
them at files containing some proprietary reference to keys that are kept in 
hardware does not seem to make sense. 

So why is it better to say “…engine –key /some/weird/path/weird-file.pem” than 
“…engine –key pkcs11:id=02” (or such)?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

> The problem is in the test. Version negotiation happens before cipher
> selection. The test creates a connection which negotiates TLSv1.3. It
> then attempts to select a cipher. However no TLSv1.3 ciphers are offered
> by the test so the connection aborts. In truth the test is all about
> mac-then-encrypt which doesn't apply to TLSv1.3 anyway, so the test
> should just disable negotiation of that protocol version.

Thanks for explaining! 

Would you be able to push a fix for this test?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

>I can't reproduce this. But on the other hand I don't have previous
>installation on --prefix. 

But did you add “enable-tls1_3” to your config?

>I mean I would guess this is because test
>program picks shared libraries at --prefix locations instead of just
>built ones, and those don't recognize 19-mac-then-encrypt.conf options.
>Originally shlib_wrap.sh had DYLD_INSERT_LIBRARIES to make it work, but
>it appears to be gone now... You should be able to confirm this by
>temporarily renaming --prefix location and running 'make test' or
>forcing install without testing...

I forced the install without testing, and then re-ran the entire build and 
test. I’m getting the very same problem.  I must also say that I’ve been 
tracking 1.1 branch for a very long time, always using this approach (without 
even forcing the install – it did not seem confused regarding what libraries to 
link against). 

The only thing that changed for this build now was addition of “enable-tls1_3” 
config option (and of course, pulling the latest stuff from the master).

Removing “enable-tls1_3” and reconfiguring makes this error disappear. So I 
think it’s somewhere in tls1_3 code. ;-)


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

Mac OS X 10.11.6, Xcode-8.1. 

$ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib 
enable-ec_nistp_64_gcc_128 enable-rfc3779 
--prefix=/Users/ur20980/src/openssl-1.1 
--openssldir=/Users/ur20980/src/openssl-1.1/etc
Configuring OpenSSL version 1.1.1-dev (0x10101000L)
no-asan [default]  OPENSSL_NO_ASAN
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
no-egd  [default]  OPENSSL_NO_EGD
no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
no-fuzz-afl [default]  OPENSSL_NO_FUZZ_AFL
no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-msan [default]  OPENSSL_NO_MSAN
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE
no-ssl3 [default]  OPENSSL_NO_SSL3
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
no-tls1_3   [default]  OPENSSL_NO_TLS1_3
no-ubsan[default]  OPENSSL_NO_UBSAN
no-unit-test[default]  OPENSSL_NO_UNIT_TEST
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib-dynamic [default] 
Configuring for darwin64-x86_64-cc

PERL  =/opt/local/bin/perl5.24
PERLVERSION   =5.24.0 for darwin-thread-multi-2level
HASHBANGPERL  =/usr/bin/env perl
CC=clang
CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
CXX   =clang++
CXXFLAG   =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
DEFINES   =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS 
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT 
OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM 
MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM 
POLY1305_ASM
EX_LIBS   =-lz 
$ ./Configure darwin64-x86_64-cc enable-threads enable-shared enable-zlib 
enable-ec_nistp_64_gcc_128 enable-rfc3779 enable-rc5 enable-tls1_3 
--prefix=/Users/ur20980/src/openssl-1.1 
--openssldir=/Users/ur20980/src/openssl-1.1/etc
Configuring OpenSSL version 1.1.1-dev (0x10101000L)
no-asan [default]  OPENSSL_NO_ASAN
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
no-egd  [default]  OPENSSL_NO_EGD
no-external-tests [default]  OPENSSL_NO_EXTERNAL_TESTS
no-fuzz-afl [default]  OPENSSL_NO_FUZZ_AFL
no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-msan [default]  OPENSSL_NO_MSAN
no-sctp [default]  OPENSSL_NO_SCTP
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE
no-ssl3 [default]  OPENSSL_NO_SSL3
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
no-ubsan[default]  OPENSSL_NO_UBSAN
no-unit-test[default]  OPENSSL_NO_UNIT_TEST
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib-dynamic [default] 
Configuring for darwin64-x86_64-cc

PERL  =/opt/local/bin/perl5.24
PERLVERSION   =5.24.0 for darwin-thread-multi-2level
HASHBANGPERL  =/usr/bin/env perl
CC=clang
CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
CXX   =clang++
CXXFLAG   =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall 
DEFINES   =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS 
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT 
OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM 
MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM 
POLY1305_ASM
EX_LIBS   =-lz 
$ make depend && make clean && make -j 4 all && make test && make install
. . . . .

../test/recipes/80-test_ssl_new.t .. 15/19 
#   Failed test 'running ssl_test 19-mac-then-encrypt.conf'
#   at ../test/recipes/80-test_ssl_new.t line 121.
# Looks like you failed 1 test of 3.

#   Failed test 'Test configuration 19-mac-then-encrypt.conf'
#   at ../test/recipes/80-test_ssl_new.t line 87.
# Looks like you failed 1 test of 19.
../test/recipes/80-test_ssl_new.t .. Dubious, test returned 1 
(wstat 256, 0x100)
Failed 1/19 subtests 
. . . . .




smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

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

Mm...  I'm not sure I agree with the method, passing a BIO for the
key_id. 

I’m sure I rather disagree, and rather strongly.

I would much rather have seen a patch where OpenSSL's PEM
module is tought to recognise 'BEGIN TSS KEY BLOB', pull out the blob
from it, securing it somehow (since key_id is expected to be be NUL
terminated) and pass that to the engine.

I would much rather use PEM only to contain keys/certs instead of “pointing” at 
them in some weird way.

My vote goes to a URI based spec rather than bastardising PEM files.

+10^101. ☺

I understand this kinda throws years of developmemt out the window,
but there you have it.

“It’s never too late to turn back on a wrong road”
 


smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

Frankly, I think this approach of specially-encoded PEM or DER files telling 
the app what key to ask from the engine is madness, compared to the 
straightforward URI approach (no pun intended :).

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: David Woodhouse
Sent: Monday, November 21, 2016 08:43
To: Richard Levitte; openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Cc: James Bottomley
Subject: Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM 
based RSA keys in openssl

On Wed, 2016-11-16 at 19:07 +0100, Richard Levitte wrote:
> 
> 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.
> 
> James, did I catch your intention about right?  I think that's
> essentially what e_tpm.c does for loading keys, right?
‎
Right. The TPM engine currently uses BEGIN TSS KEY BLOB-; I
added that a few years back (it used to just dump the binary blob
instead). Both the TPM ENGINE and GnuTLS will load those files, as
noted at http://www.infradead.org/openconnect/tpm.html

The problem is that applications have to jump through special hoops to
recognise the files and invoke the engine (and there's a special API in
GnuTLS too). It would be good if the appropriate engine could be
invoked *automatically*, so the crypto library just does the right
thing without all the applications even having to *know* about it.
(Just like GnuTLS will automatically Just Work in many situations when
presented with a PKCS#11 URI instead a filename, as OpenSSL also
should, but doesn't yet.)

However, the contents of the PEM file should *not* be OpenSSL-specific
and have engine names; I objected to James's original incarnation of
this, which had something like -BEGIN tpm ENGINE PRIVATE KEY-
and had the "tpm" engine automatically loaded on demand. It needs to be
something generic. Which means engines need to indicate *which* PEM
headers they can grok. And maybe the solution to this will tie in with
the general fixes we need for "normal" key files, so that applications
can Just Work with all of those too (qv¹).

Once the dust settles on TPMv2.0 we should probably put together an I-D 
for the TPM-wrapped blob PEM files. And I should definitely add
something about them to ¹.

-- 
dwmw2

¹ http://david.woodhou.se/draft-woodhouse-cert-best-practice.html


smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

Thank you! I think I understand. (Sounds like an ugly and hardly necessary 
complication to me – not to mention that there might not be a filesystem to 
keep those around, but…)
— 
Regards,
Uri


On 11/16/16, 5:06 PM, "openssl-dev on behalf of Dr. Stephen Henson" 
 wrote:

On Wed, Nov 16, 2016, 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



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

[Blumenthal, Uri - 0553 - MITLL]

My apologies – I don’t fully understand “file based engine keys”. I thought the 
keys were either on a hardware device (a TPM, a PKCS#11-accessible HSM or 
smartcard, etc), or in a file. If a key is in a file – it’s not an “engine key”.

What am I missing, and what’s your use case(s)?
— 
Regards,
Uri


On 11/16/16, 10:46 AM, "openssl-dev on behalf of James Bottomley" 
 wrote:

[David Woodhouse told me that openssl-dev is a closed list, so the
original messages got trashed.  This is a resend with apologies to
David and Peter]

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:

https://build.opensuse.org/project/show/home:jejb1:Tumbleweed

James

---

James Bottomley (2):
  engine: add new flag based method for loading engine keys
  pem: load engine keys

 crypto/engine/eng_int.h  |  1 +
 crypto/engine/eng_pkey.c | 38 ++
 crypto/engine/engine.h   | 26 ++
 crypto/pem/pem_pkey.c|  5 +
 4 files changed, 70 insertions(+)

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 9/16/16, 11:52, "openssl-dev on behalf of Salz, Rich" 
 wrote:



>>OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised
>> by client.
>
>When I made X25519 the default, I didn't think about it.  That was probably a 
>mistake.  Good catch!

I think so.

> 
>> So it is very likely that any client that doesn't advertise curves will 
>> expect the
>> server to select prime256v1. At the same time it is very unlikely that it 
>> will
>> support x25519 (given how new it is).
>
>Well the major browsers support it now, so once servers start upgrading to 
>1.1.0 it will be less of an issue.  But maybe the community thinks the current 
>behavior is a bug?

Yes I think it is a bug, and would like to see this behavior reverted.

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

If you want to dedicate a target to /arch:ia32, I can’t object or
complain. VC-WIN32-XP sounds like a good choice for that.
--
Regards,
Uri Blumenthal




On 8/26/16, 17:27, "openssl-dev on behalf of Scott Ware"
<openssl-dev-boun...@openssl.org on behalf of wsw...@gmail.com> wrote:

>On Fri, Aug 26, 2016 at 5:11 PM, Blumenthal, Uri - 0553 - MITLL
><u...@ll.mit.edu> wrote:
>> On 8/26/16, 17:04, "openssl-dev on behalf of Andy Polyakov"
>> <openssl-dev-boun...@openssl.org on behalf of ap...@openssl.org> wrote:
>>
>>>So suggestion is to impose /arch:ia32 on all users. Well, I personally
>>>have lesser problem with that (as most most performance-critical
>>>assembly code paths will be compiled anyway, processor capabilities
>>>detected at run-time, and inappropriate paths will be avoided), but I'm
>>>not sure if all users would appreciate it.
>>
>> Normally I don’t use Windows, so shouldn’t care. However, as
>>occasionally
>> I do stumble across a Windows system - I’d *much* dislike being stuck
>>with
>> /arch:ia32.
>>
>> 20 years ago I might have had a different opinion. ;)
>>
>>
>>> Note that it's possible to
>>>set CL environment variable to add options of your preference without
>>>modifying anything.
>>
>> And that’s probably what the requester should do, IMHO.
>>
>>>Maybe that would be more adequate option to
>>>customize builds for specific needs. In worst case it would be
>>>appropriate to tie this option to no-sse2 configuration option, but not
>>>unconditionally...
>>
>> Maybe…
>>
>
>I certainly agree for most modern users it is not needed and may slow
>down the code since it is not using the latest and greatest.
>
>How about something like this.. A VC-WIN32-XP target that has
>everything needed to make a max compatibility target
>When building under VS2012 and above.. (I also tested in VS2015)
>adds CFLAGS  /arch:IA32 -D_USING_V110_SDK71_
>adds BIN_LDFLAGS=/subsystem:console,5.01 /opt:ref
>
>And before you scream OMG XP..
>https://support.microsoft.com/en-us/gp/lifewinembed
>- Windows Embedded Standard 2009. This product is an updated release
>of the toolkit and componentized version of Windows XP. It was
>originally released in 2008; and Extended Support will end on January
>8, 2019.
>- Windows Embedded POSReady 2009. This product for Point of Sale
>devices reflects the updates available in Windows Embedded Standard
>2009. It was originally released on 2009, and extended support will
>end on April 9, 2019.
>
>People just don't want to upgrade these embedded machines, but we want
>to keep the communications between them as secure as possible with the
>latest and greatest OpenSSL. :P
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 8/26/16, 17:04, "openssl-dev on behalf of Andy Polyakov"
 wrote:

>So suggestion is to impose /arch:ia32 on all users. Well, I personally
>have lesser problem with that (as most most performance-critical
>assembly code paths will be compiled anyway, processor capabilities
>detected at run-time, and inappropriate paths will be avoided), but I'm
>not sure if all users would appreciate it.

Normally I don’t use Windows, so shouldn’t care. However, as occasionally
I do stumble across a Windows system - I’d *much* dislike being stuck with
/arch:ia32. 

20 years ago I might have had a different opinion. ;)


> Note that it's possible to
>set CL environment variable to add options of your preference without
>modifying anything.

And that’s probably what the requester should do, IMHO.

>Maybe that would be more adequate option to
>customize builds for specific needs. In worst case it would be
>appropriate to tie this option to no-sse2 configuration option, but not
>unconditionally...

Maybe… 


smime.p7s
Description: S/MIME cryptographic signature
-- 
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?

[Blumenthal, Uri - 0553 - MITLL]

On 7/26/16, 15:24 , "openssl-users on behalf of Dr. Stephen Henson"
 wrote:

>On Tue, Jul 26, 2016, Jim Carroll wrote:
>> After experimenting, I can confirm this is the same issue we're seeing,
>> although experiencing it very differently from the MIT/Kerberos team.
>>I can
>> confirm that right now PKCS7 sign/encrypt/decrypt is broken.
>
>A fix is currently being reviewed. It includes a test. It just happense
>that
>the standard CMS/PKCS#7 tests use a very short content length. If it is a
>little longer they trigger the bug.

I don’t think I’ve seen any mentioning of this bug being addressed yet
(could’ve missed the notification, of course).

So what’s the status if this issue? Has the fix been reviewed and applied?

Thanks!


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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.
However, the observed behavior is different:
$ openssl cms -engine pkcs11 -keyform engine -decrypt -debug_decrypt -aes256
-inform SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out
Cyph_Bot_test.decrypt1.eml -inkey
"pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
Error decrypting CMS using private key
140735083847760:error:2E072084:CMS routines:CMS_decrypt_set1_pkey:no
matching recipient:cms_smime.c:661:
$

The following proves that the provided private key is correct (and the above
decryption should’ve succeeded):
$ openssl cms -engine pkcs11 -keyform engine -decrypt -aes256 -inform SMIME
-in Cyph_Bot_test.smime.eml -outform SMIME -out Cyph_Bot_test.decrypt.eml
-recip ~/Documents/Certs/me_mouse_yubi_9d_.pem -inkey
"pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
$ tail Cyph_Bot_test.decrypt.eml
Message-id: 

It is either a bug in the man page or a bug in the code. In either case it
should be addressed.

P.S. This is how the CMS message in question was created:
$ openssl cms -engine pkcs11 -encrypt -aes256 -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
engine "pkcs11" set.
$ tail Cyph_Bot_test.smime.eml
p7qKV4ttuid/6ynNbobYNgSUenzrmnbO0Z03KhglAy1l/om4crfK3+5r2UJ+5daf
9kL1EUrVy6flhE198793YTZJngi3zKFYk+BY2K8wNzLEoXAfJSY6a9z8RINZW9n8


-- 
Regards,
Uri Blumenthal




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

Please add a blank line after the “+over” around line 39 in
doc/crypto/BIO_set_callback.pod
-- 
Regards,
Uri Blumenthal


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Error is a pod file

[Blumenthal, Uri - 0553 - MITLL]

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

-- 
Regards,
Uri Blumenthal


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 6/20/16, 17:12 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>> Defensive programming is about handling gracefully the cases when the
>> user/caller does something he “is not supposed to do”.
>
>There is a limit.

True.

>Should we return an error code that will most likely be ignored?

Yes, as long as you don’t crash...

>Should the C library be defensive about fprintf, strcpy, etc., etc.?

Heck, yes! There are reasons why sane programmers don’t use strcpy()
nowadays. ;)

>>Software that relies on its users doing only the right things…? Really?
>
>OpenSSL *is not* going to check for NULL parameters where you don't
>supply them.  

Is the interface partitioned that well? Perhaps it’s my ignorance, but I
didn’t think so.

>It never has (not universally) and it never will.  If you want another
>language... .:)

;-)


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 6/20/16, 16:48 , "openssl-dev on behalf of Rich Salz via RT"
 wrote:

>You are not supposed to pass NULL into OpenSSL API's. Just like doing
>this will
>cause a crash strcpy(NULL, "hello”) in a C program.

Defensive programming is about handling gracefully the cases when the
user/caller does something he “is not supposed to do”.

I don’t know if this is an exploitable bug, nor do I care to craft a
threat model to assess how bad it could be - but this whole approach
doesn’t sound endearing to me. Software that relies on its users doing
only the right things…? Really?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 6/16/16, 15:02 , "openssl-dev on behalf of Richard Levitte"
<openssl-dev-boun...@openssl.org on behalf of levi...@openssl.org> wrote:

>In message <d3886b43.2dd2e%...@ll.mit.edu> on Thu, 16 Jun 2016 18:42:17
>+0000, "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> said:
>uri> /bin/sh:
>uri> 
>/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html:
>uri> Too many levels of symbolic links
>uri> make: *** [install_html_docs] Error 1
>
>I suggest you do this first:
>
>rm -rf /Users/ur20980/src/openssl-1.1/share/doc/openssl
>
>There's a bit of documentation restructuring going on, so you probably
>have old clutter that disturbs the process.

You nailed it. Thank you!



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

link 
/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5_Final.html
-> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5.html
MD5_Final.html => MD5.html
install ./doc/crypto/MDC2_Init.pod ->
/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html
/bin/sh: 
/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html:
Too many levels of symbolic links
make: *** [install_html_docs] Error 1

-- 
Regards,
Uri Blumenthal


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

On 6/3/16, 13:23 , "openssl-dev on behalf of Dan Kegel via RT"
 wrote:

>1.02 then.  (0.9.8 is fine.  I'm ok with 1.0.0/1.0.1 remaining broken.)

I compiled your death program, and confirm that it does abort on 1.0.2h.
So presumably no fix is necessary there:

$clang -I/opt/local/include -o t t.c -L/opt/local/lib -lssl -lcrypto
$ ./t
Abort trap: 6



>On Fri, Jun 3, 2016 at 10:08 AM, Rich Salz via RT  wrote:
>> Sorry, but 0.9.8 and 1.0.0 are end of life and getting no updates and
>>1.0.1 is
>> only getting security fixes at this time.
>>
>> --
>> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4559
>> Please log in as guest with password guest if prompted


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

Manual page for “openssl cms” says:

If the -decrypt option is used without a recipient certificate then an
attempt is made
to locate the recipient by trying each potential recipient in turn using
the supplied
private key. 

To thwart the MMA attack (Bleichenbacher's 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.


The first paragraph does not seem to be true - from what I observed, when
no recipient is specified, the decryption always fails - in contradiction
to the above.

This is how I created an encrypted SMIME:

$ openssl version
OpenSSL 1.0.2h  3 May 2016
$ openssl cms -encrypt -aes256 -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


Decryption with explicitly specified -recip works:

$ openssl cms -engine pkcs11 -keyform engine -decrypt -aes256 -inform
SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out
Cyph_Bot_test.decrypt.eml -recip ~/Documents/Certs/me_mouse_yubi_9d_.pem
-inkey "pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
$ tail Cyph_Bot_test.decrypt.eml
Message-id: 
Date: Sun, 02 Jun 2013 00:56:22 -0400
To: Cloud Mouse 
MIME-version: 1.0 (1.0)
X-Mailer: iPad Mail (10B329)

4DFJ3ECyu3XQmJJtPTXp1HJXeCSFnmL8euXcOSc1NGmDm9fqgR0RU+s0Rl1oggUJ

But the same decryption fails when -recip is omitted:


$ openssl cms -engine pkcs11 -keyform engine -decrypt -aes256 -inform
SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out
Cyph_Bot_test.decrypt1.eml -inkey
"pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
Error decrypting CMS structure
140735083847760:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:
$


Adding -debug_decrypt flag reveals the problem:

$ openssl cms -engine pkcs11 -keyform engine -decrypt -debug_decrypt
-aes256 -inform SMIME -in Cyph_Bot_test.smime.eml -outform SMIME -out
Cyph_Bot_test.decrypt1.eml -inkey
"pkcs11:object=KEY%20MAN%20key;object-type=private"
engine "pkcs11" set.
PKCS#11 token PIN:
Error decrypting CMS using private key
140735083847760:error:2E072084:CMS routines:CMS_decrypt_set1_pkey:no
matching recipient:cms_smime.c:661:
$


Either the decryptor fails to properly determine the match (and should be
fixed), or the documentation is wrong (ad should be edited).
-- 
Regards,
Uri Blumenthal


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

>>On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL
>><u...@ll.mit.edu> wrote:
>> 
>>> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif
>>>there is no subjectAltName extension and iif the CN is a valid
>>>dNSNa/iPAddress syntactically.
>> 
>> That approach seems wrong.
>
>Could you explain your point in more detail than putting "wrong"
>in bold text? Though ad-hoc, it seems about the best one can do,
>absent additional information.

IMHO allowing CN to be interpreted as a DNS name would open a new attack
surface by making more name collisions (between people and host names)
possible.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

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 problem seems to be related to this code in pk7_lib.c:

533:if (!pkey || !pkey->ameth || !pkey->ameth->pkey_ctrl) {
534: PKCS7err(PKCS7_F_PKCS7_RECIP_INFO_SET,
535:  PKCS7_R_ENCRYPTION_NOT_SUPPORTED_FOR_THIS_KEY_TYPE);
536: goto err;
537:}
538:
539:ret = pkey->ameth->pkey_ctrl(pkey, ASN1_PKEY_CTRL_PKCS7_ENCRYPT,
0, p7i);
540:if (ret == -2) {
541: PKCS7err(PKCS7_F_PKCS7_RECIP_INFO_SET,
542: PKCS7_R_ENCRYPTION_NOT_SUPPORTED_FOR_THIS_KEY_TYPE);
543: goto err;
544:}


Note: EC keys cannot “encrypt” - they can only “derive”.
-- 
Regards,
Uri Blumenthal


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL via RT]

>> What other implementations, and what did they do?  Always treating a CN as a
>> DNS name?  We can't.
> 
> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there
> is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress
> syntactically.

That approach seems wrong.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Blumenthal, Uri - 0553 - MITLL]

>> What other implementations, and what did they do?  Always treating a CN as a
>> DNS name?  We can't.
> 
> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there
> is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress
> syntactically.

That approach seems wrong.




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Current Github build fails

[Blumenthal, Uri - 0553 - MITLL]

$ ./Configure darwin64-x86_64-cc threads shared zlib
enable-ec_nistp_64_gcc_128 enable-rfc3779
--prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/openssl-1.1/etc
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
no-asan [default]  OPENSSL_NO_ASAN (skip dir)
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG (skip dir)
no-crypto-mdebug-backtrace [forced]
OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE (skip dir)
no-egd  [default]  OPENSSL_NO_EGD (skip dir)
no-fuzz [default]  OPENSSL_NO_FUZZ (skip dir)
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP (skip dir)
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE (skip dir)
no-ssl3 [default]  OPENSSL_NO_SSL3 (skip dir)
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD (skip dir)
no-ubsan[default]  OPENSSL_NO_UBSAN (skip dir)
no-unit-test[default]  OPENSSL_NO_UNIT_TEST (skip dir)
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib-dynamic [default]
Configuring for darwin64-x86_64-cc
CC=clang
CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall
SHARED_CFLAG  =-fPIC
DEFINES   =ZLIB DSO_DLFCN HAVE_DLFCN_H NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT
OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM
MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG =
PLIB_LFLAG=-Wl,-search_paths_first
EX_LIBS   =-lz 
APPS_OBJ  =
CPUID_OBJ =x86_64cpuid.o
UPLINK_OBJ=
BN_ASM=asm/x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC  =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC=chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ=
PROCESSOR =
RANLIB=ranlib -c
ARFLAGS   =
PERL  =/opt/local/bin/perl5.22


SIXTY_FOUR_BIT_LONG mode


Configured for darwin64-x86_64-cc.
$ make depend && make clean && make all && make test && make install
rm -f libcrypto.1.1.dylib
rm -f libcrypto.dylib
rm -f libssl.1.1.dylib
rm -f libssl.dylib
rm -f libcrypto.a libssl.a
rm -f apps/openssl test/aborttest test/afalgtest test/asynciotest
test/asynctest test/bftest test/bntest test/casttest test/cipherlist_test
test/clienthellotest test/constant_time_test test/ct_test test/d2i_test
test/danetest test/destest test/dhtest test/dsatest test/dtlsv1listentest
test/ecdhtest test/ecdsatest test/ectest test/enginetest
test/evp_extra_test test/evp_test test/exptest test/gmdifftest
test/heartbeat_test test/hmactest test/ideatest test/igetest test/md2test
test/md4test test/md5test test/mdc2test test/memleaktest test/nptest
test/p5_crpt2_test test/packettest test/pbelutest test/randtest
test/rc2test test/rc4test test/rc5test test/rmdtest test/rsa_test
test/secmemtest test/sha1test test/sha256t test/sha512t test/srptest
test/ssl_test test/ssl_test_ctx_test test/ssltest_old test/threadstest
test/v3nametest test/verify_extra_test test/wp_test test/x509aux
engines/capi.dylib engines/dasync.dylib engines/ossltest.dylib
engines/padlock.dylib apps/CA.pl apps/tsget tools/c_rehash
rm -f crypto/aes/aesni-sha1-x86_64.s crypto/modes/ghash-x86_64.s
crypto/aes/aes-x86_64.s crypto/camellia/cmll-x86_64.s
crypto/bn/rsaz-avx2.s crypto/sha/sha256-mb-x86_64.s crypto/x86_64cpuid.s
crypto/md5/md5-x86_64.s crypto/rc4/rc4-md5-x86_64.s
crypto/chacha/chacha-x86_64.s crypto/aes/bsaes-x86_64.s
crypto/whrlpool/wp-x86_64.s crypto/rc4/rc4-x86_64.s
crypto/sha/sha256-x86_64.s crypto/aes/aesni-mb-x86_64.s
crypto/aes/aesni-x86_64.s crypto/sha/sha512-x86_64.s
crypto/aes/vpaes-x86_64.s engines/e_padlock-x86_64.s
crypto/bn/x86_64-mont5.s crypto/poly1305/poly1305-x86_64.s
crypto/sha/sha1-mb-x86_64.s crypto/bn/x86_64-mont.s
crypto/bn/x86_64-gf2m.s crypto/ec/ecp_nistz256-x86_64.s
crypto/sha/sha1-x86_64.s crypto/modes/aesni-gcm-x86_64.s
crypto/aes/aesni-sha256-x86_64.s crypto/bn/rsaz-x86_64.s
include/openssl/opensslconf.h crypto/include/internal/bn_conf.h
crypto/include/internal/dso_conf.h crypto/buildinf.h
rm -f `find . -name '*.d'`
rm -f `find . -name '*.o'`
rm -f core
rm -f tags TAGS
rm -f openssl.pc libcrypto.pc libssl.pc
rm -f `find . -type l -a \! -path 

Re: [openssl-dev] [openssl.org #1518] [PATCH] Securing private RSA keys

[Blumenthal, Uri - 0553 - MITLL]

I think the goal of this ticket can be better addressed by using a
hardware token (that cost ballpark $40 retail) and libp11 (aka pkcs11
engine). Similar results with much better security.
-- 
Regards,
Uri Blumenthal





On 5/18/16, 6:31 , "openssl-dev on behalf of Matt Caswell via RT"
 wrote:

>After 9 years looks like there is no support for this patch (and it will
>not
>apply now anyway). I'd suggest if anyone does support this then a new
>patch be
>submitted via GitHub.
>
>Closing this ticket.
>
>Matt
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1518
>Please log in as guest with password guest if prompted
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Blumenthal, Uri - 0553 - MITLL]

On 4/26/16, 15:15 , "openssl-dev on behalf of Viktor Dukhovni"

wrote:

>On Tue, Apr 26, 2016 at 12:55:28PM -0500, Douglas E Engert wrote:
>> Adding the test "if (n != rsa->n)" before the BN_free in the
>>RSA_set0_key
>> would catch this.
>
>The correct test is to return an error in that case, not to skip
>the free.  The caller is doing the wrong thing, and we should not
>silently ignore the mistake.

I’m very certain that this test should be done.

What’s the correct behavior if/when the caller is “caught” doing the wrong
thing - I leave to you guys to decide, as your experience and
understanding of these API is better than mine.

>There may be other pointers that the caller does not own that he
>might be tempted to pass into these functions, say get0 the data
>from one RSA object and attempt to set0 the same parameters on
>another.

I hear you… :-(

>The only systemic fix is much more complex.  We'd need to manage
>and set "library-owned" boolean fields in all the structures returned
>by get0 functions and refuse to accept these in "set0" functions.
>
>Thus a new() constructor would produce a caller owned structure,
>as would a get1() accessor, but a get0() access would return a
>library owned structure, which would be unsuitable for a set0()
>call that takes ownership.

Right now get0() returns a library-owned structure. But there isn’t a
get1() accessor (unless I’m too tired to search correctly :).

>Implementing this pattern would be a major overhaul of the library.

I hear you.

>For now, yes we could detect just one class of mistake, but I
>don't think we should "correct" the mistake, rather we should
>report it as such to the caller.

I think that detecting just one class of mistake makes one mistake class
less to worry about. So it would be great to catch at least this one class
for now.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Blumenthal, Uri - 0553 - MITLL]

On 4/26/16, 14:20 , "openssl-dev on behalf of Salz, Rich"
 wrote:

>> Look. If Doug noticed this, programmers less intimate with this API are
>>much
>> more likely to get stung by it. The protection against such a
>>misunderstanding
>> is cheap.
>
>Is it?  

I think it is. See Doug’s post.


>And what is that protection?

Checking whether (n, e) passed are pointing at rsa’s own, and not freeing
them if they do. See Doug’s posting for the details.


> Without introducing memory leaks.

It certainly does not look like this check would introduce any memory
leaks, while on the other hand it would prevent a few crashes. If you
think otherwise - would you care to illustrate?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Blumenthal, Uri - 0553 - MITLL]

On 4/26/16, 14:03 , "openssl-dev on behalf of Salz, Rich via RT"
 wrote:

>That code is still wrong.  Once you "get0" something you can only look at
>it.  You cannot pass it off to a "set0" function.  Get0 gives you a
>pointer that *you do not own* and *set0* takes a pointer that you DO own
>and are giving away.

On the other hand, it seems all to easy (IMHO) for a programmer to think
“I got it from OpenSSL, and I’m passing it back…"

>You can't give away something that isn't yours :)

Funny, most of the governments I know of do this quite successfully and at
quite a large scale. For a long time too. :)


>The error is thinking that "my_e" is yours; it's not.  As documented.

Look. If Doug noticed this, programmers less intimate with this API are
much more likely to get stung by it. The protection against such a
misunderstanding is cheap. There is no justification for refusing to put
this defense in. Insulate the wires instead of saying “I told him not to
touch those wires”.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Blumenthal, Uri - 0553 - MITLL]

On 4/26/16, 13:56 , "openssl-dev on behalf of Douglas E Engert"
 wrote:

>...
>RSA_get0_key(rsa, _n, _e, NULL); /* note this is a GET0 */
>
>/* my_n now points to the BIGNUM as does rsa->n */
>/* my_e now points to the BIGNUM as does rsa->e */
>
>/* other stuff done, such as calculating d */
>
>RSA_set0_key(rsa, my_n, my_e, d);
>
>/* RSA_set0_key does not check if my_n == rsa->n
>It frees rsa->n and replaces it with my_n which is is pointing at the
>freed  location */

After all the discussion that occurred here, I think that the problem Doug
is pointing at should be fixed, and the solution he recommends should be
put in.


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Blumenthal, Uri - 0553 - MITLL]

On 4/26/16, 11:43 , "openssl-dev on behalf of Tomas Mraz"
 wrote:

>On Út, 2016-04-26 at 10:16 -0500, Douglas E Engert wrote:
>> Let me update my response.
>> If I am reading GH#995 correctly it still has an issue if a user
>> does:
>> 
>> RSA_get0_key(rsa, n, e, NULL); /* note this is a GET0 */
>> /* other stuff done, such as calculating d */
>> RSA_set0_key(rsa, n, e, d);
>> 
>> rsa is left with n and e pointing to unallocated storage.
>
>This is programmer error in your code because the RSA_get0_key is
>documented to just return internal data and must not be freed. Thus
>you're not allowed to pass the returned values to RSA_set0_key().

May I suggest that this (obvious to you) text be added to the manual page
for both _get0_key() and _set0_key()? [Yes it would be redundant, but IMHO
better than allowing a harried programmer making a silly mistake “because
he should’ve known better".]


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Blumenthal, Uri - 0553 - MITLL]

On 4/26/16, 11:21 , "openssl-dev on behalf of Salz, Rich via RT"
 wrote:

>> RSA_get0_key(rsa, n, e, NULL); /* note this is a GET0 */
>> /* other stuff done, such as calculating d */
>>RSA_set0_key(rsa, n, e, d);
>> 
>> rsa is left with n and e pointing to unallocated storage.
>
>That code is incorrect.

Would you mind giving more explanation please?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev