Re: [openssl-dev] Ubsec and Chil engines

2016-02-19 Thread 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

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

2016-02-12 Thread 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

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

2016-03-09 Thread 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

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

2016-03-09 Thread 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

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

2016-03-14 Thread 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 ->

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

2016-03-14 Thread 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,

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

2016-03-15 Thread 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

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

2016-03-15 Thread 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

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

2016-03-14 Thread 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

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

2016-03-14 Thread 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] openssl cms unable to access keys on token?

2016-03-14 Thread 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

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

2016-03-14 Thread Blumenthal, Uri - 0553 - MITLL
porate 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 dat

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

2016-03-09 Thread 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

[openssl-dev] Record of configuration parameters?

2016-03-09 Thread 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

[openssl-dev] CRYPTO_lock definition gone?

2016-03-11 Thread 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]

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

2016-03-15 Thread 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

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

2016-03-14 Thread 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: >

Re: [openssl-dev] [openssl.org #4290] HMAC_Init_ex() return bug

2016-04-05 Thread Blumenthal, Uri - 0553 - MITLL
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 wishe

Re: [openssl-dev] [openssl.org #4471] 1.1.0-pre4 safestack.h compilation errors with -Wcast-qual

2016-03-22 Thread 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

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

2016-03-25 Thread 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 :

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

2016-03-21 Thread 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

[openssl-dev] Missing blake2_locl.h?

2016-03-21 Thread 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

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

2016-03-21 Thread Blumenthal, Uri - 0553 - MITLL
ling, 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 wit

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

2016-03-24 Thread 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:

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

2016-03-08 Thread 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

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

2016-03-08 Thread 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

[openssl-dev] current github 1.1.0-pre "clang: error: unsupported option '--unified'

2016-03-08 Thread 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

Re: [openssl-dev] MacOS defaults?

2016-03-06 Thread 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]

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

2016-03-02 Thread 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

Re: [openssl-dev] cipher order

2016-03-03 Thread 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

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

2016-03-03 Thread 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 . . . . . .

Re: [openssl-dev] cipher order

2016-03-03 Thread 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.

Re: [openssl-dev] MacOS defaults?

2016-03-07 Thread 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

Re: [openssl-dev] MacOS defaults?

2016-03-07 Thread 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.

Re: [openssl-dev] MacOS defaults?

2016-03-07 Thread 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

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

2016-03-07 Thread 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

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

2016-03-08 Thread 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.

[openssl-dev] Installation fails

2016-04-01 Thread 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

[openssl-dev] FW: Current Github build broken (crypto/comp/c_zlib.c:334:25: error: variable has incomplete type 'const BIO_METHOD')

2016-03-29 Thread 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

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

2016-04-25 Thread 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

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

2016-04-26 Thread 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]

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

2016-04-26 Thread 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

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

2016-04-26 Thread 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

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

2016-04-26 Thread 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 >>

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

2016-04-26 Thread 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: >>

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

2016-04-26 Thread 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

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

2016-04-26 Thread 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 >>

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

2016-05-18 Thread 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"

[openssl-dev] Error is a pod file

2016-07-14 Thread 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: ***

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

2016-07-25 Thread 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

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

2016-07-19 Thread 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?

2016-08-04 Thread 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

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

2016-06-20 Thread 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

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

2016-06-20 Thread 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

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

2016-09-16 Thread 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

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

2016-08-26 Thread 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

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

2016-08-26 Thread Blumenthal, Uri - 0553 - MITLL
e: >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 sugg

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

2016-11-28 Thread 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

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

2016-11-28 Thread 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

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

2016-11-28 Thread 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

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

2016-11-22 Thread 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

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

2016-11-16 Thread 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"

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

2016-11-16 Thread 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,

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

2016-11-21 Thread 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  

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

2017-01-10 Thread 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

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

2016-11-30 Thread 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

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

2016-11-30 Thread 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

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

2016-11-30 Thread 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, Ur

Re: [openssl-dev] License change agreement

2017-03-23 Thread 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

Re: [openssl-dev] License change agreement

2017-03-24 Thread Blumenthal, Uri - 0553 - MITLL
> >>> 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: >>>>>&

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

2017-04-13 Thread 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

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

2017-04-13 Thread 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> >

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

2017-04-13 Thread 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

[openssl-dev] Current master fails to build

2017-08-03 Thread 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

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

2017-08-03 Thread 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

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

2017-08-14 Thread 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

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

2017-08-14 Thread 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,

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

2017-08-14 Thread 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?

[openssl-dev] Master: test fails

2017-07-21 Thread 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

Re: [openssl-dev] Master: test fails

2017-07-22 Thread 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,

Re: [openssl-dev] Master: test fails

2017-07-23 Thread 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

Re: [openssl-dev] Master: test fails

2017-07-24 Thread 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

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

2017-06-29 Thread 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.

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

2017-06-28 Thread 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

Re: [openssl-dev] Build issue

2017-07-27 Thread 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

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

2017-08-18 Thread 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

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

2017-08-19 Thread 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

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

2017-08-17 Thread 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 >

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

2017-05-15 Thread Blumenthal, Uri - 0553 - MITLL
n 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,

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

2017-05-15 Thread Blumenthal, Uri - 0553 - MITLL
; -- > -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.

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

2017-05-15 Thread 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

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

2017-05-15 Thread Blumenthal, Uri - 0553 - MITLL
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

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

2017-05-12 Thread 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. ;-)

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

2017-05-12 Thread 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

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

2017-05-12 Thread 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,

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

2017-06-26 Thread 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.

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

2017-06-26 Thread 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%

[openssl-dev] Bug: digest parameter is rejected

2017-09-18 Thread 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

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

2017-09-18 Thread 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

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

2017-08-29 Thread 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:

<    1   2   3   >