Re: [openssl-dev] Work on a new RNG for OpenSSL
And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of It is documented in the RAND_add manpage. ➢ 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. And what would be the point? Why should someone trust the documentation, which can get out of date, more than the source? ➢ 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 ;). We aren’t cutting off any avenues of participation. Email discussion and pull requests are always welcome. But yes, the barrier to useful participation is that someone has to first read and understand the source. ➢ 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. I am curious to know your justification for this. It seems to me that if you accept the DRBG document, which we do, then the way we do the seeding is fine. If you don’t accept the document, then modify the source. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>>> Modify the source :) >> >>Very bad answer. > >And also a wrong one. Your application can always call RAND_add(). Sorry for mistake. And this is a very good answer. Perhaps this guidance deserves being documented somewhere besides this mailing list? Something along the lines of “RNG Seed Sources can be set by --with-rand-seed. “os” is the default source. Sources are tried until enough bits of randomness have been collected. If you want to mix data from a particular source into the seed, but don’t want to make that source exclusive – use RAND_add() method.” > This is a mostly volunteer open source project. Yeah, I realize and appreciate that. > We are unlikely to commit to something that requires so much effort I’m not sure I agree here. What effort are you talking about? In order to select an order in which available sources are queried, the developers had to think (hopefully :). Those thought could be documented in a few lines of text. > when, frankly, most of the consumers aren’t interested, or qualified, to make > an assessment. So they’ll be happy with the default. Fine with me. ;-) > I am sorry if that sounds obnoxious or conceited. It shouldn’t; there are > many things that I know I’m not qualified to comment on :) And also, we > reserve the right to make changes. No offense taken. But you “freeze” interface to and behavior of ciphers and cipher modes, for example. This (how you seed RNG that provides keys to those) is at least equally important. It’s not a minute detail that nobody should care about or nose in. So while the team clearly has the right to make changes (especially before the interface became public ;), but I’d rather that such changes are guided by an informed consent from the public (such as yours truly ;). > I expect that the FIPS project, just starting, will be of interest to you. Thank you – indeed it is of interest. (Though I see FIPS more as a curse than as a blessing ;-). One important thing I missed earlier: > We also added a separate global DRBG for private key generation and added > API’s to use it. > This object isn’t reachable directly, but it is used by the new BN_priv_rand > and BN_priv_rand_range API’s. > Those API’s, in turn, are used by all private-key generating functions. I think it is *imperative* for a user to be able to RAND_add() to the DRBG that gnerates private keys. I cannot emphasize enough how critical this is. smime.p7s Description: S/MIME cryptographic signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>>> 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. And also a wrong one. Your application can always call RAND_add(). Sorry for mistake. > 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. This is a mostly volunteer open source project. We are unlikely to commit to something that requires so much effort when, frankly, most of the consumers aren’t interested, or qualified, to make an assessment. 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. I expect that the FIPS project, just starting, will be of interest to you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
>> 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
> 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”. 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. >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. > 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 :) For a few reasons, we’re deliberately not documenting all the details. Interested parties will have to read the source. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
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
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/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017
Comments inserted. On 14/08/17 08:20, Jitendra Lulla wrote: > Hi, > > I am trying to use afalg on Linux 4.9.37 with OpenSSL 1.1.0f. > > I am facing 2 issues: > > ONE: when I issue the speed command, I see the following: > > [root@localhost apps]# ./openssl speed -evp aes-128-cbc -engine afalg > invalid engine "afalg" > 139853452924736:error:2506406A:DSO support routines:dlfcn_bind_func:could not > bind to the requested symbol > name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine): > /usr/local/lib64/engines-1.1/afalg.so: undefined symbol: bind_engine > 139853452924736:error:2506C06A:DSO support routines:DSO_bind_func:could not > bind to the requested symbol name:crypto/dso/dso_lib.c:185: > 139853452924736:error:260B6068:engine routines:dynamic_load:DSO > failure:crypto/engine/eng_dyn.c:427: > 139853452924736:error:2606A074:engine routines:ENGINE_by_id:no such > engine:crypto/engine/eng_list.c:339:id=afalg > 139853452924736:error:25066067:DS > > > nm afalg.so doesn't show bind_engine > Assuming you have already successfully built OpenSSL using "make", from the "test" subdir of the directory where you downloaded the source, what happens if you execute: OPENSSL_ENGINES=../engines/afalg ../util/shlib_wrap.sh ./afalgtest Another thing to try is (from the top level source dir) touch engines/afalg/e_afalg.c make Check to see if there are any warnings generated during the compilation of the engine. > > When I modify the openssl.cnf file with the engine name and the CIPHERS, > still I dont get it working. The command output and the change in the > openssl.cnf pasted at the end of the mail. > > > TWO: I had to create a softlink to libcrypto.so.1.1 and libssl.so.1.1 like > the following to make openssl command work: > ln -s /usr/local/lib64/libssl.so.1.1 /lib64/libssl.so.1.1 > ln -s /usr/local/lib64/libcrypto.so.1.1 /lib64/libcrypto.so.1.1 > > Is creating the softlinks a known issue and will be fixed? No, this will not be fixed and may not be the most appropriate thing to do on all systems. Matt > > I have pasted the complete information about the OS/distro environment and > installation commands I ran at the bottom. > Could you please suggest what wrong I am doing to make afalg work. > > Thanks > Jitendra Lulla > > > > > BEFORE INSTALLATION: > > [root@localhost jlulla]# rpm -qa |grep openssl > openssl-1.0.1e-60.el7.x86_64 > openssl-devel-1.0.1e-60.el7.x86_64 > openssl-libs-1.0.1e-60.el7.x86_64 > > [root@localhost jlulla]# openssl version > OpenSSL 1.0.1e-fips 11 Feb 2013 > > > > PLEASE SEE FROM HERE PLEASE SEE FROM HERE PLEASE SEE FROM > HERE > > STEP 1 : SOURCE TAKEN FROM > https://www.openssl.org/source/openssl-1.1.0f.tar.gz 2017-May-25 13:09:51 > > [root@localhost jlulla]# uname -a > Linux localhost.localdomain 4.9.37 #1 SMP Fri Jul 21 04:52:46 PDT 2017 x86_64 > x86_64 x86_64 GNU/Linux > > [root@localhost jlulla]# cat /etc/redhat-release > Red Hat Enterprise Linux Server release 7.3 (Maipo) > > > > [root@localhost openssl-1.1.0f]# pwd > /home/jlulla/openssl-1.1.0f > > STEP 2: [root@localhost openssl-1.1.0f]# ./config shared enable-engine > enable-dso enable-afalgeng > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0f (0x1010006fL) > 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-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > no-egd [default] OPENSSL_NO_EGD > 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-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[default] > no-zlib-dynamic [default] > Configuring for linux-x86_64 > CC=gcc > CFLAG=-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack > SHARED_CFLAG =-fPIC -DOPENSSL_USE_NODELETE > DEFINES =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 > LFLAG= > PLIB_LFLAG= > EX_LIBS =-ldl > APPS_OBJ = > CPUID_OBJ=x86_64cpuid.o >
[openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017
Hi, I am trying to use afalg on Linux 4.9.37 with OpenSSL 1.1.0f. I am facing 2 issues: ONE: when I issue the speed command, I see the following: [root@localhost apps]# ./openssl speed -evp aes-128-cbc -engine afalg invalid engine "afalg" 139853452924736:error:2506406A:DSO support routines:dlfcn_bind_func:could not bind to the requested symbol name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine): /usr/local/lib64/engines-1.1/afalg.so: undefined symbol: bind_engine 139853452924736:error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name:crypto/dso/dso_lib.c:185: 139853452924736:error:260B6068:engine routines:dynamic_load:DSO failure:crypto/engine/eng_dyn.c:427: 139853452924736:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:339:id=afalg 139853452924736:error:25066067:DS nm afalg.so doesn't show bind_engine When I modify the openssl.cnf file with the engine name and the CIPHERS, still I dont get it working. The command output and the change in the openssl.cnf pasted at the end of the mail. TWO: I had to create a softlink to libcrypto.so.1.1 and libssl.so.1.1 like the following to make openssl command work: ln -s /usr/local/lib64/libssl.so.1.1 /lib64/libssl.so.1.1 ln -s /usr/local/lib64/libcrypto.so.1.1 /lib64/libcrypto.so.1.1 Is creating the softlinks a known issue and will be fixed? I have pasted the complete information about the OS/distro environment and installation commands I ran at the bottom. Could you please suggest what wrong I am doing to make afalg work. Thanks Jitendra Lulla BEFORE INSTALLATION: [root@localhost jlulla]# rpm -qa |grep openssl openssl-1.0.1e-60.el7.x86_64 openssl-devel-1.0.1e-60.el7.x86_64 openssl-libs-1.0.1e-60.el7.x86_64 [root@localhost jlulla]# openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 PLEASE SEE FROM HERE PLEASE SEE FROM HERE PLEASE SEE FROM HERE STEP 1 : SOURCE TAKEN FROM https://www.openssl.org/source/openssl-1.1.0f.tar.gz 2017-May-25 13:09:51 [root@localhost jlulla]# uname -a Linux localhost.localdomain 4.9.37 #1 SMP Fri Jul 21 04:52:46 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux [root@localhost jlulla]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.3 (Maipo) [root@localhost openssl-1.1.0f]# pwd /home/jlulla/openssl-1.1.0f STEP 2: [root@localhost openssl-1.1.0f]# ./config shared enable-engine enable-dso enable-afalgeng Operating system: x86_64-whatever-linux2 Configuring for linux-x86_64 Configuring OpenSSL version 1.1.0f (0x1010006fL) 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-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 no-egd [default] OPENSSL_NO_EGD 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-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[default] no-zlib-dynamic [default] Configuring for linux-x86_64 CC=gcc CFLAG=-Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack SHARED_CFLAG =-fPIC -DOPENSSL_USE_NODELETE DEFINES =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 LFLAG= PLIB_LFLAG= EX_LIBS =-ldl 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=
