RE: rand interface while upgrading openssl
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Chitrang Srivastava > Sent: Tuesday, April 16, 2019 08:24 > I need suggestion regarding random number interface , earlier we were using > RAND_METHOD. That's a mechanism for telling OpenSSL what mechanism to use for its cryptographically-strong pseudorandom number generator (CPRNG). > Can I still use the same mechanism? Because I see new code rand folder > contains OS specific > implementation of > > rand_pool_acquire_entropy > rand_pool_add_nonce_data > rand_pool_add_additional_data That's part of OpenSSL's mechanism for getting entropy for the CPRNG. The CPRNG needs this, but they are not the same thing. > As I understand , above function also needs to be ported? I believe you'll need some implementation of them, but I haven't poked around this corner of the OpenSSL 1.1 sources. > Any document to start with porting random number to any platform. The CPRNG seeding mechanism is cryptographically sensitive, and should not be implemented by a non-expert. What does your existing implementation do to provide entropy for the OpenSSL CPRNG? If the answer is "nothing" (or something that's not adequately opaque to an attacker), then your product has seriously flawed security. An attacker who can guess the entropy for the CPRNG pool can break your encryption. It will also be platform-specific (though some mechanisms will exist on multiple platforms), so there can't be much guidance on doing it for "any platform". The literature on seeding CPRNGs is fairly extensive. It's often a challenge for embedded applications, particularly SOC-based ones which may not have much in the way of internal noise sources such as clock skew. Some CPUs have entropy sources, such as Intel's RDRAND; if you trust them (and in an embedded application you may not have much choice) you can use that. -- Michael Wojcik Distinguished Engineer, Micro Focus
Travis fixes?
Is anyone looking at the failing CI builds? It’s been a few days now.
Re: SSL_connect:error in SSLv3/TLS write client hello → write:errno=0
Hi all, The problem was an expired self-generated CA certificate. Now everything works fine. Br, Harri On 12.04.2019 20:20, Harri T. wrote: Hi! I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in SSLv3/TLS write client hello → write:errno=0" mean? Harri root@ldap2:~# echo | openssl s_client -connect ldap2.mydomain.com:389 -showcerts -state -CAfile /etc/ssl/certs/ldap2_cacert.pem CONNECTED(0003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1555084061 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no
rand interface while upgrading openssl
Hi, I am trying to upgrade openssl for my embedded OS platform. The one we currently use is pretty old i.e. *OpenSSL 0.9.6a * , but porting to Openssl 1.1.1b works fine. I need suggestion regarding random number interface , earlier we were using RAND_METHOD. Can I still use the same mechanism? Because I see new code *rand* folder contains OS specific implementation of rand_pool_acquire_entropy rand_pool_add_nonce_data rand_pool_add_additional_data As I understand , above function also needs to be ported? Any document to start with porting random number to any platform. Thanks
RE: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013
Good news. I upgraded nasm to the latest for win64 and everything now works OK. nasm-2.14.02-win64.zip C:\Downloads\OpenSSL\openssl-1.1.1b>nasm -v NASM version 2.14.02 compiled on Dec 26 2018 C:\Downloads\OpenSSL\openssl-1.1.1b>perl Configure VC-WIN64A no-shared --prefix=C:\Downloads\OpenSSL\openssl-1.1.1b\static C:\Downloads\OpenSSL\openssl-1.1.1b>nmake install C:\Downloads\OpenSSL\openssl-1.1.1b>nmake test All tests successful. Files=155, Tests=1163, 103 wallclock secs ( 0.55 usr + 0.27 sys = 0.81 CPU) Result: PASS C:\Downloads\OpenSSL\openssl-1.1.1b>nmake TESTS=test_evp V=1 test All tests successful. Files=1, Tests=9, 1 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU) Result: PASS Regards, John -Original Message- From: openssl-users On Behalf Of John Unsworth Sent: 13 April 2019 15:28 To: openssl-users@openssl.org Subject: RE: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013 CAUTION: This email originated from outside of Synchronoss. Seems OK. nmake TESTS=test_evp V=1 test results attached. C:\Downloads\OpenSSL\openssl-1.1.1b>perl Configure VC-WIN64A no-asm no-shared --prefix=C:\Downloads\OpenSSL\openssl-1.1.1b\static nmake install nmake test All tests successful. Files=155, Tests=1163, 163 wallclock secs ( 0.73 usr + 0.19 sys = 0.92 CPU) Result: PASS Regards, John -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: 12 April 2019 14:16 To: openssl-users@openssl.org Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013 CAUTION: This email originated from outside of Synchronoss. On 11/04/2019 17:43, John Unsworth wrote: > Attached. This is with the debug build. Hmmm, this seems to suggest failures in SHA3 and X448 code. Perhaps assembler issues? Try compiling with "no-asm" as a Configure option. That's not really a viable option for production code but it at least rules assembler issues in or out. Matt > > John > > -Original Message- > From: openssl-users On Behalf Of > Matt Caswell > Sent: 11 April 2019 17:40 > To: openssl-users@openssl.org > Subject: Re: Tests fail on openssl 1.1.1b Windows 7 built with VS 2013 > > CAUTION: This email originated from outside of Synchronoss. > > > On 11/04/2019 15:20, John Unsworth wrote: > >> test\recipes\30-test_evp.t .. Dubious, test >> returned 4 (wstat 1024, 0x400) > > Can you tell us the result from : > > nmake TESTS=test_evp V=1 test > > Thanks > > Matt >
