Re: openssl fips patch for RSA Key Gen (186-4)
On Tue, Jan 05, 2021 at 04:34:36PM +, Matt Caswell wrote: > > > On 05/01/2021 11:41, y vasavi wrote: > > > > Hi All, > > > > We currently FOM 2.0 module for FIPS certification. > > It doesn't have support for RSA Key generation(186-4) > > > > Are there any patches available ? > > Definitely there are no official ones (I'm also not aware of any > unofficial ones). In some vendor FIPS patch sets (e.g. Redhat or SUSE) there are RSA Key generation methods meeting FIPS 186-4, for 1.0 and 1.1 based openssls. Ciao, Marcus
Re: [openssl-users] What does this error mean?
On Mon, Apr 16, 2018 at 02:27:17PM -0400, Rob Marshall wrote: > Hi, > > It may not be relevant, but I'm running SLES 10 SP3 which is a very > old version of the OS and I can't upgrade it due to some installed > products. When I try to do a wget I'm seeing the error: > > OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 > alert protocol version > > What does the error mean and how do I fix it? >From which host? The host probably only speaks TLS 1.2. Ciao, Marcus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl FIPS 186-4 Patch
Hi, On Mon, Oct 09, 2017 at 05:24:17PM +0530, murugesh pitchaiah wrote: > Hi, > > Thanks for the comment. > > I know that openSSL is not 186-4 compliant. That is why I am looking > for anybody have the patch for the same. > > I see there are some works in Fedora: > http://pkgs.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-fips.patch Yes, the FIPS 140-2 patches done by Redhat provide a FIPS 186-3 or 186-4 enabled keygeneration. There are some small adjustments that could be merged back into the generic e.g. RSA key generation. Ciao, Marcus signature.asc Description: Digital signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM)
On Fri, Nov 04, 2016 at 10:03:21AM +0530, Akshar Kanak wrote: > Dear team > as per the documnet http://csrc.nist.gov/groups/ > STM/cmvp/documents/fips140-2/FIPS1402IG.pdf > page 150 , Its mentioned > The implementation of the nonce_explicit management logic inside the > module shall ensure that > when the nonce_explicit part of the IV exhausts the maximum number of > possible values for a given > session key (e.g., a 64-bit counter starting from 0 and increasing, > when it reaches the maximum value > of 2 64 -1), > *either party (the client or the server) that encounters this condition > triggers a handshake toestablish a new encryption key – see Sections > 7.4.1.1 and 7.4.1.2 in RFC 5246*. > > is this being handled by openssl ? in the source code of openssl i am > not able find out the > exact location where this renegotiation is initiated when the counter > over flows ? (my understanding might be limited) I think we currently do an error if the calling frontend does not initiate renegotiation. Code is here: crypto/modes/gcm128.c CRYPTO_gcm128_encrypt_ctr32 These kind of checks avoid the 32bit counter overflow: if (mlen > ((U64(1) << 36) - 32) || (sizeof(len) == 8 && mlen < len)) return -1; The calling instance needs to re-iv with CRYPTO_gcm128_setiv. For TLS, if I understand correctly, the stack does intiailize the GCM cipher with a new IV on every TLS record and these cannot be that large. Ciao, Marcus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] CVE-2016-2108 and openssl 0.9.8zf
Hi, to my knowledge older versions are also affected. Ciao, Marcus On Thu, Aug 25, 2016 at 03:10:19AM +, Zhang, Lily (USD) wrote: > Hi > > From the openssl website, it mentioned that > CVE-2016-2108<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108> > affected version of Openssl prior to April 2015. > We used openssl 0.98zf in our old product which was released several years > ago. > > Do you know if > CVE-2016-2108<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108> > affected version 0.9.8zf? We want to get this info to plan our work. > > Thanks > Lily > > CVE-2016-2108<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108> > (OpenSSL advisory) <https://www.openssl.org/news/secadv/20160503.txt> [High > severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] > <https://www.openssl.org/news/vulnerabilities.html#toc> > This issue affected versions of OpenSSL prior to April 2015. > > CVE-2016-2108<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2108> > (OpenSSL advisory) <https://www.openssl.org/news/secadv/20160503.txt> [High > severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] > <https://www.openssl.org/news/vulnerabilities.html#toc> > * Fixed in OpenSSL 1.0.1o (Affected 1.0.1n, 1.0.1m, 1.0.1l, 1.0.1k, > 1.0.1j, 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, > 1.0.1a, 1.0.1) > * Fixed in OpenSSL 1.0.2c (Affected 1.0.2b, 1.0.2a, 1.0.2) > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meiss...@suse.de> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] RSA and FIPS 186-4 in OpenSSL 1.0.1e/fips-2.0.9
On Thu, Dec 17, 2015 at 04:26:21PM -0500, jonetsu wrote: > Hello, > > > I have read about the use of FIPS_rsa_x931_generate_key_ex() for 186-4 > compliance. We are using OpenSSL 1.0.1e with the fips-2.0.9 module. Would > it make functional sense using those versions to patch RSA_generate_key_ex() > (../crypto/rsa/rsa_gen.c) to have: > > > #ifdef OPENSSL_FIPS > if (FIPS_mode()) > return FIPS_rsa_x931_generate_key_ex(rsa, bits, e_value, cb); > #endif > > > Instead of using FIPS_rsa_generate_key_ex() > > > (and also adding the prototype for FIPS_rsa_x931_generate_key_ex() earlier in > rsa_gen.c) I do not think this x931 RSA key generation is 186-4 compliant. Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
On Thu, Mar 26, 2015 at 10:42:21AM +0530, Mukesh Yadav wrote: HI, I have a query for SSl cipher on Openssl-1.0.1h Have an application which is using library compiled with openssl-1.0.1h. Application is failing in func SSL_CTX_set_cipher_list() when input is RC4-MD5+RC4-SHA and it gets succeed when input is RC4-SHA. Not sure whether RC4-MD5 is disabled by default on openssl-1.0.1h. Earlier application was using openssl-0.9.8d. There it used to work fine.. If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h. Tried looking opensource link, couldn't find a way to explicitly enable this algorithm or even if it is diabled by default. Any Inputs for same will be appreciated.. You seem to be using invalid cipher string syntax. : is a delimiter there. openssl ciphers RC4-MD5:RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On Thu, Mar 26, 2015 at 10:57:28AM -0400, Steve Marquess wrote: On 03/25/2015 06:26 PM, jone...@teksavvy.com wrote: On Wed, 25 Mar 2015 17:03:04 -0400 Steve Marquess marqu...@openssl.com wrote: I wasn't aware the Linux kernel (the real one, not proprietary commercial derivatives) had a FIPS mode. Please enlighten me. It could very well be that the word 'mode' is not the right one. 'option' would perhaps be better. This article from 2009 sets the foundation: http://www.guerilla-ciso.com/archives/793 I wonder, 6 years later, what the kernel fips option implies. Maybe I could try to contact Neil Horman andéor look into the sources. That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS doesn't get you any closer to FIPS 140-2 validated kernel cryptography. Unfortunately FIPS 140-2 validation conflicts rather violently with open source software (and with software engineering best practice in general, for that matter). Even if some benevolent benefactor ponied up the quarter megabuck it would take to do an open source based kernel crypto validation, it would be fossilized code obsolete before the validation was even approved. Linux got to be as good as it is due to constant refinement and improvement; FIPS validation presumes that it is possible to write perfect code in one shot and that the environment that code runs in never changes. This is not true. Both Redhat and SUSE have certified or are currently in the process of certifying the Linux Kernel as a cryptographic module and it is not as hard as you make it. The scope is the cryptographic module abstraction layer and even includes loadable modules. Integrity checking is done in the initrd for vmlinuz and via the module signatures also used for UEFI secure boot. crypto/testmgr.c contains the power up selftests. CAVS testing is external, driven over a specific kernel module. There is no binary only blob involved, the paper work will however list an explicit version of a specific kernel release. And the bucks are more in the low 5 digit bucks range. FWIW, here is Redhats last security policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1901.pdf Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL FIPS mode system integration
On Thu, Feb 19, 2015 at 05:19:37AM -0500, jone...@teksavvy.com wrote: Hello, Could you please comment on the following ? Any suggestion, insight, hint, is greatly appreciated. In FIPS mode, the OS, the device, must be aware of crypto errors, and adopt a certain behaviour when one occurs. Like shutting down all data output interfaces. This means that when using OpenSSL, a link must be made between OpenSSL (or the application using it) and the OS, if only to signal the OS of such errors. I would like to modify the FIPS OpenSSL library in such a way that a OS-specific action is taken when a FIPS error is detected. That action could be writing a file, writing a specific log msg, sending a signal to an application, etc. To continue in the same vein, are there major exit points in the library that could reduce the amount of modifications to be made ? Is error information inh FIPS mode traveling in the library in such a way that it could be examined and acted upon at a precise point, covering all error conditions ? Are these mainlines making sense, based on your experience with the OpenSSL library ? Another way would be to modify the applications that uses the OpenSSL library. I tend to think that it would be more efficient and easier on maintenance to modify the OpenSSL library. But then, the complexity of tapping on (every) exit point from the library could be overwhelming, when compared to the source code of several applications. Well, the writing is that the crypto module must stop operating on error. We solved this by calling abort(); in the openssl library on FIPS related error conditions. Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On Thu, Jan 15, 2015 at 05:46:22AM -0500, jone...@teksavvy.com wrote: On Tue, 13 Jan 2015 21:33:49 -0500 jone...@teksavvy.com jone...@teksavvy.com wrote: So basically every app that uses libssl will have to be modified to add a FIPS_mode_set() call near the beginning. Is that right ? Is there a way to automatically have the FIPS test executed when an application loads the library, w/o the application being modified ? Is such a way used at all ? This is actually mandated these days. The library should do this in its ELF constructor for instance. On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Openssl IPv6 Support
On Wed, Nov 05, 2014 at 08:28:40AM +, Mody, Darshan (Darshan) wrote: Hi, Does Openssl support IPv6 officially?. AFAIK the libssl and libcrypto libraries do not use sockets at all, these are left to the applications/libraries using them. So openssl does neither support ipv4 nor ipv6. Ciao, Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl IPv6 Support
On Wed, Nov 05, 2014 at 08:45:55AM -0800, Quanah Gibson-Mount wrote: --On November 5, 2014 at 10:10:26 AM +0100 Marcus Meissner meiss...@suse.de wrote: On Wed, Nov 05, 2014 at 08:28:40AM +, Mody, Darshan (Darshan) wrote: Hi, Does Openssl support IPv6 officially?. AFAIK the libssl and libcrypto libraries do not use sockets at all, these are left to the applications/libraries using them. So openssl does neither support ipv4 nor ipv6. apparently you've never used s_client, or looked at the *ancient* bug explicitly asking that IPv6 support be added for s_client s_server in OpenSSL. It even has a patch that's been widely used for years by major linux distributions. The question was for the library and I was mistaken apparently. I actually also ported a IPv6 patch to the commandline tool. Without autoconf or other automatic detection I do not dare to even try to get it upstream :( CIao, Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-5139 patch
On Mon, Aug 25, 2014 at 02:27:27PM +0530, sandeep umesh wrote: Hello users, NVD vulnerability database confirms the below link as the patch for CVE-2014-5139 - https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=80bd7b41b30af6ee96f519e629463583318de3b0 This is indicating to CVE-2014-2970. Where as, the commit for CVE-2014-5139 seems to be - https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=83764a989dcc87fbea337da5f8f86806fe767b7e Can someone please confirm the patch for this CVE? Thanks They are mostly the same, but CVE-2014-2970 should not be used: CVE-2014-2970 ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2014-5139. Reason: This candidate is a duplicate of CVE-2014-5139, and has also been used to refer to an unrelated topic that is currently outside the scope of CVE. This unrelated topic is a LibreSSL code change adding functionality for certain process-bifurcation use cases that might arise in future LibreSSL-based applications. There is no CVE ID associated with this LibreSSL code change. As of 20140730, CVE-2014-5139 is an undisclosed vulnerability in a different product, with ongoing vulnerability coordination that had previously used the CVE-2014-2970 ID. Ciao, Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Duration of rsa key generation process
On Thu, Jul 03, 2014 at 12:46:05AM -0700, phildoch wrote: I tested the generation of a certificate with a keypair RSA 4096 bit on two different platforms. The openssl command I used is: /openssl req -newkey rsa:4096 -keyout clientKey.pem -out clientReq.pem/ There was a huge difference in the time it took on each one of the platforms. On a first Linux Station it took about 10 seconds. While in the second Linux embedded board it took almost 2 minutes! Is the strength or efficiency of the processors the only way to explain the difference of time? Is there a way to reduce the duration of the process? The issue is probably getting good randomness and your Linux machine might not provide enough. Ciao, Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: What is the underlying algorithm in RAND_bytes() function?
On Mon, May 12, 2014 at 03:00:23AM -0700, harika_n wrote: I am using RAND_bytes function to generate cryptographically secure random numbers. I want to know if it uses Hash based DRBG or HMAC based DRBG. If it uses Hash based DRBG what is the underlying hash function used? I looked at the source code and found that it uses some MD function but I could not find which MD it is using. Depending on what random generator engine is used. The default builtin one is a hash based DRBG. crypto/rand/rand_lcl.h ... the default MD is SHA1. Ciao, Marcus __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
