Re: [openssl-dev] Ubsec and Chil engines

[Blumenthal, Uri - 0553 - MITLL]

+1. 

With one exception: engine_pkcs11 has been subsumed (and merged into) libp11.

I've tested it with a few different PIV tokens (RSA and ECC), and it was great.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Nikos Mavrogiannopoulos
Sent: Friday, February 19, 2016 09:53
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Ubsec and Chil engines

On Fri, 2016-02-19 at 13:12 +, Matt Caswell wrote:

> As far as I know there are some customers using the Chil engine
> > with
> > RHEL (openssl-1.0.1). 
> 
> How do you feel about the engine being spun out into a separate repo?
> That of course assumes that a volunteer can be found to maintain it
> (I
> don't believe anyone on the dev team wishes to do so).
> 
> If no such volunteer can be found how big a deal is it to remove it
> from
> 1.1.0 without a replacement? Obviously it won't be taken out of
> 1.0.1/1.0.2. Of course there's no reason, even if we take it out now,
> that if someone needs it badly enough in the future that they
> couldn't forward port the 1.0.2 version to 1.1.0 and maintain it
> themselves at that point.

It may even be better, instead of pushing for different engines for
different hardware, to make PKCS#11 the only API used to talk to
hardware. There is a quite functional (and active as project) pkcs11
engine for openssl [0].

regards,
Nikos

[0]. https://github.com/OpenSC/engine_pkcs11

-- 
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] 3DES is a HIGH-strength cipher?

[Blumenthal, Uri - 0553 - MITLL]

> So, if it’s “mandatory”, then it should be in the default set of ciphers, not
> necessarily the “HIGH” set.
> 
> I’m selecting “HIGH” because I want 128-bit+ ciphers, not a cipher that that
> has subsequently found to be weaker than previously thought.

I used to think that MTI doesn’t mean “Mandatory To Offer”. My codebase must
have it, but my server (and/or client) configuration may explicitly forbid
it. Is there anything wrong with this view?



> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
> 
>> On Feb 12, 2016, at 3:36 PM, Viktor Dukhovni 
>> wrote:
>> 
>> 
>>> On Feb 12, 2016, at 3:15 PM, Salz, Rich  wrote:
>>> 
>>> So is RC4 and we don't see that as HIGH. HIGH implies strength, not
>>> MTI-ness.
>> 
>> Now let's not make stuff up:
>> 
>> http://tools.ietf.org/html/rfc5246#section-9
>> 
>> 9.  Mandatory Cipher Suites
>> 
>>   In the absence of an application profile standard specifying
>>   otherwise, a TLS-compliant application MUST implement the cipher
>>   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5  for the
>>   definition).
>> 
>> http://tools.ietf.org/html/rfc4346#section-9
>> 
>> 9. Mandatory Cipher Suites
>> 
>>   In the absence of an application profile standard specifying
>>   otherwise, a TLS compliant application MUST implement the cipher
>>   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
>> 
>> http://tools.ietf.org/html/rfc2246#section-9
>> 
>> 9. Mandatory Cipher Suites
>> 
>>   In the absence of an application profile standard specifying
>>   otherwise, a TLS compliant application MUST implement the cipher
>>   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
>> 
>> Since many users enable just HIGH ciphers, they must not exclude the MTI
>> ciphers.
>> 
>> -- 
>> -- 
>> Viktor.
>> 
>> -- 
>> 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] Errors when loading an OpenSSL RSA Engine

[Blumenthal, Uri - 0553 - MITLL]

> Relating to the MD5 Engine, I tryed to build the git version
>   manually with these
> commands:
> $ gcc -fPIC -o rfc1321/md5c.o -c rfc1321/md5c.c
> $ gcc -fPIC -o md5-engine.o -c e_md5.c
> $ gcc -shared -o md5-engine.so -lcrypto md5-engine.o rfc1321/md5c.o
> ... and it failed when I tried to load the engine, but using the autotools and
> a few modifications it worked.

When I try autotools, I get this:

git clone https://github.com/engine-corner/Lesson-2-A-digest.git

Cloning into 'Lesson-2-A-digest'...

remote: Counting objects: 21, done.

remote: Total 21 (delta 0), reused 0 (delta 0), pack-reused 21

Unpacking objects: 100% (21/21), done.

Checking connectivity... done.

$ cd Lesson-2-A-digest/

$ autoreconf -i

aclocal: warning: couldn't open directory 'm4': No such file or directory

glibtoolize: putting auxiliary files in '.'.

glibtoolize: copying file './ltmain.sh'

glibtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.

glibtoolize: copying file 'm4/libtool.m4'

glibtoolize: copying file 'm4/ltoptions.m4'

glibtoolize: copying file 'm4/ltsugar.m4'

glibtoolize: copying file 'm4/ltversion.m4'

glibtoolize: copying file 'm4/lt~obsolete.m4'

configure.ac:18: error: possibly undefined macro: AC_MSG_FAILURE

  If this token and others are legitimate, please use m4_pattern_allow.

  See the Autoconf documentation.

autoreconf: /opt/local/bin/autoconf failed with exit status: 1

$ 


You probably want to post (a) the modifications you made to
autotools-whatever, and (b) the resulting compile and link commands.






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

Re: [openssl-dev] Record of configuration parameters?

[Blumenthal, Uri - 0553 - MITLL]

I like very much what you suggested!

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Salz, Rich
Sent: Wednesday, March 9, 2016 12:02
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Record of configuration parameters?

> In the master branch, the best is to look in configdata.pm.
> perlargv => [ "linux-x86_64", "-Wa,--noexecstack" ],

Perhaps configdata.pm should have a comment like
"# configured with ...args...
At the top, to make it stand out?

Or maybe even the command line to reproduce the config?
-- 
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] 1.1-pre4 documentation fails to install

[Blumenthal, Uri - 0553 - MITLL]

Current Github version:


EVP_PKEY_print_public.3 => EVP_PKEY_print_private.3

link /Users/ur20980/share/man/man3/EVP_PKEY_print_params.3 -> 
/Users/ur20980/share/man/man3/EVP_PKEY_print_private.3

EVP_PKEY_print_params.3 => EVP_PKEY_print_private.3

install ./doc/crypto/EVP_PKEY_set1_RSA.pod -> 
/Users/ur20980/share/man/man3/EVP_PKEY_set1_RSA.3

IO::File=IO(0x7feb8c8029c0) around line 62: Unterminated B<...> sequence

POD document had syntax errors at /opt/local/bin/pod2man line 68.

make: *** [install_man_docs] Error 1

--
Regards,
Uri Blumenthal
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 1.1-pre4 documentation fails to install

[Blumenthal, Uri - 0553 - MITLL]

Yes, that diff fixes the problem, thank you! (Hope to see it in Github :)

On 3/14/16, 11:45, "openssl-dev on behalf of Viktor Dukhovni"
<openssl-dev-boun...@openssl.org on behalf of openssl-us...@dukhovni.org>
wrote:

>On Mon, Mar 14, 2016 at 03:28:13PM +0000, Blumenthal, Uri - 0553 - MITLL
>wrote:
>> install ./doc/crypto/EVP_PKEY_set1_RSA.pod ->
>>/Users/ur20980/share/man/man3/EVP_PKEY_set1_RSA.3
>> 
>> IO::File=IO(0x7feb8c8029c0) around line 62: Unterminated B<...> sequence
>> POD document had syntax errors at /opt/local/bin/pod2man line 68.
>
>Try:
>
>diff --git a/doc/crypto/EVP_PKEY_set1_RSA.pod
>b/doc/crypto/EVP_PKEY_set1_RSA.pod
>index de31bc1..c7fd8e9 100644
>--- a/doc/crypto/EVP_PKEY_set1_RSA.pod
>+++ b/doc/crypto/EVP_PKEY_set1_RSA.pod
>@@ -62,7 +62,7 @@ an RSA key will return B.
> EVP_PKEY_id() returns the actual OID associated with B.
>Historically keys
> using the same algorithm could use different OIDs. For example an RSA
>key could
> use the OIDs corresponding to the NIDs B (equivalent
>to
>-B<EVP_PKEY_RSA) or B (equivalent to B). The use
>of
>+B) or B (equivalent to B). The use
>of
> alternative non-standard OIDs is now rare so B et al are
>not
> often seen in practice.

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

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

[Blumenthal, Uri - 0553 - MITLL]

On 3/15/16, 15:29 , "openssl-dev on behalf of Viktor Dukhovni"

wrote:

>These days, most people recommend encrypt then sign.  CMS and S/MIME
>natively support sign-then-encrypt, but encapsulating encrypted
>content as signed content as above also works.

Please excuse my ignorance - how do you invoke “openssl cms” to accomplish
native “sign-then-encrypt” (which in some cases is still OK)?


>>The only problem - now I have one test failing:
>> 
>> ../test/recipes/80-test_ca.t .. ok
>> ../test/recipes/80-test_cms.t . 2/4
>
>The CMS tests pass when I run them:
>
>$ HARNESS_VERBOSE=yes make TESTS=test_cms test
>( cd test;  SRCTOP=../.  BLDTOP=../.  EXE_EXT=  /usr/pkg/bin/perl
>.././test/run_tests.pl test_cms )
>../test/recipes/80-test_cms.t ..

Alas, for some reason does not work here:

../test/recipes/80-test_ca.t .. ok
../test/recipes/80-test_cms.t .
#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients'
#   at ../test/recipes/80-test_cms.t line 376.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, 3rd used'
#   at ../test/recipes/80-test_cms.t line 376.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, key only used'
#   at ../test/recipes/80-test_cms.t line 376.

#   Failed test 'enveloped content test streaming S/MIME format,
AES-256 cipher, 3 recipients'
#   at ../test/recipes/80-test_cms.t line 376.
# Looks like you failed 4 tests of 15.
../test/recipes/80-test_cms.t . 1/4
#   Failed test 'CMS => PKCS\#7 compatibility tests
# '
#   at ../test/recipes/80-test_cms.t line 381.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients'
#   at ../test/recipes/80-test_cms.t line 391.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, 3rd used'
#   at ../test/recipes/80-test_cms.t line 391.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, key only used'
#   at ../test/recipes/80-test_cms.t line 391.

#   Failed test 'enveloped content test streaming S/MIME format,
AES-256 cipher, 3 recipients'
#   at ../test/recipes/80-test_cms.t line 391.
# Looks like you failed 4 tests of 15.
../test/recipes/80-test_cms.t . 2/4
#   Failed test 'CMS <= PKCS\#7 compatibility tests
# '
#   at ../test/recipes/80-test_cms.t line 396.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients'
#   at ../test/recipes/80-test_cms.t line 407.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, 3rd used'
#   at ../test/recipes/80-test_cms.t line 407.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, key only used'
#   at ../test/recipes/80-test_cms.t line 407.

#   Failed test 'enveloped content test streaming S/MIME format,
AES-256 cipher, 3 recipients'
#   at ../test/recipes/80-test_cms.t line 407.

#   Failed test 'enveloped content test streaming S/MIME format, 3
recipients, keyid'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'enveloped content test streaming PEM format, KEK'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'enveloped content test streaming PEM format, KEK, key
only'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'encrypted content test streaming PEM format, 128 bit
RC2 key'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'encrypted content test streaming PEM format, 40 bit
RC2 key'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'encrypted content test streaming PEM format, triple
DES key'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'encrypted content test streaming PEM format, 128 bit
AES key'
#   at ../test/recipes/80-test_cms.t line 418.
# Looks like you failed 11 tests of 27.
../test/recipes/80-test_cms.t . 3/4
#   Failed test 'CMS <=> CMS consistency tests
# '
#   at ../test/recipes/80-test_cms.t line 423.

#   Failed test 'enveloped content test streaming S/MIME format, OAEP
default parameters'
#   at ../test/recipes/80-test_cms.t line 435.

#   Failed test 'enveloped content test streaming S/MIME format, OAEP
SHA256'
#   at ../test/recipes/80-test_cms.t line 435.

#   Failed test 'enveloped content test streaming S/MIME format, ECDH'
#   at ../test/recipes/80-test_cms.t line 435.

#   Failed test 'enveloped content test streaming S/MIME format, ECDH,
key identifier'
#   at ../test/recipes/80-test_cms.t line 435.

#   Failed test 'enveloped content test streaming S/MIME format, ECDH,
AES128, SHA256 KDF'
#   at 

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

[Blumenthal, Uri - 0553 - MITLL]

My apologies - it appears that the patch was screwed up on my system. When
I just replaced the EVP_CIPHER_asn1_to_param() with your new code, the
tests passed OK.

. . . . . . 
../test/recipes/70-test_verify_extra.t  ok
../test/recipes/80-test_ca.t .. ok
../test/recipes/80-test_cms.t . ok
../test/recipes/80-test_ct.t .. ok
../test/recipes/80-test_dane.t  ok
../test/recipes/80-test_dtlsv1listen.t  ok
../test/recipes/80-test_ocsp.t  ok
../test/recipes/80-test_ssl.t . ok
../test/recipes/80-test_tsa.t . ok
../test/recipes/90-test_async.t ... ok
../test/recipes/90-test_constant_time.t ... ok
../test/recipes/90-test_gmdiff.t .. ok
../test/recipes/90-test_heartbeat.t ... skipped: heartbeats is not
supported by this OpenSSL build
../test/recipes/90-test_ige.t . ok
../test/recipes/90-test_memleak.t . ok
../test/recipes/90-test_networking.t .. ok
../test/recipes/90-test_np.t .. ok
../test/recipes/90-test_p5_crpt2.t  ok
../test/recipes/90-test_secmem.t .. ok
../test/recipes/90-test_srp.t . ok
../test/recipes/90-test_threads.t . ok
../test/recipes/90-test_v3name.t .. ok
All tests successful.
Files=71, Tests=394, 53 wallclock secs ( 0.51 usr  0.17 sys + 32.96 cusr
15.10 csys = 48.74 CPU)
Result: PASS
$ 


-- 
Regards,
Uri Blumenthal





On 3/15/16, 15:54 , "openssl-dev on behalf of Viktor Dukhovni"

wrote:

>On Tue, Mar 15, 2016 at 07:29:04PM +, Viktor Dukhovni wrote:
>
>> ok 24 - encrypted content test streaming PEM format, 128 bit RC2 key
>> ok 25 - encrypted content test streaming PEM format, 40 bit RC2 key
>
>The underlying test commands amount to:
>
> $ cd test
> $ openssl cms -EncryptedData_encrypt -in smcont.txt -outform PEM -rc2
>-secretkey 000102030405060708090A0B0C0D0E0F -stream -out test.cms
> $ openssl cms -EncryptedData_decrypt -in test.cms -inform PEM -secretkey
>000102030405060708090A0B0C0D0E0F -out smtst.txt
>
>For me these succeed and result in smtst.txt identical to smcont.txt.
>
>-- 
>   Viktor.
>-- 
>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 #4429] Cannot decrypt RC4-encrypted CMS object

[Blumenthal, Uri - 0553 - MITLL]

On 3/14/16, 14:45, "openssl-dev on behalf of Viktor Dukhovni"

wrote:

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

Is there any reason why stream ciphers are not supported with CMS?

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

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

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

[Blumenthal, Uri - 0553 - MITLL]

In that bug description I see a reference to code in “enc.c” that aborts
if the cipher is AEAD or XTS (and an offer to submit PR that hasn’t
materialized so far).

Would you be able to elaborate why those checks that forbid AEAD were put
in?
--
Regards,
Uri Blumenthal




On 3/14/16, 15:09, "openssl-dev on behalf of Salz, Rich"
 wrote:

>> Is there any reason why stream ciphers are not supported with CMS?
>
>Go ask CMS folks? :)
> 
>> Along the same line, is there any reason why AE(AD) ciphers are not
>> supported with “openssl enc”?
>
>A known bug.  https://rt.openssl.org/Ticket/Display.html?id=4228 user
>guess / pass guest if needed.
>
>-- 
>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] openssl cms unable to access keys on token?

[Blumenthal, Uri - 0553 - MITLL]

$ openssl cms -engine pkcs11 -aes256 -encrypt -binary -in data.txt -outform 
engine "pkcs11:object=KEY%20MAN%20pubkey;object-type=public"

engine "pkcs11" set.

Error opening recipient certificate file 
pkcs11:object=KEY%20MAN%20pubkey;object-type=public

140735201178448:error:02001002:system library:fopen:No such file or 
directory:bss_file.c:398:fopen('pkcs11:object=KEY%20MAN%20pubkey;object-type=public','r')

140735201178448:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:

unable to load certificate

$ openssl cms -engine pkcs11 -aes256 -encrypt -binary -in data.txt -outform 
engine 
"pkcs11:object=Certificate%20for%20Key%20Management;object-type=certificate"

engine "pkcs11" set.

Error opening recipient certificate file 
pkcs11:object=Certificate%20for%20Key%20Management;object-type=certificate

140735201178448:error:02001002:system library:fopen:No such file or 
directory:bss_file.c:398:fopen('pkcs11:object=Certificate%20for%20Key%20Management;object-type=certificate','r')

140735201178448:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:

unable to load certificate

$ openssl cms -engine pkcs11 -aes256 -encrypt -binary -in data.txt -outform 
engine "pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert"

engine "pkcs11" set.

Error opening recipient certificate file 
pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert

140735201178448:error:02001002:system library:fopen:No such file or 
directory:bss_file.c:398:fopen('pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert','r')

140735201178448:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:

unable to load certificate

$

--
Regards,
Uri Blumenthal
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] openssl cms unable to access keys on token?

[Blumenthal, Uri - 0553 - MITLL]

You are right - the command line was wrong. Here’s the correct line, which
should work, but doesn’t:

$ openssl cms -engine pkcs11 -aes256 -encrypt -in data.txt -binary
-outform PEM -out data.txt.enc
"pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert"
engine "pkcs11" set.
Error opening recipient certificate file
pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert
140735201178448:error:02001002:system library:fopen:No such file or
directory:bss_file.c:398:fopen('pkcs11:object=Certificate%20for%20Key%20Man
agement;object-type=cert','r')
140735201178448:error:20074002:BIO routines:FILE_CTRL:system
lib:bss_file.c:400:
unable to load certificate
$ openssl cms -engine pkcs11 -aes256 -encrypt -in data.txt -binary
-outform PEM -out data.txt.enc token.cert.pem
engine "pkcs11" set.
$




And yes, it’s about time for OpenSSL to incorporate proper support for
PKCS#11.
--
Regards,
Uri Blumenthal




On 3/14/16, 17:08, "David Woodhouse" <dw...@infradead.org> wrote:

>On Mon, 2016-03-14 at 19:27 +, Blumenthal, Uri - 0553 - MITLL
>wrote:
>> $ openssl cms -engine pkcs11 -aes256 -encrypt -binary -in data.txt
>> -outform engine "pkcs11:object=KEY%20MAN%20pubkey;object-type=public"
>
>That isn't what -outform does. It controls the output format of the
>encrypted result:
>
>$ openssl cms -aes256 -encrypt -binary -in data.txt -outform PEM cert.pem
>-BEGIN CMS-
>MIICIgYJKoZIhvcNAQcDoIICEzCCAg8CAQAxggHKMIIBxgIBADCBrTCBpzELMAkG
>...
>
>There is no option which makes it obtain the *certificate* (to which it
>is encrypting the CMS message) from an engine. There isn't even a
>standard way for an engine to provide such functionality — the PKCS#11
>engine currently exposes it only with a custom "LOAD_CERT_CTRL"
>command.
>
>This is just one of many reasons why libp11/engine_pkcs11 needs to die
>as a separate project, and we need to incorporate proper PKCS#11
>support into OpenSSL natively.
>
>-- 
>David WoodhouseOpen Source Technology Centre
>david.woodho...@intel.com  Intel Corporation
>


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

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

[Blumenthal, Uri - 0553 - MITLL]

On 3/9/16, 12:57 , "openssl-dev on behalf of danigrosu"
 wrote:

>In git version, if I comment the block...

I found that was not necessary. But autotools setup did not work (see my
previous post in this thread). Perhaps Richard could shed some light on
that.

$ echo whatever | OPENSSL_ENGINES=. openssl dgst -md5 -engine emd5
engine "emd5" set.
(stdin)= d8d77109f4a24efc3bd53d7cabb7ee35
$


Regarding RSA-X engine, it lacks the dynamic binding code necessary for
being loaded, etc. That’s why it fails to load. Check the contents of
e_md5.c and eng_rsax.c for differences.

$ OPENSSL_ENGINES=. openssl engine -t -c rsax
(rsax) RSAX engine support
 [RSA]
 [ available ]
$ 





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

[openssl-dev] Record of configuration parameters?

[Blumenthal, Uri - 0553 - MITLL]

Say, one configures an openssl build with parameters:

./Configure darwin-whatever —prefix=/whereever enable-this enable-that …etc

My question is – if after the fact I need to check what parameters exactly
were passed to the configuration command, how can I do it? With “normal”
autotools, there’s a record preserved in the “config.log” file. Is there an
analog of that here?

Thanks!
-- 
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] CRYPTO_lock definition gone?

[Blumenthal, Uri - 0553 - MITLL]

In a commit done in the last two days, definition of CRYPTO_lock() seems to
have disappeared or moved. As a result, libp11 cannot compile on
openssl-1.1-pre4:

p11_cert.c:50:3: warning: implicit declaration of function 'CRYPTO_lock' is
invalid in C99 [-Wimplicit-function-declaration]

pkcs11_w_lock(cpriv->lockid);

^

./libp11-int.h:142:11: note: expanded from macro 'pkcs11_w_lock'

if(type) 
CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)

 ^

p11_cert.c:50:3: error: use of undeclared identifier 'CRYPTO_LOCK'

./libp11-int.h:142:23: note: expanded from macro 'pkcs11_w_lock'

if(type) 
CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)

 ^

p11_cert.c:50:3: error: use of undeclared identifier 'CRYPTO_WRITE'

./libp11-int.h:142:35: note: expanded from macro 'pkcs11_w_lock'

if(type) 
CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)

 ^

p11_cert.c:52:3: error: use of undeclared identifier 'CRYPTO_UNLOCK'

pkcs11_w_unlock(cpriv->lockid);

^

./libp11-int.h:144:23: note: expanded from macro 'pkcs11_w_unlock'

if(type) 
CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)

 ^

p11_cert.c:52:3: error: use of undeclared identifier 'CRYPTO_WRITE'

./libp11-int.h:144:37: note: expanded from macro 'pkcs11_w_unlock'

if(type) 
CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)

   ^

1 warning and 4 errors generated.

make[2]: *** [libp11_la-p11_cert.lo] 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 #4429] Cannot decrypt RC4-encrypted CMS object

[Blumenthal, Uri - 0553 - MITLL]

First of all - thank you! It is great to see useful capabilities added (I
consider stream ciphers and AEAD modes very useful :). I fully agree that
unsigned CMS is an invitation to trouble. If I understand correctly, the
intended openssl use is “openssl cms -encrypt … | openssl cms -sign …” (or
the other way around :).

$ ./util/shlib_wrap.sh ./apps/openssl req -config apps/openssl.cnf -new
-x509 -newkey rsa:2048 -keyout key.pem -nodes -out cert.pem -days 100
-subj "/CN=RC4 CMS Test"
Generating a 2048 bit RSA private key
..+++
.+++
writing new private key to 'key.pem'
-
$ ./util/shlib_wrap.sh ./apps/openssl x509 -in cert.pem -noout -serial
serial=B83C7468CCE8930E
$ echo sesame > data.txt
$ ./util/shlib_wrap.sh ./apps/openssl cms -rc4 -encrypt -binary -in
data.txt -out data.txt.cms -outform DER cert.pem
$ ./util/shlib_wrap.sh ./apps/openssl cms -decrypt -in data.txt.cms
-inform DER -out data2.txt -inkey key.pem -recip cert.pem
$ diff -u data.txt data2.txt
$ openssl asn1parse -inform DER -in data.txt.cms
0:d=0  hl=4 l= 380 cons: SEQUENCE
4:d=1  hl=2 l=   9 prim: OBJECT:pkcs7-envelopedData
   15:d=1  hl=4 l= 365 cons: cont [ 0 ]
. . . . . . . 
   90:d=5  hl=4 l= 256 prim: OCTET STRING  [HEX
DUMP]:362DC32CD6520D3765255D9549BEC058766499C0581430E84929419730B08C31C6E78
D22CB8D8C026EEB75203D19148C97F8F73C7066D158E6E85FEA41972B50EB245ACB15C23209
7DD3046901882B95C9AD102F8E34E0E049B4A374F1EF61C48E1F90F95A3F8E2306161AF0882
99F7A4949D706FBF6A92DB8BB5DF293E1B3BA135BAA8E63FE94C0BBD7A29D31AD28E9137D66
41CF7490257BEE23161A478B6FCBDEE05B1578592272335713196C3F26139A41B76A3EA1371
FA875A4DD09C150D4674AF7A399F886A09D245EE1A81AEC8A96B4647C712D366A0FBC7964FE
C6EF69A076CB58A81ED8DBD466FAA1E9CD072C8242B5D68F3CDB95C5CF04AFE71795
  350:d=3  hl=2 l=  32 cons: SEQUENCE
  352:d=4  hl=2 l=   9 prim: OBJECT:pkcs7-data
  363:d=4  hl=2 l=  10 cons: SEQUENCE
  365:d=5  hl=2 l=   8 prim: OBJECT:rc4
  375:d=4  hl=2 l=   7 prim: cont [ 0 ]
$



The only problem - now I have one test failing:


../test/recipes/80-test_ca.t .. ok
../test/recipes/80-test_cms.t . 2/4
#   Failed test 'encrypted content test streaming PEM format, 128 bit
RC2 key'
#   at ../test/recipes/80-test_cms.t line 418.

#   Failed test 'encrypted content test streaming PEM format, 40 bit
RC2 key'
#   at ../test/recipes/80-test_cms.t line 418.
# Looks like you failed 2 tests of 27.
../test/recipes/80-test_cms.t . 3/4
#   Failed test 'CMS <=> CMS consistency tests
# '
#   at ../test/recipes/80-test_cms.t line 423.
../test/recipes/80-test_cms.t . 4/4 # Looks like you failed 1
test of 4.
../test/recipes/80-test_cms.t . Dubious, test returned 1
(wstat 256, 0x100)
Failed 1/4 subtests
../test/recipes/80-test_ct.t .. Ok




I wonder how difficult would it be to add AEAD support, considering that
they (usually) can take 96-bit nonce (treated as IV), and the
authentication tag often is just appended to the ciphertext (and expected
at the end of the ciphertext during decryption).
-- 
Regards,
Uri Blumenthal





On 3/15/16, 3:47 , "openssl-dev on behalf of Viktor Dukhovni"

wrote:

>On Tue, Mar 15, 2016 at 06:33:32AM +, Viktor Dukhovni wrote:
>
>> This is completely untested, may not even compile!  Enjoy.
>
>It does seem to work, so one key remaining questions is whether it
>is interoperable:
>
>$ ./util/shlib_wrap.sh ./apps/openssl req -config apps/openssl.cnf
>-new -x509 -newkey rsa:2048 -keyout key.pem -nodes -out cert.pem -days
>100 -subj "/CN=RC4 CMS Test"
>
>$ ./util/shlib_wrap.sh ./apps/openssl x509 -in cert.pem -noout -serial
>serial=ACD5DEDE758B9AA6
>$ echo sesame > data.txt
>$ ./util/shlib_wrap.sh ./apps/openssl cms -rc4 -encrypt -binary -in
>data.txt -out data.txt.cms -outform DER cert.pem
>$ ./util/shlib_wrap.sh ./apps/openssl cms -decrypt -in data.txt.cms
>-inform DER -out data2.txt -inkey key.pem -recip cert.pem
>$ diff -u data.txt data2.txt
>
>$ openssl asn1parse -inform DER -in data.txt.cms
>   0:d=0  hl=4 l= 380 cons: SEQUENCE
>   4:d=1  hl=2 l=   9 prim: OBJECT:pkcs7-envelopedData
>   15:d=1  hl=4 l= 365 cons: cont [ 0 ]
>   19:d=2  hl=4 l= 361 cons: SEQUENCE
>   23:d=3  hl=2 l=   1 prim: INTEGER   :00
>   26:d=3  hl=4 l= 320 cons: SET
>   30:d=4  hl=4 l= 316 cons: SEQUENCE
>   34:d=5  hl=2 l=   1 prim: INTEGER   :00
>   37:d=5  hl=2 l=  36 cons: SEQUENCE
>   39:d=6  hl=2 l=  23 cons: SEQUENCE
>   41:d=7  hl=2 l=  21 cons: SET
>   43:d=8  hl=2 l=  19 cons: SEQUENCE
>   45:d=9  hl=2 l=   3 prim: OBJECT:commonName
>   50:d=9  hl=2 l=  12 prim: UTF8STRING:RC4 CMS Test
>   64:d=6  hl=2 l=   9 prim: INTEGER   :ACD5DEDE758B9AA6
>   75:d=5  hl=2 l=  13 

Re: [openssl-dev] openssl cms unable to access keys on token?

[Blumenthal, Uri - 0553 - MITLL]

On 3/14/16, 17:33, "David Woodhouse" <dw...@infradead.org> wrote:

>On Mon, 2016-03-14 at 21:28 +0000, Blumenthal, Uri - 0553 - MITLL
>wrote:
>> You are right - the command line was wrong. Here’s the correct line,
>> which
>> should work, but doesn’t:
>> 
>> $ openssl cms -engine pkcs11 -aes256 -encrypt -in data.txt -binary
>> -outform PEM -out data.txt.enc
>> "pkcs11:object=Certificate%20for%20Key%20Management;object-type=cert"
>
>Yeah, that won't work either.

Yep…

>Perhaps you need the "-certform engine" option.
>
>Which doesn't exist. :)

I’d personally prefer the cms app to have internal logic “if -engine is
specified and the cert name starts with ‘pksc11:’ then load it via
engine”. It’s been suggested in another forum that perhaps openssl should
automatically load the appropriate engine if the resource (key || pubkey
|| cert) is specified via URI that starts with the engine name (like
“pkcs11:”).

Does it mean I need to come up with a PR? :-)

>(My mailer doesn't seem to trust your signing cert, btw. Should you be
>including an intermediate certificate in your messages? For that
>matter, should I? :)

Yours appear OK. Perhaps because I know StartCom. ;)

I’ll send you mine.


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 #4290] HMAC_Init_ex() return bug

[Blumenthal, Uri - 0553 - MITLL]

I had the same (good) results on El Capitan 10.11.4 (and before than on
10.11.3), Xcode-7.3, and Openssl-1.0.2g (and Openssl-1.0.2h-dev).

With some modifications (changing the calls to the 1.1 standard so it can
compile :) it also produced the expected (correct) results with
OpenSSL-1.1.0-pre5.

Again, Mac OS X 10.10.5 and 10.11.4, Xcode-7.2.1 and Xcode-7.3, OpenSSL
branches 1.0.2g, 1.0.2h-dev, 1.1.0-pre…

$ cat openssl-hmac-tst.c

#include 
#include 

void test_hmac() {

#if OPENSSL_VERSION_NUMBER >= 0x1011L
   HMAC_CTX *ctx;
#else
   HMAC_CTX ctx;
#endif /* OPENSSL-1.1 */

  
   uint8_t key[32] = {0xDC, 0xFB, 0x59, 0x40, 0x73, 0x32, 0xF0, 0x46,
0x1F, 0xC4, 0xF9, 0xE0, 0xEF, 0x15, 0x62, 0xB5, 0xC9, 0x9F, 0xE4, 0xD3,
0x36, 0xDB, 0x9D, 0x61, 0xE0, 0x31, 0xA5, 0x6E, 0xD0, 0x79, 0xD7, 0x15};

#if OPENSSL_VERSION_NUMBER >= 0x1011L
   ctx = HMAC_CTX_new();
#else
   HMAC_CTX_init();
#endif /* OPENSSL-1.1 */

#if OPENSSL_VERSION_NUMBER >= 0x1011L
   int thor = HMAC_Init_ex(ctx, , 32, EVP_sha256(), NULL);
#else
   int thor = HMAC_Init_ex(, , 32, EVP_sha256(), NULL);
#endif /* OPENSSL-1.1 */
  
   printf("hmac init = %d\n", thor);

#if OPENSSL_VERSION_NUMBER >= 0x1011L
   HMAC_CTX_free(ctx);
#else
   HMAC_CTX_cleanup();
#endif /* OPENSSL-1.1 */
  
}

int main(int argc, char **argv) {
   test_hmac();
}

$ clang -o openssl-hmac-tst-1.1 -I/Users/ur20980/src/openssl-1.1/include
openssl-hmac-tst.c -L /Users/ur20980/src/openssl-1.1/lib -lcrypto
$ clang -o openssl-hmac-tst -I /opt/local/include openssl-hmac-tst.c -L
/opt/local/lib -lcrypto
$ ./openssl-hmac-tst
hmac init = 1
$ ./openssl-hmac-tst-1.1
hmac init = 1
$ otool -L openssl-hmac-tst
openssl-hmac-tst:
/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)
$ otool -L openssl-hmac-tst-1.1
openssl-hmac-tst-1.1:
/Users/ur20980/src/openssl-1.1/lib/libcrypto.1.1.dylib (compatibility
version 1.1.0, current version 1.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1213.0.0)
$ 


-- 
Regards,
Uri Blumenthal


From:  Uri Blumenthal <u...@ll.mit.edu>
Date:  Thursday, March 24, 2016 at 15:10
To:  viisakas <mikkrat...@gmail.com>
Subject:  Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug


>Sorry for my laziness/busy-ness – but I don’t experience the problem you
>described (on Yosemite). I will test on El Capitan (Mac OS X 10.11.4,
>Xcode-7.3) later today.
>
>Mac OS X 10.10.5, Xcode-7.2.1:
>
>$ cat openssl-hmac-tst.c
>#include 
>#include 
>
>void test_hmac() {
>HMAC_CTX ctx;
>uint8_t key[32] = {0xDC, 0xFB, 0x59, 0x40, 0x73, 0x32, 0xF0, 0x46,
>0x1F, 0xC4, 0xF9, 0xE0, 0xEF, 0x15, 0x62, 0xB5, 0xC9, 0x9F, 0xE4, 0xD3,
>0x36, 0xDB, 0x9D, 0x61, 0xE0, 0x31, 0xA5, 0x6E, 0xD0, 0x79, 0xD7, 0x15};
>
>HMAC_CTX_init();
>
>int thor = HMAC_Init_ex(, , 32, EVP_sha256(), NULL);
>
>printf("hmac init = %d\n", thor);
>
>HMAC_CTX_cleanup();
>}
>
>int main(int argc, char **argv) {
>  test_hmac();
>}
>$ clang -I/opt/local/include -o openssl-hmac-tst openssl-hmac-tst.c
>-L/opt/local/lib -lcrypto
>$ ./openssl-hmac-tst
>hmac init = 1
>$ ./openssl-hmac-tst
>hmac init = 1
>$ ./openssl-hmac-tst
>hmac init = 1
>$ ./openssl-hmac-tst
>hmac init = 1
>$ openssl version
>OpenSSL 1.0.2h-dev  xx XXX 
>$
>
>-- 
>Regards,
>Uri Blumenthal
>
>From:  viisakas <mikkrat...@gmail.com>
>Date:  Tuesday, February 23, 2016 at 3:48
>To:  Uri Blumenthal <u...@ll.mit.edu>
>Subject:  Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug
>
>>Hey,
>>
>>sorry for the laziness.
>>This is with 1.0.2f, on OS X 10.11.3.
>>
>>void test_hmac() {
>>HMAC_CTX ctx;
>>uint8_t key[32] = {0xDC, 0xFB, 0x59, 0x40, 0x73, 0x32, 0xF0, 0x46,
>>0x1F, 0xC4, 0xF9, 0xE0, 0xEF, 0x15, 0x62, 0xB5, 0xC9, 0x9F, 0xE4, 0xD3,
>>0x36, 0xDB, 0x9D, 0x61, 0xE0, 0x31, 0xA5, 0x6E, 0xD0, 0x79, 0xD7, 0x15};
>>
>>HMAC_CTX_init();
>>
>>int thor = HMAC_Init_ex(, , 32, EVP_sha256(), NULL);
>>
>>printf("hmac init = %d\n", thor);
>>
>>HMAC_CTX_cleanup();
>>}
>>
>>Best of wishes,
>>Mikk Rätsep
>>
>>>On 22 veebr 2016, at 18:42, Blumenthal, Uri - 0553 - MITLL
>>><u...@ll.mit.edu> wrote:
>>> 
>>> If somebody (Mikk, Felipe, you hear? :) cares to send me a *simple*
>>>*short*
>>> code that exposes this problem, I’ll be willing to test it on Linux and
>>> Mac OS X, with OpenSSL-1.0.2f, OpenSSL-1.0.2-stable, and
>>>1.1-pre.
>>> -- 
>>> Regards,
>>> Uri Blumenthal


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 #4471] 1.1.0-pre4 safestack.h compilation errors with -Wcast-qual

[Blumenthal, Uri - 0553 - MITLL]

I don’t seem to be able to replicate with either 1.0.2h-dev, or
1.1.0-pre using clang-3.7 and gcc-5.3 (on Mac OS X 10.10.5).
Here’s 1.1.0-pre output:

$ cat t9.c
#include 

int
main(int argc, char **argv) {
return 0;
}
$ gcc -Wcast-qual -I/Users/ur20980/include -o t9 t9.c -L/Users/ur20980/lib
-lcrypto
$ clang -Wcast-qual -I/Users/ur20980/include -o t9 t9.c
-L/Users/ur20980/lib -lcrypto
$ clang-mp-3.7 -Wcast-qual -I/Users/ur20980/include -o t9 t9.c
-L/Users/ur20980/lib -lcrypto
$


-- 
Regards,
Uri Blumenthal





On 3/22/16, 15:40 , "openssl-dev on behalf of Brian Wellington via RT"
 wrote:

>Attempting to compile this program:
>
>#include 
>
>int
>main(int argc, char **argv) {
>return 0;
>}
>
>with -Wcast-qual (with both gcc and clang) results in errors like this
>(repeated a number of times).
>
>target/include/openssl/safestack.h:214:1: warning: cast from 'const struct
>  stack_st_OPENSSL_STRING *' to 'struct stack_st *' drops const
>qualifier
>  [-Wcast-qual]
>DEFINE_SPECIAL_STACK_OF(OPENSSL_STRING, char)
>^
>target/include/openssl/safestack.h:186:42: note: expanded from macro
>  'DEFINE_SPECIAL_STACK_OF'
># define DEFINE_SPECIAL_STACK_OF(t1, t2) SKM_DEFINE_STACK_OF(t1, t2, t2)
> ^
>target/include/openssl/safestack.h:95:33: note: expanded from macro
>  'SKM_DEFINE_STACK_OF'
>return sk_num((_STACK *)sk); \
>^
>
>This doesn’t happen with 1.0.2g.
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4471
>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 #4477] [PATCH] enc command enhancement and small fixes

[Blumenthal, Uri - 0553 - MITLL]

On 3/25/16, 6:03 , "openssl-dev on behalf of Michel"
 wrote:

>Hi Mr. Blumenthal,
>
>I believed there is someone else who should have almost finished at this
>time :
>https://mta.openssl.org/pipermail/openssl-dev/2016-January/004034.html

Ah, yes. But that person seems to be rather quiet since that post.


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

[openssl-dev] "make depend" is broken in current Github

[Blumenthal, Uri - 0553 - MITLL]

After fixing “blake2_locl.h” (by copying it manually to 
crypto/include/internal), same problem with ct_int.h:


clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -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 -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/Users/ur20980/etc/openssl/\"" 
-DENGINESDIR="\"/Users/ur20980/lib/engines\"" -O3 -D_REENTRANT -arch x86_64 
-DL_ENDIAN -Wall  -fPIC -Iinclude -I. -Icrypto/include -MMD -MF 
crypto/ct/ct_vfy.d.tmp -MT crypto/ct/ct_vfy.o -c -o crypto/ct/ct_vfy.o 
crypto/ct/ct_vfy.c

make: *** No rule to make target `crypto/include/internal/ct_int.h', needed by 
`crypto/ct/ct_x509v3.o'.  Stop.

--
Regards,
Uri Blumenthal
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Missing blake2_locl.h?

[Blumenthal, Uri - 0553 - MITLL]

With the current Github code (1.1-pre…) after ./Configure xxx and “make depend 
&& make clean && make all":


clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -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 -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/Users/ur20980/etc/openssl/\"" 
-DENGINESDIR="\"/Users/ur20980/lib/engines\"" -O3 -D_REENTRANT -arch x86_64 
-DL_ENDIAN -Wall  -fPIC -Iinclude -I. -Icrypto/include -MMD -MF 
crypto/bio/bss_sock.d.tmp -MT crypto/bio/bss_sock.o -c -o crypto/bio/bss_sock.o 
crypto/bio/bss_sock.c

make: *** No rule to make target `crypto/include/internal/blake2_locl.h', 
needed by `crypto/blake2/blake2b.o'.  Stop.

$

--
Regards,
Uri Blumenthal
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] "make depend" is broken in current Github

[Blumenthal, Uri - 0553 - MITLL]

Some header files moved.  Clean and rebuild.

I’ve done it several times (./Configure… then “make depend && make clean && 
make all …” - you know the drill), but after this email it started working. No 
update on git that could claim responsibility for this success. Puzzling, but…

From: Blumenthal, Uri - 0553 - MITLL [mailto:u...@ll.mit.edu]
Sent: Monday, March 21, 2016 9:39 AM
To: openssl-dev
Subject: [openssl-dev] "make depend" is broken in current Github

After fixing “blake2_locl.h” (by copying it manually to 
crypto/include/internal), same problem with ct_int.h:


clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -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 -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/Users/ur20980/etc/openssl/\"" 
-DENGINESDIR="\"/Users/ur20980/lib/engines\"" -O3 -D_REENTRANT -arch x86_64 
-DL_ENDIAN -Wall  -fPIC -Iinclude -I. -Icrypto/include -MMD -MF 
crypto/ct/ct_vfy.d.tmp -MT crypto/ct/ct_vfy.o -c -o crypto/ct/ct_vfy.o 
crypto/ct/ct_vfy.c

make: *** No rule to make target `crypto/include/internal/ct_int.h', needed by 
`crypto/ct/ct_x509v3.o'.  Stop.
--
Regards,
Uri Blumenthal
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4477] [PATCH] enc command enhancement and small fixes

[Blumenthal, Uri - 0553 - MITLL]

Please consider that position vacant! ;)

I've no idea when I manage to get it (AEAD in enc) done, if at all.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Michel via RT
Sent: Thursday, March 24, 2016 19:48
Reply To: r...@openssl.org
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #4477] [PATCH] enc command enhancement  
and small fixes

Hi,



While I was at it (allowing wrap/unwrap mode), I finally decided to remedy
some unnecessary restrictions of the 'enc' command.

The general idea is to allow to decrypt a file using the original passphrase
even when it is not internally salted (hence produced by another software),
in which case the salt must be supplied as an argument (along with the same
iteration count). I also added support for PKCS5 v2.
The previous behavior of the command is not modified.

I didn't work on the AEAD ciphers problem as I know someone else applied for
this job.

Regards,

Michel.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4477
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] Errors when loading an OpenSSL RSA Engine

[Blumenthal, Uri - 0553 - MITLL]

> I'm just trying to implement an RSA engine and I thought that this would be a
> good start.
> I tryed successfully the MD5 Engine
>  ple-md5-engine/>  written by Richard Levitte and my next step is to build an
> RSA engine
> which I will use in my application.

Could you please confirm that you’re doing this on OpenSSL-1.0.2?

> I think my problem is simple and it's just something that I miss.

Frankly, I don’t think so. But let others, who are more experienced, comment
on this.




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

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

[Blumenthal, Uri - 0553 - MITLL]

> I tried your suggestion, but the error still appears.

I’ve observed those errors too.

Am I correct that the interface for the engine changed between 1.0.1 and
1.0.2? That would explain the issues I saw.

Of course, based on the Jeremy’s response, there probably is no need in
RSA-X, so no point trying to get it up and running.




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.0-pre "clang: error: unsupported option '--unified'

[Blumenthal, Uri - 0553 - MITLL]

$ ./Configure darwin64-x86_64-cc enable-rfc3779 threads zlib
enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/openssl-1.1/etc --unified

Smartmatch is experimental at ./Configure line 2144.

Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L)

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-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-static-engine [default]  OPENSSL_NO_STATIC_ENGINE (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

IsMK1MF   =no

CC=clang

CFLAG =-O3 -D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  --unified

DEFINES   =ZLIB DSO_DLFCN HAVE_DLFCN_H 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

PROCESSOR =

RANLIB=ranlib -c

ARFLAGS   =

PERL  =/opt/local/bin/perl5



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/afalgtest test/asynctest test/bftest test/bntest
test/casttest test/clienthellotest test/constant_time_test test/ct_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/ssltest test/threadstest
test/v3nametest test/verify_extra_test test/wp_test

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`

rm -f ../openssl-1.1.0-pre4-dev.tar

clang -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -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 -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-DOPENSSLDIR="\"/Users/ur20980/src/openssl-1.1/etc\""
-DENGINESDIR="\"/Users/ur20980/src/openssl-1.1/lib/engines\"" -O3
-D_REENTRANT -arch x86_64 -DL_ENDIAN -Wall  --unified -fPIC -Iinclude -I.
-Icrypto/include -MMD -MF crypto/aes/aes-x86_64.d.tmp -MT
crypto/aes/aes-x86_64.o -c -o crypto/aes/aes-x86_64.o
crypto/aes/aes-x86_64.s

clang: error: unsupported option '--unified'

make: *** [crypto/aes/aes-x86_64.o] 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] MacOS defaults?

[Blumenthal, Uri - 0553 - MITLL]

Yes I think it's way past time to make this change. 64-bit has been the norm 
for ages.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Ben Laurie
Sent: Sunday, March 6, 2016 06:21
To: OpenSSL development
Reply To: openssl-dev@openssl.org
Subject: [openssl-dev] MacOS defaults?

Currently OpenSSL defaults to 32 bit in MacOS. I'm told it might be better to 
default to 64 bit these days.

Does anyone have any views?




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

[openssl-dev] Test 80 fails in the current 1.1 build

[Blumenthal, Uri - 0553 - MITLL]

$ ./Configure darwin64-x86_64-cc enable-rfc3779 threads zlib
enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/openssl-1.1/etc --unified


../test/recipes/80-test_cms.t . 3/4

#   Failed test 'compressed content test streaming PEM format'

#   at ../test/recipes/80-test_cms.t line 452.

# Looks like you failed 1 test of 11.

../test/recipes/80-test_cms.t . 4/4

#   Failed test 'CMS <=> CMS consistency tests, modified key parameters

# '

#   at ../test/recipes/80-test_cms.t line 458.

# Looks like you failed 1 test of 4.

../test/recipes/80-test_cms.t . Dubious, test returned 1 (wstat
256, 0x100)

Failed 1/4 subtests

../test/recipes/80-test_ct.t .. Ok

. . .

Test Summary Report

---

../test/recipes/80-test_cms.t   (Wstat: 256 Tests: 4 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=70, Tests=389, 65 wallclock secs ( 0.63 usr  0.20 sys + 39.54 cusr
15.73 csys = 56.10 CPU)

Result: FAIL

Failed 1/70 test programs. 1/389 subtests failed.

make: *** [test] Error 255


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

[Blumenthal, Uri - 0553 - MITLL]

+1

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Hanno Böck
Sent: Thursday, March 3, 2016 07:28
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: [openssl-dev] cipher order

Hi,

Last year I proposed to change the ciphering order in OpenSSL to always
prefer AEAD cipher suites before CBC/HMAC-based ones:
https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html

I just checked openssl 1.1.0 alpha and it still orders ciphers in an
imho problematic way.

Browsers have largely decided to implement GCM-modes only with AES128.
Chrome is now about to change that. Not sure if other browsers will
follow.

Right now if you configure a server with openssl's cipher suite
ordering it is likely that a connection will happen with AES256 in CBC
mode instead of the (most likely more secure) AES128 in GCM mode.

Can this be changed before 1.1.0 gets out?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



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

[openssl-dev] 1.1-pre: test 80 fails

[Blumenthal, Uri - 0553 - MITLL]

$ ./Configure darwin64-x86_64-cc enable-rfc3779 threads zlib
enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1
--openssldir=/Users/ur20980/src/openssl-1.1/etc —unified

. . . . . .

$ make depend && make clean && make all && make test && make install

. . . . . . 

../test/recipes/70-test_verify_extra.t  ok

../test/recipes/80-test_ca.t .. ok

../test/recipes/80-test_cms.t . 3/4

#   Failed test 'compressed content test streaming PEM format'

#   at ../test/recipes/80-test_cms.t line 452.

# Looks like you failed 1 test of 11.

../test/recipes/80-test_cms.t . 4/4

#   Failed test 'CMS <=> CMS consistency tests, modified key parameters

# '

#   at ../test/recipes/80-test_cms.t line 458.

# Looks like you failed 1 test of 4.

../test/recipes/80-test_cms.t . Dubious, test returned 1 (wstat
256, 0x100)

Failed 1/4 subtests

../test/recipes/80-test_ct.t .. ok

../test/recipes/80-test_dane.t  ok

. . . . . .



Test Summary Report

---

../test/recipes/80-test_cms.t   (Wstat: 256 Tests: 4 Failed: 1)

  Failed test:  4

  Non-zero exit status: 1

Files=70, Tests=389, 56 wallclock secs ( 0.55 usr  0.16 sys + 35.30 cusr
15.09 csys = 51.10 CPU)

Result: FAIL

Failed 1/70 test programs. 1/389 subtests failed.

make: *** [test] Error 255

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

[Blumenthal, Uri - 0553 - MITLL]

On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck"
 wrote:

>On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper 
>wrote:
>>https://github.com/openssl/openssl/pull/783
>
>This is different from what I had in mind.
>...
>I would argue that cbc/hmac is so fragile that it's always preferrable
>to have aead before cbc/hmac. The security difference between 128 and
>256 bit aes is imho mostly irrelevant in practice.

Again, +1

Perhaps David can do his magic again? :-)


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

Re: [openssl-dev] MacOS defaults?

[Blumenthal, Uri - 0553 - MITLL]

Try 
$ machine

Apparently "arch" is not only old (the latest release was in July 2010), but it 
does not differentiate between Intel-32 and Intel-64. 

On my own Mac (proven to be 64-bit :) arch returns "i386", machine returns 
"x86_64h".

Oh, and do hook up BB-10 to LTE - an absolute must for running 64-bit stuff on 
Macs. :-) :) :)

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Ben Laurie
Sent: Monday, March 7, 2016 04:22
To: OpenSSL development
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] MacOS defaults?

On 6 March 2016 at 22:40, Viktor Dukhovni  wrote:
>
>> On Mar 6, 2016, at 12:00 PM, Ben Laurie  wrote:
>>
>> Hmm. So why do I see this on my macbook?
>>
>> $ arch
>> i386
>
> Try "uname -m"

x86_64

But AIUI, uname -m tells me what hardware I've got, arch tells me what
mode it is running in...
-- 
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] MacOS defaults?

[Blumenthal, Uri - 0553 - MITLL]

On 3/7/16, 11:05 , "openssl-dev on behalf of Andy Polyakov"
 wrote:

>> Try 
>> $ machine
>> 
>> Apparently "arch" is not only old (the latest release was in July
>>2010), but it does not differentiate between Intel-32 and Intel-64.
>> 
>> On my own Mac (proven to be 64-bit :) arch returns "i386", machine
>>returns "x86_64h".
>
>And I get i486 (sic!) on proven to be 64-bit Mac.

Yes another proof that we cannot rely on “arch” on the newer Mac OS X
boxes.

>As already mentioned,
>these things has changed recently (all right, at some point), and for
>this reason something that worked earlier and keeps working in the same
>way should be preferable. Or at least one should account for the fact
>that things has changed.

I agree. But don’t know how to accomplish that.

>What's h after x86_64h anyway?

Sorry, I don’t have the slightest idea. :-(


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

Re: [openssl-dev] MacOS defaults?

[Blumenthal, Uri - 0553 - MITLL]

>>>And I get i486 (sic!) on proven to be 64-bit Mac.
>> 
>> Yes another proof that we cannot rely on “arch” on the newer Mac OS X
>> boxes.
>
>I meant that I get i486 from 'machine’! I.e. what I tried to say all
>along is that one can't trust 'arch' *nor* 'machine' or 'uname -m' to
>identify 64-bit Darwin. Well, if you want something that works even with
>older versions.

OK, your point is taken. But what does tell 64-bit from 32-bit? And how
badly do we need to know for sure?


We were talking about what the *default* should be, not about how to
determine 64-bit from 32-bit beyond any reasonable doubt (I think).

I’d conjecture that the older versions are becoming less and less relevant
as the time goes. So *now* we can (and should) safely set the default to
x86_64 for Darwin, and those still on 32-bit architecture can run
“./Configure whatever”.


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

Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

[Blumenthal, Uri - 0553 - MITLL]

A naïve question.

OpenSSL RSA engine (RSAX) by Intel wants to call function mod_exp_512() that
is defined somewhere else. I checked, and that function is not defined
anywhere in the sources of either OpenSSL-1.0.2h-dev, or OpenSSL-1.1.0-pre.
$ clang -shared -o eng_rsax.so eng_rsax.o -L/opt/local/lib -lcrypto

Undefined symbols for architecture x86_64:

  "_mod_exp_512", referenced from:

  _e_rsax_bn_mod_exp in eng_rsax.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

$ openssl version

OpenSSL 1.0.2h-dev  xx XXX 

$


Does it mean that this method has been deprecated and removed? If so, what
functions should be used instead?

Also, this Intel-optimized engine (from 2010) seems to be geared towards
RSA-1024, which isn’t considered adequate by now. Does it mean this engine
has been deprecated as well, and shouldn’t be used (assuming one can link a
valid shared library, resolving that undefined reference)?  Does the current
OpenSSL RSA code contains optimizations proposed by that engine?

Thanks!

P.S. My OpenSSL-1.0.2h-dev installation was configured for darwin-x86_64-cc,
and seems to function correctly. It also passed all the tests.
-- 
Regards,
Uri Blumenthal

From:  openssl-dev  on behalf of Jeremy
Farrell 
Organization:  Oracle Corporation
Reply-To:  openssl-dev 
Date:  Monday, March 7, 2016 at 13:25
To:  openssl-dev 
Subject:  Re: [openssl-dev] Errors when loading an OpenSSL RSA Engine

> On 07/03/2016 17:56, Richard Levitte wrote:
>> In message <1457369381041-64385.p...@n7.nabble.com>
>>   on Mon, 7 Mar 2016 09:49:41
>> -0700 (MST), danigrosu  
>> said:
>> 
>> dni.grosu> I want to build an OpenSSL RSA engine, starting from this existing
>> dni.grosu> source code file
>> dni.grosu> which is a faster method implemented by Intel. First of all I want
>> to
>> dni.grosu> build this code so I'm using these commands:
>> dni.grosu> 
>> dni.grosu> gcc -fPIC -m64 -o eng_rsax.o -c eng_rsax.c
>> dni.grosu> gcc -shared -o eng_rsax.so -lcrypto eng_rsax.o
>> 
>> You might want to try this:
>> 
>> gcc -shared -o eng_rsax.so eng_rsax.o -lcrypto
>> 
>> When linking, order is important.
> 
> In the spirit of teaching to fish, this could have been discovered by looking
> at the makefiles which build the engine. Those aren't always easy to decipher,
> so an alternative would have been just to build that OpenSSL release and look
> at all the output lines from the build which mention eng_rsax.
> -- 
> J. J. Farrell




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 #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Blumenthal, Uri - 0553 - MITLL]

On 3/8/16, 15:01 , "openssl-dev on behalf of Salz, Rich via RT"
 wrote:

>
>> +   if (dest->mont_data != NULL)
>> +   BN_MONT_CTX_free(dest->mont_data);
>
>Free routines don't need to check for non-NULL.

Yes, don’t *have* to. But does it hurt to check?


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

[openssl-dev] Installation fails

[Blumenthal, Uri - 0553 - MITLL]

Current Github, Mac OS X 10.10.5:

install libcrypto.a -> /Users/ur20980/src/openssl-1.1/lib/libcrypto.a
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(async_null.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(async_win.o) has no
symbols
ranlib: file: /Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(dso_dl.o)
has no symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(dso_openssl.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(dso_vms.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(dso_win32.o) has no
symbols
ranlib: file: /Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(ebcdic.o)
has no symbols
ranlib: file: /Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(e_rc5.o)
has no symbols
ranlib: file: /Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(m_md2.o)
has no symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(rand_egd.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(rand_vms.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(rand_win.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(threads_none.o) has no
symbols
ranlib: file: 
/Users/ur20980/src/openssl-1.1/lib/libcrypto.a.new(threads_win.o) has no
symbols
install libssl.a -> /Users/ur20980/src/openssl-1.1/lib/libssl.a
ranlib: file: /Users/ur20980/src/openssl-1.1/lib/libssl.a.new(ssl_utst.o)
has no symbols
ranlib: file: /Users/ur20980/src/openssl-1.1/lib/libssl.a.new(t1_trce.o)
has no symbols
install libcrypto.1.1.dylib ->
/Users/ur20980/src/openssl-1.1/lib/libcrypto.1.1.dylib
link /Users/ur20980/src/openssl-1.1/lib/libcrypto.dylib ->
/Users/ur20980/src/openssl-1.1/lib/libcrypto.1.1.dylib
install libssl.1.1.dylib ->
/Users/ur20980/src/openssl-1.1/lib/libssl.1.1.dylib
link /Users/ur20980/src/openssl-1.1/lib/libssl.dylib ->
/Users/ur20980/src/openssl-1.1/lib/libssl.1.1.dylib
install libcrypto.pc ->
/Users/ur20980/src/openssl-1.1/lib/pkgconfig/libcrypto.pc
install libssl.pc -> /Users/ur20980/src/openssl-1.1/lib/pkgconfig/libssl.pc
install openssl.pc ->
/Users/ur20980/src/openssl-1.1/lib/pkgconfig/openssl.pc
*** Installing engines
install engines/capi.dylib ->
/Users/ur20980/src/openssl-1.1/lib/engines/capi.dylib
install engines/dasync.dylib ->
/Users/ur20980/src/openssl-1.1/lib/engines/dasync.dylib
install engines/padlock.dylib ->
/Users/ur20980/src/openssl-1.1/lib/engines/padlock.dylib
*** Installing runtime files
: ;
install apps/openssl -> /Users/ur20980/src/openssl-1.1/bin/openssl
install ./tools/c_rehash -> /Users/ur20980/src/openssl-1.1/bin/c_rehash
install ./tools/c_hash -> /Users/ur20980/src/openssl-1.1/etc/misc/c_hash
install ./tools/c_info -> /Users/ur20980/src/openssl-1.1/etc/misc/c_info
install ./tools/c_issuer ->
/Users/ur20980/src/openssl-1.1/etc/misc/c_issuer
install ./tools/c_name -> /Users/ur20980/src/openssl-1.1/etc/misc/c_name
install ./apps/CA.pl -> /Users/ur20980/src/openssl-1.1/etc/misc/CA.pl
install /apps/tsget -> /Users/ur20980/src/openssl-1.1/etc/misc/tsget
cp: /apps/tsget: No such file or directory
make: *** [install_runtime] Error 1
$ 

All the previous steps (configure, make depend, make clean, etc.)
succeeded.
-- 
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] FW: Current Github build broken (crypto/comp/c_zlib.c:334:25: error: variable has incomplete type 'const BIO_METHOD')

[Blumenthal, Uri - 0553 - MITLL]

Mac OS X 10.10.5, Xcode-7.2.1. OpenSSL-1.1.0-pre5

>$ git clone https://github.com/openssl/openssl.git
>Cloning into 'openssl'...
>remote: Counting objects: 193677, done.
>remote: Compressing objects: 100% (127/127), done.
>remote: Total 193677 (delta 54), reused 8 (delta 8), pack-reused 193542
>Receiving objects: 100% (193677/193677), 85.73 MiB | 5.27 MiB/s, done.
>Resolving deltas: 100% (153073/153073), done.
>Checking connectivity... done.
>Checking out files: 100% (2271/2271), done.
>$ cd openssl
>$ ./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-pre5-dev (0x0x1015L)
>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-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-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 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
>
>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/asynctest
>test/bftest test/bntest test/casttest test/clienthellotest
>test/constant_time_test test/ct_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/ssltest test/threadstest test/v3nametest test/verify_extra_test
>test/wp_test engines/capi.dylib engines/dasync.dylib
>engines/ossltest.dylib engines/padlock.dylib apps/CA.pl tools/c_rehash
>rm -f crypto/aes/aesp8-ppc.s crypto/modes/ghash-alpha.s
>crypto/sha/sha256-mips.s crypto/aes/aes-parisc.s crypto/sha/sha256-586.s
>crypto/sha/sha256-sparcv9.s crypto/rc4/rc4-x86_64.s
>crypto/chacha/chacha-ppc.s crypto/chacha/chacha-armv4.s
>crypto/bn/sparcv9a-mont.s crypto/sha/sha512-sparcv9.s
>crypto/sha/sha256-x86_64.s crypto/aes/vpaes-ppc.s
>crypto/sha/sha512-ia64.s crypto/aes/aes-586.s crypto/des/dest4-sparcv9.s
>crypto/bn/rsaz-avx2.s crypto/modes/ghash-parisc.s
>crypto/poly1305/poly1305-x86_64.s crypto/sha/sha256-ia64.s
>crypto/modes/ghash-sparcv9.s crypto/sha/sha1-mips.s
>crypto/modes/ghashv8-armx.s crypto/des/des_enc-sparc.s
>crypto/modes/ghash-ia64.s crypto/sha/sha256-armv8.s
>crypto/aes/aesv8-armx.s crypto/bn/ia64-mont.s crypto/aes/bsaes-armv7.s
>crypto/aes/aes-ppc.s 

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]

>There isn't much difference between this:
>
>RSA_set0_key(rsa, n, NULL, NULL);
>RSA_set0_key(rsa, NULL, e, NULL);
>RSA_set0_key(rsa, NULL, NULL, d);
>
>and something like this:
>
>RSA_set0_n(rsa, n);
>RSA_set0_e(rsa, e);
>RSA_set0_d(rsa, d);

The attractiveness of RSA_set0_key(rsa, n, NULL, NULL); is that you can
provide whatever many (from 1 to 3 :) parameters using the same single
function call, rather than learning three different (albeit quite simple
:) independent functions.

>The only difference is that with the former, you get two-in-one, as it
>also works as a function to set all three numbers in one go.

Yes, but this difference adds convenience, IMHO. My preference is this:
RSA_set0_key(rsa, n, e, d); with any parameter (except for rsa :)
potentially NULL.


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]

IMO, go ahead.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Richard Levitte
Sent: Tuesday, April 26, 2016 07:46
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: 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

In message <571f2941.4040...@openssl.org> on Tue, 26 Apr 2016 09:39:29 +0100, 
Matt Caswell  said:

matt> 
matt> 
matt> On 26/04/16 08:26, Richard Levitte wrote:
matt> > [temporarly taking this thread away from RT]
matt> > 
matt> > Basically, I can see two solutions:
matt> > 
matt> > - Allow calls like RSA_set0_key(rsa, NULL, NULL, d);
matt> > 
matt> > That's what's implemented in GH#995, except it doesn't check if the
matt> > input parameters are NULL before setting the corresponding fields,
matt> > so that call ends up clearing n and e.
matt> > 
matt> > GH#995 could be changed so that any input parameter can be NULL, and
matt> > that the corresponding RSA structure fields are left untouched. The
matt> > consequence is that can never be made NULL. I can live with that,
matt> > as I can't imagine a reason to reset the fields to NULL.
matt> 
matt> IMO this is the way to go. As long as we can't set private key values
matt> without first having set the public key, i.e. we should not be able to
matt> get into an inconsistent state.

I've seen no other opinion, so I went with it. Would you mind having
a look at GH#995? I did a bit of change in the docs, but could need
some help expressing it in a better manner.

Also, I'd like to hear from Douglas and Tomas if these changes found
in said pull request would fit your bill better... basically, it
allows (or should allow, unless I've goofed something up) a call set
like this:

RSA_set0_key(rsa, n, e, NULL);
/* other stuff done, such as calculatig d */
RSA_set0_key(rsa, NULL, NULL, d);

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



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

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

[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

[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

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

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

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

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

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

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

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

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

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

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

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]

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

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]

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

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]

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]

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

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

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

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

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