Re: OpenSSL 1.0.1c, Mac OS X, -no-XXX, and [missing] make depend
On 19 January 2013 16:31, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jan 19, 2013 at 9:17 AM, Ben Laurie b...@links.org wrote: On 26 December 2012 20:07, Jeffrey Walton noloa...@gmail.com wrote: On Wed, Dec 26, 2012 at 9:57 AM, Ben Laurie b...@links.org wrote: On Tue, Dec 25, 2012 at 1:35 PM, Jeffrey Walton noloa...@gmail.com wrote: I fetched `makedepend` from FreeDesktop.org (http://xorg.freedesktop.org/releases/individual/util/). It would not build due to missing dependencies. Ad infinitum. $ port search makedepend makedepend @1.0.4 (x11, devel) Create dependencies in makefiles Ah, thanks Ben. I did not think to try MacPorts. BTW, commit a6bbbf2ff5580addb917a8b4f1160f90af91d268, when I push it, fixes this to use clang instead of makdepend (in master, I may update other branches, too). Thanks Ben. Let me know if you would like me to test it on modern Mac OS X, including iOS cross compile environment before you commit. I didn't make the corresponding change for cross compiles since I don't do those, though it should be trivial, I guess - do they also use cc? My eventual desire is to have configure targets for iphoneos, iphonesimulator, and macosx that use SYSROOT. The darwin targets will not be touched. I can then package the libraries, the headers and their tools (incore) into a Framework, and stop fighting Xcode and its Build Settings (including the cursed User Paths and System Paths). Its not so much me - its more for the organizations I work with. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Web site: Send to Majordomo broken
On 16 Jan 2013, at 17:27, Lutz Jaenicke l...@lutz-jaenicke.de wrote: Thanks for your update. I have fixed the links. http://openssl.org/support/rt.html also has a broken link to the 'list' of bugs - http://rt.openssl.org/NoAuth/Buglist.html returns Page Not Found but http://rt.openssl.org works. -- Bruce Cran__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Failure to generate RSA key in FIPS mode
Hi,
I'm using OpenSSL 1.0.1c linked with FIPS object module.
On startup FIPS is enabled successfully (using FIPS_mode_set function).
When I try to generate rsa key it failed with error 'non fips rsa method'.
I tried calling both EVP API and rsa function directly (RSA_generate_key).
I can see it failed in rsa_gen.c in function RSA_generate_key_ex()
Here is the EVP API I'm using:
EVP_PKEY_CTX *ctx;
EVP_PKEY *pkey = NULL;
ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL);
if (!ctx)
{ /* Error occurred */
return 0;
}
if (EVP_PKEY_keygen_init(ctx) = 0)
{ /* Error */
return 0;
}
if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx, 2048) = 0)
{ /* Error */
return 0;
}
/* Generate key */
if (EVP_PKEY_keygen(ctx, pkey) = 0)
{ /* Error */
return 0;
}
Anything I should do differently to make it work ?
Thanks,
Tal
Re: Failure to generate RSA key in FIPS mode
On Sun, Jan 20, 2013, Oz, Tal (Tal) wrote: Hi, I'm using OpenSSL 1.0.1c linked with FIPS object module. On startup FIPS is enabled successfully (using FIPS_mode_set function). When I try to generate rsa key it failed with error 'non fips rsa method'. I tried calling both EVP API and rsa function directly (RSA_generate_key). I can see it failed in rsa_gen.c in function RSA_generate_key_ex() [snip] Anything I should do differently to make it work ? Well the openssl genrsa and genpkey commands do essentially the same and they work in FIPS mode. So I'd guess it's something wrong elsewhere, such as how your application is linked or how you enter FIPS mode? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: print result of SSL_get_verify_result
On Sat, Jan 19, 2013, ask wrote: Is there is a function in ERR_* that can print the text from code? Not in ERR_* no because the error doesn't come from the ERR library. You can instead use X509_verify_cert_error_string(err) Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Failure to generate RSA key in FIPS mode
I'm cross compiling it to run on arm, so maybe that is the problem (although without FIPS everything is working fine). First I compiled the FIPS object module (using command: './Configure linux-generic32 -Wall -fPIC' ) Then, I created shared object of openSSL which uses fipscanister.o (compiling using fipsld). On strtup, FIPS_mode_set(1) is called successfully. I think that some of the functions which are implemented by FIPS object module are actually not being called. For example, RSA_generate_key_ex, which I can see is implemented both in FIPS object module and in openSSL. When I call to EVP_PKEY_keygen, what is the expected function flow until it gets to FIPS object module implementation ? Currently, I see this flow (all in openSSL): EVP_PKEY_keygen - pkey_rsa_keygen - RSA_generate_key_ex Thanks, Tal -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Sunday, January 20, 2013 6:04 PM To: openssl-users@openssl.org Subject: Re: Failure to generate RSA key in FIPS mode On Sun, Jan 20, 2013, Oz, Tal (Tal) wrote: Hi, I'm using OpenSSL 1.0.1c linked with FIPS object module. On startup FIPS is enabled successfully (using FIPS_mode_set function). When I try to generate rsa key it failed with error 'non fips rsa method'. I tried calling both EVP API and rsa function directly (RSA_generate_key). I can see it failed in rsa_gen.c in function RSA_generate_key_ex() [snip] Anything I should do differently to make it work ? Well the openssl genrsa and genpkey commands do essentially the same and they work in FIPS mode. So I'd guess it's something wrong elsewhere, such as how your application is linked or how you enter FIPS mode? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Can I build the FIPS module with /MT?
On 18-01-2013 20:26, Jeffrey Walton wrote: On Fri, Jan 18, 2013 at 11:01 AM, Memmott, Lester lester.memm...@landesk.com wrote: All modern Versions of Microsoft's C Runtime are thread safe. That occurred around Visual Studio 6.0 (circa 2000 or so). From http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx: The single-threaded CRT (libc.lib, libcd.lib) (formerly the /ML or /MLd options) is no longer available. Instead, use the multithreaded CRT. Thanks for the quick response. My proposal isn't to use the single threaded C runtime, but instead to use the statically linked (multithreaded) C runtime instead of the dynamically linked (multithreaded) runtime. My bad. I read that wrong (I think I crossed wires on /MT and /ML). Your installer should unconditionally install vcredist_*.exe before installing the program proper. I say 'unconditionally' because some installers don't offer a way to check for the CRT version. Since vcredist_x86.exe is a Microsoft executable, the Microsoft installer will exit if its not needed; and the binary should not have any negative platform side effects. ... This is so obviously a non-solution, you should have thought about this before making the rookie mistake of FIPS-certifying the MSVCRTxx.DLL needing build option. As every seriously experienced Visual C++ developer knows, Microsoft has a terrible track record when it comes to making their DLL C runtimes useful for reliable or secure software (I will not bother to enumerate their epic fails here, they are actually documented in various individual Microsoft documents that each try to talk down the problems). In practice for library designs (such as future releases of the OpenSSL FIPS module), the realistic design options are: A. Require any memory, FILE* objects and POSIX-like int file handles allocated by library functions to be freed by other library functions and also require that the FILE* objects and int file handles are used exclusively through the library. And the converse for any such things allocated outside the library. Then the library can use a private statically linked C runtime even if the calling application does not. Many aspects of OpenSSL already do this, but there may be a few unsafe functions laying around, maybe in the BIO_ family. B. Create the one-compilation-only part (the FIPS module in this case) not to call the stateful parts of the C runtime (especially malloc/free etc.) directly but leave that to the recompilable part (the FIPS-compatible OpenSSL library in this case). This way a single code blob becomes independent of such factors and also becomes reusable across compiler versions, and even operating systems (imagine an x86_64 module that is compiled once by a known good compiler, FIPS certified for different CPU capabilities and then reused on all the many OSes for that architecture with Apple's legal requirements as a possible exception). This also creates a clearer specification of the module boundary, as this no longer includes an unknown C runtime library, just a specific environment condition on helper functions supplied by the FIPS-compatible OpenSSL library. Its also a recommended solution with, for example, Inno Installer when the setup program carries around both an x86 and x64 copy of the program to install. I can't give you a reference since it appears http://news.jrsoftware.org/read/thread.php?group=jrsoftware.innosetup is not indexed. But I asked a similar question a few years ago. This won't work for code running outside the protective bubble of a completely installed multi-megabyte application. Anything running during install/uninstall/upgrade or downloaded as a small piece of mobile code will not be able to satisfy this, by definition. That sidesteps the FIPS requirements, and the nasty interactions between mixing/matching static and dynamic libraries with /NODEFAULTLIB. The nasty side effects have been deliberately exaggerated by the documentation writers, the realities are much more manageable as explained above. -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Can I build the FIPS module with /MT?
On Sun, Jan 20, 2013 at 6:51 PM, jb-open...@wisemo.com wrote: On 18-01-2013 20:26, Jeffrey Walton wrote: On Fri, Jan 18, 2013 at 11:01 AM, Memmott, Lester lester.memm...@landesk.com wrote: All modern Versions of Microsoft's C Runtime are thread safe. That occurred around Visual Studio 6.0 (circa 2000 or so). From http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx: The single-threaded CRT (libc.lib, libcd.lib) (formerly the /ML or /MLd options) is no longer available. Instead, use the multithreaded CRT. Thanks for the quick response. My proposal isn't to use the single threaded C runtime, but instead to use the statically linked (multithreaded) C runtime instead of the dynamically linked (multithreaded) runtime. My bad. I read that wrong (I think I crossed wires on /MT and /ML). Your installer should unconditionally install vcredist_*.exe before installing the program proper. I say 'unconditionally' because some installers don't offer a way to check for the CRT version. Since vcredist_x86.exe is a Microsoft executable, the Microsoft installer will exit if its not needed; and the binary should not have any negative platform side effects. ... This is so obviously a non-solution, you should have thought about this before making the rookie mistake of FIPS-certifying the MSVCRTxx.DLL needing build option. I'm not sure what you mean. For OpenSSL, the CMVP considers the platform golden. Any interaction with vendor provided components - such as runtimes - are irrelevant and have no bearing on FIPS validation. That means if he needs the runtime supplied with Visual Studio 2008 SP1, he packages it and installs it. This is on contrast with, for example, using Crypto++'s FIPS module. In the Crypto++ case, the binary module was validated against a specific OS and runtime environment, and it requires the specific environment (and specific version of the runtime). As every seriously experienced Visual C++ developer knows, Microsoft has a terrible track record when it comes to making their DLL C runtimes useful for reliable or secure software (I will not bother to enumerate their epic fails here, they are actually documented in various individual Microsoft documents that each try to talk down the problems). All platforms have their problems. I could go on and on about Drepper and his runtime and loader (that make regular appearances on Bugtraq and Full Disclosure). But its irrelevant for the source code validation since the platform is golden. In practice for library designs (such as future releases of the OpenSSL FIPS module), the realistic design options are: A. Require any memory, FILE* objects and POSIX-like int file handles allocated by library functions to be freed by other library functions and also require that the FILE* objects and int file handles are used exclusively through the library. And the converse for any such things allocated outside the library. Then the library can use a private statically linked C runtime even if the calling application does not. Many aspects of OpenSSL already do this, but there may be a few unsafe functions laying around, maybe in the BIO_ family. OK. I believe this is the approach of Microsoft's Net API. B. Create the one-compilation-only part (the FIPS module in this case) not to call the stateful parts of the C runtime (especially malloc/free etc.) directly but leave that to the recompilable part (the FIPS-compatible OpenSSL library in this case). This way a single code That's kind of tenuous :) blob becomes independent of such factors and also becomes reusable across compiler versions, and even operating systems (imagine an x86_64 module that is compiled once by a known good compiler, FIPS certified The compiler is part of the platform, so its considered golden too. All compilers are 'knonw good' (some handwaiving). for different CPU capabilities and then reused on all the many OSes for that architecture with Apple's legal requirements as a possible exception). This also creates a clearer specification of the module boundary, as this no longer includes an unknown C runtime library, just a specific environment condition on helper functions supplied by the FIPS-compatible OpenSSL library. It does not sound bad from an architectural point of view, but I'm not sure I'd want to implement it; and I'm not sure what the CMVP would think about it. Perhaps Steve Marquess has some insight due to all his experience with the CMVP. Its also a recommended solution with, for example, Inno Installer when the setup program carries around both an x86 and x64 copy of the program to install. I can't give you a reference since it appears http://news.jrsoftware.org/read/thread.php?group=jrsoftware.innosetup is not indexed. But I asked a similar question a few years ago. This won't work for code running outside the protective bubble of a completely installed multi-megabyte
Re: OpenSSL 1.0.1c, Mac OS X, -no-XXX, and [missing] make depend
On Sat, Jan 19, 2013 at 11:42 AM, Ben Laurie b...@links.org wrote: On 19 January 2013 16:31, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Jan 19, 2013 at 9:17 AM, Ben Laurie b...@links.org wrote: On 26 December 2012 20:07, Jeffrey Walton noloa...@gmail.com wrote: On Wed, Dec 26, 2012 at 9:57 AM, Ben Laurie b...@links.org wrote: On Tue, Dec 25, 2012 at 1:35 PM, Jeffrey Walton noloa...@gmail.com wrote: I fetched `makedepend` from FreeDesktop.org (http://xorg.freedesktop.org/releases/individual/util/). It would not build due to missing dependencies. Ad infinitum. $ port search makedepend makedepend @1.0.4 (x11, devel) Create dependencies in makefiles Ah, thanks Ben. I did not think to try MacPorts. BTW, commit a6bbbf2ff5580addb917a8b4f1160f90af91d268, when I push it, fixes this to use clang instead of makdepend (in master, I may update other branches, too). Thanks Ben. Let me know if you would like me to test it on modern Mac OS X, including iOS cross compile environment before you commit. I didn't make the corresponding change for cross compiles since I don't do those, though it should be trivial, I guess - do they also use cc? My eventual desire is to have configure targets for iphoneos, iphonesimulator, and macosx that use SYSROOT. The darwin targets will not be touched. I can then package the libraries, the headers and their tools (incore) into a Framework, and stop fighting Xcode and its Build Settings (including the cursed User Paths and System Paths). Its not so much me - its more for the organizations I work with. Well, I set CROSS_CHAIN and CROSS_COMPILE to /Applications/Xcode/Developer.../Platform/SDKs//usr/bin. I believe that means llvm-gcc. I don't explicitly set CC in the scripts (the scripts are based on Tim's original work). The Plaform above can be MacOSX, iPhoneOS, or iPhoneSimulator. I also put CROSS_COMPILE on path as the first entry. When I set CROSS_COMPILE, `MAKEDEPEND=makedepend` breaks. To fix it, I open the Makefile and change it to `MAKEDEPEND=$(CC) -M`. Note: the fix is need for FIPS Capable, but not needed for FIPS Object Module. So I don't believe I am using CC by default, but I use CC to fix the problem when I encounter it. I'm not sure what CC evaluates to. I will check it the next time I have Xcode open. if you are not adverse to a small change if needed, check it in and I will go through a FIPS Object Module and FIPS Capable Library build. I'll report back if there are problems. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Building OpenSSL for EFI
I would like (need) to get OpenSSL working in the EFI [...] In the EDK-2, this directory: edk2/trunk/edk2/CryptoPkg/Library/OpensslLib/* showd you how to patch, configure, and build OpenSSL in the EDK-2 environment. Also look in some nearby include directories for OpenSSL headers and install scripts. AFAIK, besides this list, the only other place to talk about UEFI OpenSSL issues would be on the EDK-2 list. There are a few OpenSSL-related msgs on the EDK-2 list; That list is on YahooGroups, which has suboptimal archives; but in the last few months, someone setup Gmake.org mirrors of most of the EDK-2 lists. HTH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
