[openssl-dev] Current Github master fails to compile/link

./Configure darwin64-x86_64-cc enable-rfc3779 enable-rc5 enable-md2 enable-deprecated experimental-jpake threads zlib enable-ec_nistp_64_gcc_128 shared --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/engines-1.1 … LD_LIBRARY_PATH=.: clang -DDSO_DLFCN -DHAVE_DLFCN_H -DOPEN

Re: [openssl-dev] Current Github master fails to compile/link

On 2/11/16, 16:16 , "openssl-dev on behalf of Salz, Rich" wrote: >Yes, fixed now. I confirm the fix. 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 #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"? Clearly the device manufacturer is at fault here, but the punished party is the user - probably not what w

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

v@openssl.org Cc: Stephen Henson via RT; bcri...@gmail.com Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails toparse x509 certificate in DER format‎ On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > Might I suggest that the right th

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

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

Re: [openssl-dev] ECDH engine

rg‎ >> Reply To: openssl-dev@openssl.org >> Subject: Re: [openssl-dev] ECDH engine >> ‎ >> You are missing the point. OpenSSL-1.0.2 only exposed ECDSA, not ECDH to >> external engines. It took years to even get ECDSA exposed. >> OpenSSL approach to support this is

Re: [openssl-dev] ECDH engine

d, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL > wrote: >>> When I started to write the ECDSA code for engine_pkcs11 in 2011 the code >>> to support the method hooks was not >>> in the code. So I used internal OpenSSL header files to copy the >>&g

Re: [openssl-dev] Ubsec and Chil engines

+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

[openssl-dev] openssl-1.1 started looking for engines using wrong names

In short, after commits done in the last few days, openssl-1.1 stopped looking for lib.so, and started looking for .so. I think it’s an introduced bug that needs to be fixed: $ ~/src/openssl-1.1/bin/openssl engine pkcs11 -t 140735268914000:error:25066067:DSO support routines:dlfcn_load:could not

Re: [openssl-dev] Ubsec and Chil engines

On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse" wrote: >>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 open

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

If somebody (Mik, 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 On 2/20/16, 9:10 , "openssl-dev on behalf of Salz, Ri

Re: [openssl-dev] Ubsec and Chil engines

>>> Agreed. With the caveat that I *really* want libp11 and engine_pkcs11 >> > to die, and be replaced by native code in openssl/crypto/pkcs11/ >> >> Would you mind explaining what you mean by “native code” that presumably >> could replace the current libp11, and who in your opinion would support

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

>>> Nonsense. Source code is not API documentation, it is an >> > implementation, not an interface contract. >> >> I'm not sure I'd consider it nonsense. > >Comments in source code are not documentation, they explain the >internals of the implementation, not the contract. Actually they can (and

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

$ ./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

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

Re: [openssl-dev] cipher order

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 h

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

$ ./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/r

Re: [openssl-dev] MacOS defaults?

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]

Re: [openssl-dev] MacOS defaults?

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 run

Re: [openssl-dev] MacOS defaults?

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

Re: [openssl-dev] MacOS defaults?

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

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

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

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

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

$ ./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 (0x0x101

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

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

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

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 Descr

[openssl-dev] Record of configuration parameters?

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

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

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

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

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 configura

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

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=. op

[openssl-dev] CRYPTO_lock definition gone?

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]

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

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

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" wrote: >On Mon, Mar 14, 2016 at 03:28:13PM +0000, Blumenthal, Uri - 0553 - MITLL >wrote: >> install ./doc/crypto/EVP_PKEY_set1_RSA.p

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

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 su

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

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

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

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

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

for OpenSSL to incorporate proper support for PKCS#11. -- Regards, Uri Blumenthal On 3/14/16, 17:08, "David Woodhouse" wrote: >On Mon, 2016-03-14 at 19:27 +, Blumenthal, Uri - 0553 - MITLL >wrote: >> $ openssl cms -engine pkcs11 -aes256 -encrypt -binary -in data.txt

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

On 3/14/16, 17:33, "David Woodhouse" 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 cm

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

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

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

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 inv

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

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.

[openssl-dev] Missing blake2_locl.h?

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 -

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

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

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

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

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

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

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

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

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

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 ranli

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

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

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

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

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

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

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

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 incor

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

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

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

On 4/26/16, 13:56 , "openssl-dev on behalf of Douglas E Engert" wrote: >... >RSA_get0_key(rsa, &my_n, &my_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 */

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

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 ar

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

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 w

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

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

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

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

[openssl-dev] Current Github build fails

$ ./Configure darwin64-x86_64-cc threads shared zlib enable-ec_nistp_64_gcc_128 enable-rfc3779 --prefix=/Users/ur20980/src/openssl-1.1 --openssldir=/Users/ur20980/src/openssl-1.1/etc Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) no-asan [default] OPENSSL_NO_ASAN (skip dir)

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

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

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

Does OpenSSL support ECC-based S/MIME as defined in RFC 5753? I was trying to create an encrypted S/MIME message using OpenSSL-1.0.2h, and got the following: $ openssl smime -encrypt -aes128 -inform SMIME -in Cyph_Bot_test.eml -outform SMIME -out Cyph_Bot_test.smime.eml -subject SMIME_ECC ~/Docum

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

>>On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL >> wrote: >> >>> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif >>>there is no subjectAltName extension and iif the CN is a valid >>>dNSNa/iPAddress syntactically. &

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

Manual page for “openssl cms” says: If the -decrypt option is used without a recipient certificate then an attempt is made to locate the recipient by trying each potential recipient in turn using the supplied private key. To thwart the MMA attack (Bleichenbacher's

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

On 6/3/16, 13:23 , "openssl-dev on behalf of Dan Kegel via RT" wrote: >1.02 then. (0.9.8 is fine. I'm ok with 1.0.0/1.0.1 remaining broken.) I compiled your death program, and confirm that it does abort on 1.0.2h. So presumably no fix is necessary there: $clang -I/opt/local/include -o t t.c -

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

link /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5_Final.html -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MD5.html MD5_Final.html => MD5.html install ./doc/crypto/MDC2_Init.pod -> /Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Init.html /bin/sh:

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

On 6/16/16, 15:02 , "openssl-dev on behalf of Richard Levitte" wrote: >In message on Thu, 16 Jun 2016 18:42:17 >+0000, "Blumenthal, Uri - 0553 - MITLL" said: >uri> /bin/sh: >uri> >/Users/ur20980/src/openssl-1.1/share/doc/openssl/html/man3/MDC2_Ini

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

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 som

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

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,

[openssl-dev] Error is a pod file

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

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

Please add a blank line after the “+over” around line 39 in doc/crypto/BIO_set_callback.pod -- Regards, Uri Blumenthal smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

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

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

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 no

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

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,

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

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" wrote: >On Fri, Aug 26, 2016 at 5:11 PM, Blumenthal, Uri - 0553 -

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

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 ver

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

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

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

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,

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

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   Fr

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

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

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

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 (0x1010

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

>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

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

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

> 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

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

On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" wrote: > One of the principle problems of using TPM based keys is that there's > no easy way of integrating them with standard file based keys. Why should token- and/or TPM-based keys be integrated with file-based keys?

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

>> So why is it better to say “…engine –key /some/weird/path/weird >> -file.pem” than “…engine –key pkcs11:id=02” (or such)? > > There appears to be some confusion here. pkcs11 is a representation > for defined tokens. Well, I did not mean *specifically* pkcs11 – just as an e

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

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" wrote: On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote: > > The problem is in t

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

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 so

Re: [openssl-dev] License change agreement

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

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:48A

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

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

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

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

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

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

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

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

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

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

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

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

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

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 wrote: Todd> Yes, it’s likely this is due to the amoun

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

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

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

@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 >> wrote: >> >> My disk is SSD, but computer load is pretty high. Which probably explains >> that recovery

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

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

  1   2   3   >