Re: [openssl-dev] FIPS CAVP tests for WinCE.
On 06/18/2017 01:03 PM, Jayalakshmi bhat wrote: > Hi All, > > I am using OpenSSL-FIPS-2.0.4 library on ARM7 + WinCE 6.0 with "user > affirm" the validation for Y per I.G. G.5. > > We want to run latest CAVP test suites. We have built the *build_algvs > and other executable* for the above product/build environment. > However when we are trying to execute the executable with req file and > resp file parameters, example fips_drbgvs CTR_DRBG.req CTR_DRBG.resp > we end up in receiving error "error opening the input file". > > Later we found that WinCE environment cannot read simple character file > name, it needs some windows specific conversion like WideCharToMultiByte. > > We have the below questions, > > 1. Is there any way to build the test suites on WinCE environment. User > guide says it is incomplete? > 2. As these are test files, is it OK to modify them? WinCE (with WinEC) is one of the most painful environments to test on, and what's worse is no two such devices seem to be very similar. We've ended up hand-hacking the test suite software for each and every such platform validation, and the hacks for one WinCR device aren't necessarily useful for the next one. The test suite software is outside the ideologically significant "cryptographic module boundary", but you'll need to consult with your particular accredited test lab on just what is and isn't acceptable. Also please note that the algorithm test vectors change frequently, so even on a well-behaved target device you generally can't use the test suite software from earlier validations as-is. Usually the hacks to accommodate the latest test vector format aren't difficult, but you don't know what's actually needed until you get the new set of test vectors (which of course cost money). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl-announce] Akamai sponsors TLS 1.3
Many companies use OpenSSL, relatively few of them support it. I'm pleased to announce that Akamai (https://www.akamai.com/) has expanded its already substantial presence in the latter category. Akamai has contractually committed to funding implementation of TLS 1.3 in OpenSSL. That is something we were going to do anyway, an initiative that has been delayed by the major overhaul leading up to the 1.1 release. But, by contracting us to perform that implementation Akamai accomplishes two things: 1) A known schedule (with a key deadline of 2017-04-05). Left to our own devices and the usual resource contentions we would have taken longer; by funding us for a specific deliverable and schedule Akamai ensures a result that meets their own needs. 2) Significant financial support for OpenSSL, funding we would not otherwise have received which will be used for long term support of OpenSSL. While not technically a donation (because payment is contingent on specific deliverables) the end effect is the same, as we would have eventually done a comparable TLS 1.3 implementation anyway. Thank you Akamai for your well-considered initiative to both address your own business requirements and support OpenSSL and the OpenSSL user community at the same time; a win-win situation all around. -Steve M. -- Steve Marquess OpenSSL Software Foundation 20-22 Wenlock Road London N1 7GU United Kingdom +44 1785508015 +1 301 874 2571 direct marqu...@opensslfoundation.org ste...@openssl.org -- openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] About Chinese crypto-algorithms
On 09/27/2016 11:24 AM, robin wrote: > Thanks for your reply Marquess. I understand English documents are > essential factor to start, and I certainly sure it is not A problem > to translate these kinds of published standard to English version if > there's no other unclear reasons. > > In the past, we have several cryptographic algorithms implement in > different platforms and obviously can contribute to community as a > reference including test samples. > > If possible, an English copy of standard would be a good start for > this work? > > It will be great to hear your further information. > Is there currently any documentation at all on these Chinese algorithms? I'm certainly curious, and I'm sure others in the OpenSSL community will be. I've had some limited experiences with translations of technical standards, and from that I know those are the hardest translations of all. It may well take a lot more manpower to generate quality translations than to code implementations. Please keep in mind that the technical documentation is a necessary prerequisite but not necessarily sufficient. The nature of the algorithms may be uninteresting (we've declined to accept/implement some algorithms we judged to be of insufficient virtue or utility, even for pay). We can be very picky about code contributions too, as any code added to OpenSSL has to work across a huge spectrum of platforms and be maintainable for the long haul. We may also not have the resources to tackle something that would otherwise be of interest (we have a back catalog of nice-to-have cryptography waiting for a rainy day). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPS validation
On 09/07/2016 12:49 AM, Leon Brits wrote: > Hi SteveM, > > Yes we are copycats - thanks for making it possible. > > I was also amazed when I received the email very close to our final > source code review and operational testing phase. > > I've used the fips_algv tests suite to have the algorithms validated > (#3768) using this lab but I cannot see how to use it to "induce" and > error in the FIPS module. > Look at what the "fips_test_suite" option of fips_algv does. That's also discussed in the OpenSSL FIPS module user guide. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPS validation
On 09/05/2016 02:09 AM, Leon Brits wrote: > The FIPS validation company says: > > > > “The tests I am most interested in are the failure cases, where you > induce an error in each of the power-on self-tests and conditional tests > (i.e, continuous RNG test, pairwise consistency test).” > > > > Can anybody tell me how I can induce these errors? > > > > I do run the FIPS_selftest() function on demand and the POST has never > failed when I switch to FIPS mode with FIPS_mode_set(). > > > > Thanks > > LJB > > > So you're trying to obtain your own copycat validation based on the OpenSSL FIPS Object Module code (as many vendors have done). Since that has been done so many times your unnamed FIPS validation consultant or test lab should already be familiar enough with the OpenSSL FIPS module code to immediately know the answer to this question, rather than asking it of you (that's a hint). Most labs or consultants would direct you to the "fips_test_suite" test harness (also called from fips_algvs), which is included in the OpenSSL FIPS module tarballs and documented in the User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf Test labs typically just run "fips_algv fips_test_suite" for the functional testing, as it was designed for exactly that purpose. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Latest Open SSL and old FIP module
On 06/17/2016 07:48 AM, Alibek Joraev wrote: > Currently, I use 1.0.1 series (with current one being 1.0.1t) of OpenSSL > with OpenSSL FIPS module version 2.0.2. > as 1.0.1 version nears its long term support, I would like to upgrade to > OpenSSL 1.0.2h, but keep existing 2.0.2 FIPS module. > > I can see that latest OpenSSL 1.0.2h is posted together with FIPS module > 2.0.12. > > is OpenSSL 1.0.2h compatible with older FIPS modules? or do I also have > to upgrade to newest FIPS module? > > ... All revisions of OpenSSL 1.0.2 are compatible with all revisions of the OpenSSL FIPS Object Module 2.0. So you can keep your existing 2.0.2 FIPS module and upgrade from 1.0.1 to 1.0.2. Note that in general there is no advantage to upgrading to newer FIPS module revisions (e.g. from 2.0.2 to 2.0.12) as in general we're not allowed to do bugfixes or feature enhancements; the newer revisions are not "better" in the sense usually expected for open source software. The exception to that statement is a feature enhancement of sorts, the removal of Dual EC DRBG that occurred at 2.0.6. If completely removing Dual EC DRBG matters to you[1] then you can upgrade to any revision 2.0.6+, all of which will work for any platform supported by 2.0.2. If you're upgrading you might as well go straight to 2.0.12[2], while realizing you'll always be a revision or three behind (2.0.13 is in the works). Also please note that at some point you'll want or need to upgrade to OpenSSL 1.1, for which no FIPS 140 support is currently available or planned at anything beyond the wistful thinking stage. -Steve M. [1] why you might: http://veridicalsystems.com/blog/immutability-of-fips/ [2] Unless, sigh, your platform(s) of interest are listed only for the #1747 or #2473 validations which stop at revision 2.0.10, in which case that's the newest FIPS module revision with the magical pixie dust of FIPS righteousness, even though the latest revision (2.0.12) functionally supports all platforms for all validations. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPs mode and openssl
On 05/27/2016 05:11 AM, Mody, Darshan (Darshan) wrote: > Hi, > > > > I have a query with regards to FIPS mode and use of Openssl. I have put > my kernel image n FIPs mode using the documentation > (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html) > > > > Do I need to put the openssl in FIPs mode using the API FIPS_mode_set(1) > or will by default the openssl will put itself in FIPS mode for my > application. There are couple of application on the server we use > openssl. Do I need to put each of the application openssl in FIPS mode > or will it put itself in FIPS since the kernel is in FIPS mode. > > > > Thanks > > Darshan > > > You are using the Red Hat FIPS module, not the OpenSSL one, so you'll need to ask that vendor. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Where is the sample-comprehensive CAVS test vectors' set with all 259 test vectors
On 04/14/2016 07:20 AM, cyriac wrote: > Thanx! That link works now. Infact, we had some samples from there already. > We understand now that the test vectors do change over time and there is > nothing like a "final" set. > > And yes, we are working with an accredited test lab already. The intention > behind getting hold of a complete set in advance was to have a trial run of > the tests in advance till we wait for official test vectors from the lab. IMHO the algorithm testing process is tedious enough as it is; since in general you cannot get a "complete set" in advance because the format changes so frequently, you're just asking for unnecessary grief and frustration. You'll encounter enough of that in the normal course of events without seeking it out :-) Your lab should have told you that... > And as I understand, officially, these have to be verified with the CAVS > tool which can be done only by the lab. Correct. > However, the perl script fipsalgtest.pl is capable to verify the .rsp files > against the .fax files (provided along with the vectors) and to provide a > test summary report. (With the exception of some key gen vectors which could > be verified only by CAVS tool) > We have done this for a set of vectors and it passes too. > > *Only one clarification sought for.. If fipsalgtest.pl tells me that my > vectors are verified without errors, should I still be skeptical until the > lab confirms it ?* Yes, for several reasons: 1) That check only compares the results from a presumed known good platform against the target response files. 2) The test vector set you're using is probably obsolete, and so is no good for your intended outcome even if "correct". 3) Even of "current", with "correct" response files relative to the request files, the request files may be wrong (as in not what is required by the CAVP). Those files are generated from the CAVS tool via a labor intensive manual process, and the CAVS tool is updated frequently and sometimes has bugs. Errors in one or both (manual process or tool) are not at all uncommon; I'd say the error rate is in the 10% range. So you can find that the test vectors you processed without apparent error, and even that the test lab confirmed, can still turn out to be unsuitable. Usually you don't have to reprocess them all, though I usually do given that it's easier to use fipsalgtest.pl on a full test vector set than to manually manipulate individual request files. Note I like to hang on to the test device until the CMVP formally approves the related validation action, as on occasion we've have to re-do testing that was first done months ago. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Where is the sample-comprehensive CAVS test vectors' set with all 259 test vectors
On 04/14/2016 06:09 AM, cyriac wrote: > Hi, > > *In FIPS Userguide 2.0*, Appendix B, about CAVS testing, I could find: > Note this step requires a large directory tree of input test data files > produced by the > testing lab using a NIST provided tool (CAVS); several sets of input and > response values can be > found http://openssl.com/testing/validation-2.0/testvectors/. The file > *http://openssl.com/testing/validation-2.0/testvectors/tv.tar.gz > contains a complete set of 259 test vector files with correct responses that > can be used for a single > comprehensive test. *Note the number and format of these test vector files > changes over time, so this > set may not correspond exactly to what the CAVS tool currently produces. > > Unfortunately, this sample comprehensive test vector tar-ball (tv.tar.gz) is > not present in this location. > I have been searching all out, but I could not get hold of this set with all > 259 vectors from anywhere. > Could I know how to get hold of this complete test vector set. (Any web link > available?). Kindly help… The tv.tar.gz symlink was missing; I've restored it. Unfortunately that doesn't do you much good. You can find a huge collection of historical test vectors at: http://openssl.com/testing/validation-2.0/testvectors/ and tv.tar.gz is now pointing to one of them. But, the format and contents of these test vector data sets change over time, frequently. Having one of them doesn't do you much good for a number of reasons: 1) Even if you appear to have processed them without error, you can't properly verify them without an accredited test lab, and if you were working with an accredited test lab they would supply you with a current set of test vectors. 2) There is no reason to fool with these test vectors unless you're trying for your own validation using the OpenSSL FIPS module code, in which case you'll have to engage an accredited test lab. 3) Even if you have a current set (unlikely), any official algorithm validation action requires a unique new set of test vectors (which ... wait for it ... you can only get from an accredited test lab). 4) If you're working with a non-current set of test vectors (which is usually all of them as the format changes frequently), you'll waste time barking up the wrong tree. They can change substantially in a short period of time; note for instance the file count is no longer 259. Notice I mention "accredited test lab" a lot. You're wasting your time if you've not engaged one. Our open source test suite software makes the mechanics of validation a lot easier, but you still have to use a test lab. Yes, you have to pay the lab, but welcome to the wonderful world of FIPS 140-2. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1.0 and FIPS
On 02/23/2016 08:16 AM, Wall, Stephen wrote: > Thanks for the feedback, I was deliberately ignoring the issue of not > running non-FIPS algos, there are actually instances where it's > desirable to have access to them in FIPS mode (RADIUS, eg). A > generic way to handle that (aside from Richards dream proposal) would > be to have a NO_INTERNAL_ALGORITHMS setting somewhere in the API. > Possibly split into NO_INTERNAL_SYMMETRIC_ALGOS, ASYMMETRIC, HASHES, > etc, for finer grained control. Or even a bit per specific algo to > go to the extreme. Probably too late to get something like that in > for a 1.1.0 release...? > > As far as structure incompatibility, translation could be handled > internally to the engine (though that would require a lot of > near-duplicate structures). Feasible, maybe not practical. Sufficient desperation and sufficiently deep pockets set the boundaries of "feasible". FIPS 140-2 isn't practical to begin with. I know of several commercial vendors planning to hand-jamb some variant of the current FIPS module into OpenSSL 1.1 (what they see as their least bad option). The result is going to be horrible, though, and will still require validation. It will leave them with a maintenance tail that will haunt them for years to come. I wish them luck, and understand that FIPS 140-2 is important enough to their business that they have no choice. But here at the OpenSSL project we've made the conscious decision to not allow FIPS 140-2 to distort and pervert OpenSSL even more than has already been the case. We'll do a (relatively) clean and sane implementation for 1.1 if and when we can, and nothing otherwise. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1.0 and FIPS
On 02/22/2016 01:58 PM, Dr. Stephen Henson wrote: > On Mon, Feb 22, 2016, Wall, Stephen wrote: > >> I wonder if I could get the thoughts of some of you developers on how >> difficult it would be to build an engine for OpenSSL 1.1.0 that makes use of >> the current (2.0.11?) fipscanister.o. Also, opinions on if this would be a >> legitimate way to get FIPS in 1.1.0. >> > > Just to add a few thoughts to this. > > It would be very tricky and rather messy. The 2.0.x module uses various > shortcuts (which were pretty much essential given the time pressure on its > development) such as keeping structure compatible with OpenSSL. For 1.1.0 many > structures have changed considerably and many are opaque so this wont work. > > Add to that that it isn't just a case of having an external ENGINE. There > needs to be some extensive glue code in OpenSSL itself to (for example) ensure > that the correct imeplementation is used and to block unapproved APIs and > algorithms. > ... This last point is worth emphasizing. While the formal FIPS validation is more or less done in a vacuum (or perhaps I should say "reality independent context"), it has to be used in a real world setting with application code (probably legacy code developed to use stock OpenSSL). That means a) using it with OpenSSL, because the FIPS module alone is too impoverished an API for direct use, and b) making sure your application does only FIPS allowed cryptography while FIPS mode is enabled. That latter step is a lot harder than it looks. While some vendors won't care as long as they have some minimal level of buzzword compliance, some do. With the "FIPS enabled" OpenSSL converting your existing application for FIPS 140-2 can be as simple as throwing in a FIPS_mode_set() call. With a stock OpenSSL and hand-jammed FIPS module you'd need to manually vet all application code; the stock OpenSSL won't let you know when your application uses non-allowed cryptography. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1.0 and FIPS
On 02/22/2016 11:01 AM, Wall, Stephen wrote: > I wonder if I could get the thoughts of some of you developers on how > difficult it would be to build an engine for OpenSSL 1.1.0 that makes > use of the current (2.0.11?) fipscanister.o. Also, opinions on if > this would be a legitimate way to get FIPS in 1.1.0. > > Thanks, spw > Re-use of the current 2.0 module was debated in detail, with the conclusion that too many distortions to the new OpenSSL code would be required. We're trying hard to get away from messy, ugly, fragile code and reluctantly concluded that only a new FIPS module designed for a clean interface with OpenSSL 1.1 was feasible. We are not happy with the loss of FIPS support for 1.1; we know many users require it. But, we're not willing to compromise sound software engineering judgment to kludge together an abomination (and frankly the current FIPS module with OpenSSL 1.0.N is pretty ugly already). What we need is a new FIPS module, which we're willing to develop given the opportunity. The main problem there is the formal validation process. A FIPS 140-2 validation is challenging enough for conventional proprietary close-source binary code; open source based validations are enormously more difficult. Those have only been done five times, and my assessment of the current regulatory environment is that it would be far too risky for us to attempt a sixth such attempt (at least not without sponsor(s) willing to absorb most of that risk). If and when a new FIPS module for 1.1 is developed, it almost certainly will take the form of a new "engine" style modular component. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Openssl 1.0.2e is compatible with FIPS module openssl-fips-2.0.10
On 12/09/2015 12:07 AM, Patil, Ashwini IN BLR SHC wrote: > Hello All, > > Please let me know if the Openssl 1.0.2e is compatible with FIPS module > openssl-fips-2.0.10. > Your help is appreciated. The OpenSSL FIPS Object Module v2.0 (all openssl-fips-2.0.N.tar.gz tarballs for the #1747, #2398, #2473 validations) is compatible with all OpenSSL 1.0.1 and 1.0.2 releases. We have 2.0.11 and 2.0.12 revisions in process (and waiting and waiting...); those and any subsequent 2.0.N revisions will also be compatible with 1.0.1 and 1.0.2. It will not be compatible with the upcoming 1.1 releases. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code
On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote:
> Hi,
>
> I don't know what your intentions are with FIPS support in master, ...
We would like to continue to provide a FIPS validated module for the 1.1
(and subsequent) releases. Unfortunately the current module ("OpenSSL
FIPS Object Module 2.0") designed for compatibility with the 1.0
releases won't be compatible with 1.1. That means we need to obtain a
new validation for a new module, an endeavor fraught with many
difficulties (none of them technical).
I do expect the stars will align for that eventually, as they have for
the five previous open source based validations. In the interim, since
the FIPS module is shaped almost entirely by policy and metaphysical
considerations, we should not include any incomplete FIPS specific code
in 1.1 -- code that even if complete in some speculative sense would
also be unusable absent a matching FIPS 140-2 validation.
-Steve M.
--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@opensslfoundation.com
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code
On 10/31/2015 09:01 AM, Richard Levitte wrote: > Can't recall previous discussions on this, but would it be possible to have a > FIPS engine? Of a sort, yes. I'll let Steve Henson speak to the details, but it is his hope (and mine) that FIPS module support for 1.1 and beyond would be modular so the FIPS module and OpenSSL releases would no longer be so tightly coupled. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4055] FIPS Object Module User Guide corrections needed for (*get_entropy)()
On 09/21/2015 08:00 PM, Gibbons, Lee D via RT wrote: > This is to highlight a bug in the FIPS Object Module 2.10 and corrective > documentation in its User Guide. > > The User Guide for the FIPS Object Module 2.10 describes the (*get_entropy)() > callback: > > size_t (*get_entropy)(DRBG_CTX *ctx, unsigned char **pout, >int entropy, size_t min_len, size_t max_len) > > "A call to this function requests entropy bits of entropy in > a buffer of between min_len and > max_len size bytes inclusive. The values of these are > mechanism specific and taken from > SP800-90 tables. This callback should then return the amount > of data in the buffer *pout and the > length in the return value, or zero in case of being unable > to retrieve sufficient entropy." > > The caller of (*get_entropy)() is the static function fips_get_entropy(). > Notice how it constructs the value, which should be in bits: > > rv = dctx->get_entropy(dctx, , entropy + bl, > min_len + bl, max_len + bl); > *pout = tout + bl; > if (rv < (min_len + bl) || (rv % bl)) >return 0; > > The "entropy + bl" expression is mixing types, adding bits and bytes > together. Anyone defining a (*get_entropy)() callback had better ignore the > parameter. What's more, the callback had better return > rounded up to a dctx->entropy_blocklen boundary or face failure. The User > Guide mentions none of this. > > I realize the FIPS Object Module is frozen. The documentation should be > corrected to expose the real restrictions on the callback. Doug, it took awhile to respond to this because I had to check with one of my smarter colleagues (Steve Henson in this case). He confirms the bug, which fortunately is easy to work around and only matters when an application supplies external entropy callbacks (which few will). Documenting it coherently is another matter. Entropy is a bit of a mess in FIPS 140-2 due to the mandated continuous PRNG test which is completely useless and it very clearly doesn't fit properly with the new DRBGs and especially not entropy sources. For the #1747 validation we specifically asked if it was required were told said yes. The poor fit with entropy sources is that it's perfectly legal for an entropy source to provide the entropy in a non-uniform way. Say 256 bits of entropy at the start of a large buffer and the rest nothing (but not all zeroes!). If the input to the PRNG test is supplied as a big buffer like that the DRBG continuous test will compare the first block against the rest and then discard the first block which might remove a disproportionate amount of entropy. So after pondering a bit I came up with the following new text for section 6.1.1 of the User Guide. Any errors of omission or commission are mine, not Steve's: (addition to Section 6.1.1) Few applications provide external entropy callbacks, but due to a bug in the callback code those that do define a (*get_entropy)() callback should have that return at least two full "blocks" of entropy. This is because the FIPS 140-2 mandated continuous PRNG test has to be applied to the entropy source. It has to compare consecutive blocks (discarding the first) which means the entropy source needs to supply a multiple of the block size. The solution isn't obvious so a detailed discusson follows. FIPS_drbg_get_strength() returns the strength of the DRBG context which is the number of bits of entropy needed to seed the DRBG without the continuous PRNG test. When an application adds its own entropy callbacks it has to tell the FIPS module what the block length of the entropy source is. So arguably the entropy parameter with the continuous PRNG test is: FIPS_drbg_get_strength(dctx) + block_length * 8 But, that calculation determines a maximum value and an entropy source could conceivably supply less. For instance, suppose we want 256 bits of entropy and the callback supplies it as high grade entropy uniformly in a 32 byte buffer (the absolute minimum) and has a 16 byte block length. An extra block is needed for the PRNG test so we should supply a 48 byte buffer (three blocks) and effectively 384 bits of entropy. Now suppose we have a low grade entropy source which provides just 1 bit of entropy per byte. Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7). Again lets have a block size of 16 bytes. This time to get 256 bits of entropy the source must provides it in a 256 byte buffer. An extra block is required which makes 272 bytes but because we only have 1 bit of entropy per byte it just needs to supply 272 bits of entropy. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, M
Re: [openssl-dev] We're working on license changes
On 08/04/2015 04:02 PM, Brian Smith wrote: ... The OpenSSL website says[1] the OpenSSL Software Foundation (OSF) is incorporated in the United States as a regular for-profit corporation, and the proposed CLA[2] is an agreement between the contributor and that for-profit corporation. I'm going to jump in here with some headache-inducing detail. In The Beginning there was one legal entity called OSF. It handled everything legal/financial for the OpenSSL project, from commercial consulting to donations. Then with the rapid expansion of the project post-Heartbleed, and the receipt of some meaningful levels of funding for the first time ever, we began the arduous process of migrating to a new corporate structure, or structures plural. One new entity, OpenSSL Software Services Inc., has taken over almost all commercial and quasi-commercial activities. Another new entity, OpenSSL Software Foundation Inc., a non-profit Delaware corporation, has taken over all the non-commercial functions of representing the OpenSSL foundation (such as holding CLAs). We've deliberately and clearly delineated and separated those different functions. The original legal entity, a Maryland corporation still called OpenSSL Software Foundation, Inc., still exists but has been reduced to handling only FIPS 140-2 related work, and not much of that. The original intention was to rename it (to OpenSSL Validation Services, Inc.), but renaming a corporation is almost as much hassle and paperwork as starting one, and it appears there may be a significant chance that this original legal entity may be shutting down entirely. For that reason I've stalled on the formal name change (which become easier as ever fewer active contractual agreements are in place). If it isn't completely gone by the end of this year it will be renamed. All contemporary references you see to the OpenSSL Software Foundation are for the new non-profit Delaware entity. As Rich has noted we do need to change mentions of the original entity, now confined to FIPS related activities only. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] PR for OpenSSL FIPS
On 07/28/2015 03:17 PM, Misaki.Miyashita wrote: Hi, I would like the same change as the following PR to be applied to the OpenSSL FIPS module: https://github.com/openssl/openssl/pull/342 How should I proceed in this case? Should I make a pull request for the openssl:OpenSSL-fips-2_0-dev branch? The FIPS module is unfortunately a special case because we can't make any changes to already validated code. Our only opportunity to introduce course code changes is when we do change letter updates, and those we have to pay for (and wait on for months). Only some kinds of source code changes can be done even with that process. For example, we were unable to fully mitigate Lucky 13 for the FIPS-enabled OpenSSL because we weren't allowed to make the necessary changes to the FIPS module. So feel free to make changes yourself to your local copy of the code, but you'll need to get that modified code validated to claim FIPS 140-2 validation. There is no reason to use the FIPS module code otherwise, so the basic rule is you just have to live with whatever flaws or omissions are present. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module
On 07/01/2015 02:24 AM, Patil, Ashwini IN BLR STS wrote: Hello All, Please let me know if openssl-1.0.2c include FIPS 140-2 Object Module. Also please explain how to validate the application. This question would be more appropriate for the openssl-users list. The -dev list is for OpenSSL development issues, not for basic usage questions. You might want to start with the OpenSSL FIPS User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] RSA SigVer (FIPS 186-4) Issue
On 06/29/2015 02:48 AM, rst...@symsysresearch.com wrote: I am getting incorrect False-Negative results when performing tests with 186-4 vectors (generated by CAVS 17.6). This vector is being reported false while CAVS says they should pass. [mod = 1024] ... You're getting CAVS tests for 1024 bit RSA keys? Keep in mind that the #1747 validation predates FPS 186-4, and we aren't allowed to update it to meet that (or other) new requirements. So you won't see FIPS 1806-4 support in the FIPS module until and if we're able to do a new OSS based validation to succeed #1747. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit
On 04/27/2015 02:47 AM, Annuradha Gupta wrote: Hi I wanted to understand FIPS 140-2 support, on Mac 32/64 and iOS 32/64. Which version of OpenSSL will have the required support for these platforms. Mac support is unknown (not in process and no prospective sponsors). 64bit iOS is pending, held up by the hostage issue[*]. All the hands-on testing is done and we're in the wait-on-the-bureaucracy phase. My best guess at this point is another two or three months. That revision will probably be called 2.0.10, but it won't be a revision of the #1747 validation. Instead it will be the first revision of the pending new salvage edition validation[**]. It will be the same tarball as if we were allowed to update the #1747 validation directly, though. -Steve M. [*] http://openssl.com/fips/hostage.html [**] http://openssl.com/fips/ransom.html -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: Can I still use OpenSSL FIPS v2.0 (#1747) for FIPS 140-2 certified new products?
On 08/15/2014 01:10 PM, xxiao8 wrote: I have read various info regarding OpenSSL and FIPS 140-2, however I still have this very basic question: For a new product, can I still use OpenSSL FIPS v2.0(#1747, Policy 2.0.7) to get FIPS 140-2 certification these days(i.e. after I.G 9.5/9.10)? My platform is Linux 3.x/ARMv7/OpenWRT and I plan to use OpenSSL FIPS v2.0 #1747 as a static module(unchanged) so my code can use it for crypto operations. The openssl-users list would be more appropriate for this query. BTW there is no such thing as FIPS 140-2 certification, you mean FIPS 140-2 validation which is a very specific formal process. The #1747 validation remains in effect, so if you use that module as-is in full compliance with the Security Policy then you're covered. If you're trying to do a copycat (private label) validation of your own using that module source code, good luck. You will have to deal with a number of new requirements that have been introduced since the #1747 validation was obtained, among the I.G. 9.10, SP800-131A, and FIPS 146-4. The FIPS capable OpenSSL will need non-trivial modifications as well to match. All together that adds up to a pretty significant hit in cost and time which is why we've not done any private label validations in 2014 yet. You mention a specific platform that is not included as one of the formally tested platforms (Operational Environments) for the #1747 validation. It could be that you want to use the #1747 validation as-is and just want to add an appropriate Operational Environment to that validation. That is possible and in fact that's how the #1747 validation came to have so many platforms (we're working on the 101st platform now). It's not free though; figure about US$15K which is either a bargain (for commercial vendors relative to any alternatives) or cost prohibitive (for the small business). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL engine support in OpenSSL FIPS Object Module
On 07/05/2014 02:09 AM, Jayalakshmi bhat wrote: Hi All, We want to support a hardware accelerator on our device. We are using OpenSSL with OpenSSL FIPS Object module. I wanted to know if we can add engine support in OpenSSL FIPS Object module. I welcome all valuable inputs. First, please don't cross post to both lists. The openssl-users list would suffice. You've more or less asked this question already. The OpenSSL FIPS Object Module source code is available under an open source license, so subject to the very liberal terms of that license you can hack that code to your hearts content. However... The FIPS 140-2 Level 1 validation of that module (certificate #1747) is a different thing entirely. The instant you touch the code that validation no longer applies. The code without the validation is worthless (it does nothing regular OpenSSL doesn't do better, faster, more securely). A new validation will be necessary. You will find such a validation a significant challenge even without the source code mods you contemplate. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Expansion of the OpenSSL team
I am pleased to announce some changes to the OpenSSL team (see https://www.openssl.org/about/): Andy Polyakov has been added to the core team Tim Hudson has been added to the dev team Viktor Dukhovni has been added to the dev team We anticipate some more additions in the near future. The previous and new team members are currently discussing plans for tacking the multiple issues we are all eager to address. Those plans are ambitious and the issues are complex so those discussions are taking longer than we'd like. We'll have more announcements as those plans converge on some sort of coherence. In the meantime we greatly appreciate the patience and support shown by so many of you in the OpenSSL community. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Which of HOW TO CONTRIBUTE TO OpenSSL in README is still relevant?
On 04/28/2014 07:31 AM, Dr. Stephen Henson wrote: ... Unknown. Can someone comment on this? With respect to U.S. export controls (EAR), open source cryptographic code contributions appearing on the publicly visible OpenSSL web site appear to fall under the TSU exception to ECCN 5D002. The necessary notification for that code to the Commerce Department was by OSF done years ago and is renewed from time to time (even though such renewal is not explicitly required). U.S. contributors do need to be *very* careful about crypto code that is exported anywhere. Note that in EAR/ITAR parlance export essentially means potentially seen by non-U.S. persons. So for instance posting such code to github would be an export, as would E-mailing to anyone overseas. When in doubt consult your own attorney, as U.S. export controls are more than a little nonsensical. TBH it's such a mess that I quit working directly on crypto code myself after unwittingly attaining the dubious and expensive distinction of becoming a registered international arms dealer (mandatory registration with the State Department DDTC per ITAR). In short, while your odds of actually being prosecuted are probably low, it's damn hard to be a U.S. citizen and lawfully work on open source cryptography. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: The Future of OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 01:30 PM, Hanno Böck wrote: Hi, ... Basically, what bothers me most is that right now it seems to me the openssl project is unresponsive. There are people out there who want to improve things. There are people who want to help. And most likely there are people asking themselves if they'd better invest their time in improving openssl or helping out libressl. So to the openssl devs: Please give some answers. All true; but I would like to note that the OpenSSL team is in fact currently very active, more so than has been the case for years. You just can't see it quite yet. They are engaged in a reorganization and discussions in preparation for launching a revitalized newer, better, larger, more effective and more inclusive OpenSSL team. Some big changes are coming and I would like to beg the indulgence of the OpenSSL community for a bit longer. - -Steve M. - -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNX/rQACgkQJBALAc5pQk7ziwCfWvpZ3tZkwWNl4CbJJNPGe373 fZIAoM8tfOuClHzZ4qDu6FdgSi8BDoGp =Ve5U -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Getting patches applied
On 04/10/2014 03:22 PM, Kurt Roeckx wrote: Hi, I've seen many examples of patches being submitted but never getting applied. For some problems there are actually multiple people submitting a patch for the same issue, and none of them getting applied. What is the problem getting them applied? Not enough people to do the reviewing? People who have commit access don't have enough time, or different priorities? Yes, yes, and not necessarily. While I'm not one of the OpenSSL committers, I've had the honor and privilege of being close enough to some of the action to have an appreciation for the heavy burden of responsibility they carry. IMHO user community contributions, and the care and effort that went into them and the desire and need for them, are not being callously disregarded. It's just that after all the urgently necessary activities are covered there isn't a lot of discretionary time left over. OpenSSL hangs by a thinner thread than most people realize. Since contributions are as likely to introduce problems or vulnerabilities as code authored directly by the OpenSSL team, I think you can expect even more caution for awhile. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Getting patches applied
On 04/10/2014 05:36 PM, Kurt Roeckx wrote: ... While I'm not one of the OpenSSL committers, I've had the honor and privilege of being close enough to some of the action to have an appreciation for the heavy burden of responsibility they carry. IMHO user community contributions, and the care and effort that went into them and the desire and need for them, are not being callously disregarded. It's just that after all the urgently necessary activities are covered there isn't a lot of discretionary time left over. OpenSSL hangs by a thinner thread than most people realize. So my the question is basically what we can do so that more of the patches get applied in a reasonable time? For instance, would it help to use Signed-off-by or Reviewed-by patches in some git tree? If I'm going to put time in this, will someone take the time to get them applied? With the very, very important caveat that I'm not one of the people who directly carry this burden: There is certainly room for improvement in the process by which patches are reviewed and merged into OpenSSL. For the more straightforward bug fixes and minor changes it might be useful to have a mechanism where a patch could be approved by multiple people and then committed to OpenSSL almost automatically. Obviously this wouldn't work for significant changes like whole new APIs and infrastructure mods. The multiple people could be a sufficiently large and diverse group of serious and committed stakeholders, both OpenSSL team members and others. Volunteers? Of course, a process like that wouldn't necessarily prevent future vulnerabilities like the Debian PRNG issue or the heartbeat bug. Even gross bugs are only truly obvious in hindsight. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL-FIPS - incore and ia32
On 03/26/2014 05:25 PM, Mark Hatle wrote: On 3/26/14, 2:41 PM, Steve Marquess wrote: On 03/26/2014 12:30 PM, Mark Hatle wrote: Looking at the fips_canister.c I see that ia32 (32-bit and 64-bit) systems are not enabled ... Would it be possible to add this change to the fips_canister in a future version, or would this require a full re-validation of the openssl-fips? A change letter update would suffice. That's still a non-trivial expense, in both time and money, but not nearly as expensive as a full validation. Do you have an idea of the potential expense and time it would take to do this? We're certainly interested in getting this done in the community. I can ask my management to help pay for this change, but I need some idea as to a reasonable cost. Rough rule of thumb, US$15K (for an uncomplicated platform) and about three months. We don't have much control over the time, though, and disruptions in the validation testing process are not uncommon. For instance, we've had a number of platforms here stalled for three months just waiting for official test vectors so we can start testing, and those poor sponsors will still have to wait another three months or so at best. We absorb the risk of complications, costwise, but can't do anything about schedule slips. For most of our clients the time hurts more than the money. Three months is a long time when you're losing sales. Note that cost is independent of the nature or complexity of the code change, and many changes will not be permitted at all (for instance, we're usually unable to backport vulnerability fixes). Platform portability code changes that don't touch the actual cryptographic algorithm implementations and are clearly specific to the new platform(s) usually are possible. (We don't want to do it ourselves, we want everything we do to come from the openssl.org.) You actually can't do this type of change letter mod yourself, only the vendor of record (OSF) and the original test lab (InfoGard in this case) can do that. So it's a bit of a captive market which we try not to abuse. We are aware that the sponsors of the original very difficult and expensive #1747 validation (DARPA, DHS, and other government and commercial sponsors) wanted that validation to be widely used in just the way you're trying to use it. An open source based validated module benefits a large community. Note BTW that OSF (the OpenSSL Software Foundation) and openssl.org are not synonymous. The former is a legal entity formed for the purpose of engaging in commercial contracts and the like (performing FIPS 140-2 validations, for instance, which require lots of paperwork). Some but not all of the members of the less formal OpenSSL project are engaged in OSF activities. Until then, my only other option is to use something like qemu to run the linked application to get the necessary checksum, in order to recompile/relink the final binary. Is modifying the fipsld script in such a way acceptable for FIPS compliance? You can't modify the fipsld present within the openssl-fips-2.0.N.tar.gz source distribution (*no* such modifications are allowed), but you can use *another* external modified fipsld script that respects the requirements of the Security Policy (i.e., verify the *.sha1 digests as you go). What I am doing right now: ... * download (and verify) openssl-fips-2.0.5.tar.gz, openssl-1.0.1f.tar.gz * extract, build, install, openssl-fips (no modifications) using the rules from the UserGuide. You built the FIPS module exactly as required; good. That process really matters including even the apparently silly parts like starting with a snail-mailed CD. What follows is far less critical. ... * modify the fipsld script to call 'openssl sha1 -hmac ' ... So -my- interpretation is that I didn't modify the openssl-fips sources, I modified the install location and fipsld script -after- it was built.. but I ensure that the steps performed are technically the same. So this is OK. Does this seem reasonable? It's allowed. As noted earlier you can modify the fipsld scrip used for creating the final application executable (e.g. libcrypto) as long as the *.sha1 digests are verified. For cross-compilations we typically use an shell script to set environment variables, for instance: http://opensslfoundation.com/testing/validation-2.0/platforms/android-x86/setenv-android-x86.sh which usually avoids the need for such hacks. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager
Re: OpenSSL-FIPS - incore and ia32
On 03/26/2014 12:30 PM, Mark Hatle wrote: Looking at the fips_canister.c I see that ia32 (32-bit and 64-bit) systems are not enabled with the cross compiling when using 'Linux'. But ia32 (32-bit) is enabled on Android systems. This is preventing me from cross compiling and using the fipsld with the incore script to link my applications. I modified fips_canister.c as shown in the attached patch. So far in my testing (building various applications and running them on the target system), the incore script is working correctly. Would it be possible to add this change to the fips_canister in a future version, or would this require a full re-validation of the openssl-fips? A change letter update would suffice. That's still a non-trivial expense, in both time and money, but not nearly as expensive as a full validation. Until then, my only other option is to use something like qemu to run the linked application to get the necessary checksum, in order to recompile/relink the final binary. Is modifying the fipsld script in such a way acceptable for FIPS compliance? You can't modify the fipsld present within the openssl-fips-2.0.N.tar.gz source distribution (*no* such modifications are allowed), but you can use *another* external modified fipsld script that respects the requirements of the Security Policy (i.e., verify the *.sha1 digests as you go). That point is a little confusing. When the FIPS module was first validated only native compilation was supported. Later we worked out how to support cross-compilation, and the precedent of using an external fipsld (and/or incore) utility for building the FIPS module has since been well established. Fipsld and incore (and some other files) are really part of the build environment, like the compiler and linker, and don't need to be in the source distribution tarball proper. If/when we ever do another open source based validation we'll probably leave those build utilities out of the FIPS module tarball entirely. Until then any change to the tarball contents means (at best) a change letter update, even something as trivial as a change to a comment. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL obsolescence query
On 02/07/2014 12:47 PM, Trebilcock, Richard wrote: Hi, I am an ILS Engineer working for CGI IT UK Limited. At the present time I am looking at software obsolescence issues that relate to the CGI project I am working on. On this project we use OpenSSL FIPS 1.2 and FIPS 1.2.4. In order to support our process of monitoring software obsolescence I would be grateful if you could provide me with the following information with respect to OpenSSL FIPS 1.2 and FIPS 1.2.4: 1. End of Product Support date 2. Superseding Product if support for PDFtk 1.12 or FIPS 1.2.4 is no longer available. Your assistance with this matter is most appreciated. Regards, Richard Richard, this query would be more appropriate for the openssl-users list. PDFtk: no idea, that is product quite separate and distinct from OpenSSL. I didn't know it had any support for FIPS 140-2. OpenSSL FIPS 1.2 and FIPS 1.2.4 are both the OpenSSL FIPS Object Module v1.2, validation certificate #1051. The latest revision of that module is 1.2.4. That module, including all revisions, remains validated (though as with all validated modules it is now subject to the new SP800-131A and FIPS 186-4 restrictions effective Jan 1 2014). However, the 1.2 FIPS module is only usable with OpenSSL 0.9.8 releases. OpenSSL 0.9.8 is still supported as a sustainment release, meaning vulnerability bugfixes, but is effectively obsolete for many purposes. For instance, it does not support TLS 1.2. The OpenSSL FIPS Object Module 2.0, validation certificate #1747, should be used for any new development and careful consideration should be given to upgrading any FIPS 1.2/OpenSSL 0.9.8 based products to FIPS 2.0/OpenSSL 1.0.1. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL support query
On 02/07/2014 06:27 AM, Trebilcock, Richard wrote: Good Morning, I am an ILS Engineer working for CGI IT UK Limited. At the present time I am looking at software obsolescence issues that relate to the CGI project I am working on. On this project we use the OpenSSL products as tabulated below. In order to support our process of monitoring software obsolescence I would be grateful if you could provide me with the information in the table below. I have provided a key to explain the information that I require. Item Name Version Number End of Product Support date Superseding Product if support no longer available OpenSSL FIPS 1.2 ... Richard, as you can see your message didn't render very well on the openssl-dev mailing list. You probably sent it using html. I see mention of the OpenSSL FIPS Object Module, so I'll have a crack at responding if you'll resend in a text friendly format. Also, the openssl-users list would be more appropriate for this kind of query. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS certification
On 02/03/2014 09:30 AM, Leon Brits wrote: Steve, Thanks for your help so far. Q: How is this certification of the algorithms done? Our device only has a USB interface acting like a smartcard so will the lab (or OSF) use our cryptoki/CSP interface(s) to validate the algorithms or should we make a development board, which has a serial interface, available. Note that we are aiming for FIPS 140-2 level 3 certification so the device is potted (not the devboard). The algorithm testing consists of a set of data files, the request file supplied by the test lab and the response files generated from the input request files on the test device (IUT Implement Under Test). Collectively those algorithm test files are often called test vectors. The structure of the test vectors and the typical processing process is documented in Appendix B of the FIPS module User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf Actual test vectors generated in the course of formal testing can be found at: http://opensslfoundation.com/testing/validation-2.0/testvectors/ Note the complete set takes nearly a quarter GB of writable disk space. We use NFS or CIFS when we can, and sometimes need to use mountable storage devices. That typical processing assumes an environment with POSIX support and an interactive command shell. A more creative approach is required for some unusual or limited platforms. Fortunately the goal of the algorithm testing is just the generation of the response files, and the means by which those are generated isn't tightly constrained. In many cases the vendor can generate those in an internal setting, in which case the vendor is asked to sign a form attesting that the response files were generated on the appropriate target device using the appropriate FIPS module. When the canned test suite software supplied with the OpenSSL FIPS Object Module (fips_algvs generated from the build_algvs Makefile target) cannot be used directly, it is permissible to use custom test software to read data from the request files, feed it to the FIPS module on the target device, and collect the output in response files. In the most extreme cases of very limited embedded devices we've had to do that one line at a time. Usually it's sufficient to hack the original test suite code to accommodate specific limitations of the thetarget device. In many cases the target device in a production configuration lacks any means to exchange test vector data between the target device and the outside world, and/or any sort of shell access. In such cases it is permissible to enable or install normally absent diagnostic/maintenance/development access and/or hardware interfaces such as serial ports. In your specific case either option should be acceptable. You could either write test software to utilize the cryptoki/CSP interface, or you could use a development board. That's assuming the development board has the same OS and processor as the production device of interest. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS revalidation after openssl vulnerability fix
On 01/29/2014 11:29 PM, sam1982 wrote: Thanks Stevan for prompt reply. Just to confirm, you are saying that even if I upgrade openssl to 1.0.1f from 1.0.1c, fips validation which is done on older version of openssl libeay32.dll(1.0.1c) holds true. There is no change in FIPS object module and validation is already done around 4 months ago. Please confirm my understandings. Ajay Ajay, no disrespect intended but you're in way over your head. You need to start by understanding what a FIPS 140-2 validation is and the critical distinction between the OpenSSL FIPS Object Module 2.0 (the FIPS module) and other application software such as OpenSSL. Clear your calendar for a day or so, find a comfy chair, and read both the Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf and the FIPS module User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf Reading that stuff is a long slog, I know, but my attempt at a succinct response to your question wasn't adequate. On 01/29/2014 11:52 PM, sam1982 wrote: I am reconfirming my understandings since there is some confusion around ... -We have done FIPS validation from a private lab, but before discussing with them we want to hear from openssl. ... Ok, so you've confirmed my suspicion that you're attempting your own private label validation. You *really* need to ask these questions of the accredited test lab you're using for that work, as each lab has a distinctive approach. You can't mix and match input from multiple labs in one validation submission; the result would be even more incoherent than usual. Also (of critical importance) -- your test lab hay have defined the module boundary differently than was done for the OpenSSL FIPS Object Module. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS certification
On 01/30/2014 04:00 AM, Leon Brits wrote: Hi all, I've used the FIPS Object Module v2.0.2 in a product which need to be FIPS 140-2 certified. One of the steps in this process is to certify the module algorithms on our platform since it is not one of the platforms which are covered by certificate #1747. I have all these questionnaires from the certification lab about the algorithms and some of the answers I simply do not know. E.g. for RSAPSS they want to know what the salt length is. As far as I know this is dynamically determined based on the modulus size and digest (correct?). Anyway, I do not know what value to fill in as an answer. So is it possible to get access to these algorithm documents which OpenSSL also had to complete for their certification? I'm going to answer your question with what you think you want, but I want to first caution you that what you really need isn't what you think you want. You are trying to take the OpenSSL FIPS Object Module source code and obtain your own private label validation (that's fine BTW, one of the intended uses of the open source based validations). But, the fact that your test lab is asking you those questions means that they aren't familiar with the OpenSSL FIPS Object Module, and neither you nor they are familiar enough with the code to figure it out. So that effort is going to be more difficult than usual for a private label validation, and you're going to be paying for that effort (one way or the other). It is true that a FIPS 140-2 validation entails a lot of arm waving, but some understanding of the actual code and algorithm implementations is still necessary. That said, what you think you want to know is this: the CAVS algorithm test forms used for the #1747 validation are at: http://opensslfoundation.com/testing/validation-2.0/forms/ The test vectors and use thereof are documented in the FIPS module User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf and many of the actual test vector data sets used for the #1747 testing (and for *other* validations) can be found at: http://opensslfoundation.com/testing/validation-2.0/testvectors/ You'll want one specific to the #1747 code base, so for instance: http://opensslfoundation.com/testing/validation-2.0/testvectors/OE46.results.tar.gz You will find rather quickly that factors like SP800-131A, the deprecation of Dual EC DRBG, and the I.G. 9.10 issue (http://opensslfoundation.com/fips/ig95.html) mean that you can't use these test vector formats and the OpenSSL FIPS Object Module 2.0,2.0.1,...,2.0.5 code as-is. So don't say I didn't warn you :-) -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS certification
On 01/30/2014 07:37 AM, Leon Brits wrote: Steve, Thanks for the information. About your last paragraph, I have to ask: The requirements for this product only uses a subset of the algorithms provided by the FIPS Object Module and the DualEC DRBG and RSA1024 etc. is not supported via our API. So SP800-131A does not affect me. My assumption is that because of this we do not have to test them even though they are present in the FIPS Object Module. True? So apparently you're substantially hacking the OpenSSL FIPS Object Module code. You won't need to test an algorithm that is completely absent (entirely absent, not just disabled), of course, but keep in mind that apparently common sense software engineering assumptions may not apply. So I can't really help you there; that's something you'll need to carefully review with your test lab. You can't obtain a validation without the participation of an accredited test lab, so your first step is to pick one. There can be multiple correct answers to questions like this, in the sense that you can take the same code to different test labs (as we have done multiple times) and end up with very different answers and approaches to various requirements. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS certification
On 01/30/2014 08:49 AM, Leon Brits wrote: Steve, We are talking past each other - sorry for that but that is the way people like me get to understand these things. First of we have not changed any code of the FIPS Object Module. We simply do not use all of the algorithms based on requirements. The application linking the libcrypto.so, enforce that only required and allowed cryptographic calls is made to the Module. So, if I understand you (or maybe again not), we must test everything in the Module even if we do not use them? And this is why the new directives will give me problems - right? Hmmm. So you're obtaining your own private label validation. Since you're doing a validation from scratch, you have two options. One is to just remove the algorithms you don't want. The other is to keep the code as-is and designate the algorithms you don't want and don't plan to use as non-Approved (you'll still need to identify them though). Background: We were hoping to use your certification of the algorithms as part of our products validation. Using your certificate numbers in our SP in section 2 for Cryptographic Functionality. That's known as OEMing certificates. If you look through extant validations (note Google indexes PDFs) you'll see more than a few proprietary validations that reference algorithm certificates from the #1747 validation. You'll need to use unmodified code from the #1747 validation (almost certainly; some labs are a little more flexible on some mods) and need an OEM certificate that matches that code and your platform. Then you'll still need to address the IG 9.10 issues at least, meaning code mods which (again depending on the lab) may well mean you can't OEM algorithm certs from #1747. If your only objective is to end up with a FIPS module that is functionally identical to the OpenSSL FIPS Object Module, for your platform(s) of interest, there is a much easier way. You can have your platform(s) added to the #1747 validation. That's how that validation came to have 80 platforms (with another dozen or so on the way) :-). Our rough cost for the change letter addition of a platform to #1747 is $15K and 2-3 months. Compare that to the cost and time for any type of new validation. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS revalidation after openssl vulnerability fix
On 01/29/2014 01:44 AM, sam1982 wrote: We were using openssl 1.0.1c, built fipscanister.lib which is linked to libeay32.dll and ssleay32.dll. The output files ( libeay32.dll ) were submitted for FIPS validation. Now after openssl 1.0.1f, we need to upgrade ssl library to version 1.0.1f. But fips validation is already done on 1.0.1c. Do we need FIPS revalidatation even security patch is in OpenSSL ? We are patching openssl and the cyypto module. This makes no sense. If you were using the OpenSSL FIPS Object Module (certificate #1747), then the OpenSSL version is irrelevant to that FIPS validation (OpenSSL proper is out of scope). If you've gone to a test lab and obtained some sort of private validation based on OpenSSL code, then you need to consult with that lab. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: No fips and --with-fipsdir arguments in OpenSSL 1.0.0l configure script.
On 01/08/2014 07:48 AM, Stephan Mueller wrote: Am Mittwoch, 8. Januar 2014, 13:36:37 schrieb Dr. Stephen Henson: Hi Stephen, On Wed, Jan 08, 2014, Abdul Anshad wrote: Hello All, I noticed in trying to build OpenSSL 1.0.0l that, Configure doesn't accept the fips and --with-fipsdir= arguments. But, the OpenSSl 1.0.1f and OpenSSL 0.9.8y accepts the same. Does that mean that the OpenSSL 1.0.0l wont support fips mode ? is the branch OpenSSL 1.0.0 still under fips validation ? OpenSSL proper has never been FIPS 140-2 validated and never will be. The OpenSSL FIPS Object Module v2.0 is the thing that is validated, and that's a separate and distinct software component. This question here is which versions of OpenSSL are compatible with the FIPS module. The descriptions of the OpenSSL FIPS security policy (e.g. section 4.2.3) hint to using the regular OpenSSL library version which can be compiled to use the fipsified OpenSSL version as a crypto-backend. IIRC this is what the above mentioned configure options hint to. You mean the FIPS module User Guide, not the Security Policy. I'm not sure what hint you're getting from section 4.2.3 which states: Once the validated FIPS Object Module has been generated it is usually combined with an OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 release can be used for this purpose. I thought that rather specifically excluded 1.0.0 along with all other releases that aren't 1.0.1. Should that paragraph also state Releases other than 1.0.1 cannot be used for this purpose? -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: No fips and --with-fipsdir arguments in OpenSSL 1.0.0l configure script.
On 01/08/2014 08:21 AM, Stephan Mueller wrote: ... Once the validated FIPS Object Module has been generated it is usually combined with an OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 release can be used for this purpose. I thought that rather specifically excluded 1.0.0 along with all other releases that aren't 1.0.1. Should that paragraph also state Releases other than 1.0.1 cannot be used for this purpose? I withdraw my comment. You are right that all refers to 1.0.1 only without applying to any other version. Ok. If there's a way we can improve that document I want to know. It's a complex topic. When OpenSSL 1.0.2 is released the User Guide will be updated to state 1.0.1 and 1.0.2 as the current FIPS module will also be compatible with 1.0.2. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl integrity checking logic
On 12/27/2013 05:37 PM, Ursa Major wrote: Hi , I am new to openssl, and am very keen to learn how how the integrity checking is performed. In my understanding, the incore computes the integrity of the codes and placed them in an .hmac file (I am not sure if my understanding is correct). How is the text segment and data segment being loaded for the integrity test (they should be the exact copy of the 'executables', but won't that be a circular proving as it embeds itself within itself)? What are the contents of the segments? What is the mechanism of the working? IMHO this question would be more appropriate for the openssl-users list. I presume you're asking about the OpenSSL FIPS Object Module integrity test, which is part of the mandated POST (Power On Self Test) process. The implementation of that integrity test is documented at a conceptual level in the FIPS module User Guide: http://www.openssl.org/docs/fips/UserGuide-2.0.pdf Simply put, at build time an HMAC-SHA1 digest is calculated over the TEXT and RODATA segments of object code, and stored in the FIPS module. One or both of two different techniques can be used for determining that digest. Typically the premain intermediate executable is used for native compilation and an incore utility for cross-compilation. At runtime the stored digest is calculated over the TEXT and RODATA segments of live memory and compared with the previously stored value. That mechanism is of course also fully exposed in the source code: http://www.openssl.org/source/openssl-fips-2.0.5.tar.gz In particular look at fips.c, fips_premain.c, fipsld, and incore (for ELF). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL ECCN query
On 12/09/2013 07:35 AM, Trebilcock, Richard wrote: On the CGI IT UK Limited project I am currently working on, we are looking to export OpenSSL as part of the overall software deliverable. As part of this process, we need to know whether OpenSSL is of United States origin, and if so what the ECCN number is, and does an ENC licence also apply? I would be most grateful if you could provide me with this information. However, failing this, if you could direct me to where I might find the information I require this would also be very helpful. OpenSSL is not of U.S origin, as in it was developed and is maintained outside of the U.S. by non-U.S. persons. I'm the only U.S. citizen or resident with any direct involvement in OpenSSL and I'm not part of the OpenSSL team proper (no commit privileges). However, be careful as U.S. export controls are tricky. If I download crypto from outside the U.S. and then immediately forward it to a non-U.S. destination then I may have committed an export control violation. So where the crypto came from initially isn't relevant, it's whether it leaves the U.S. Yes, that doesn't make any sense. But that's why you need to be very careful. You really need to consult with competent legal counsel specializing in export law. That said you may find Appendix F of the OpenSSL FIPS module User Guide of use: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf Keep in mind that the FIPS module is *not* the same as OpenSSL and that I'm not qualified to give legal advice. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS verification for AES XTS
On 11/25/2013 05:51 AM, Leon Brits wrote: Hi, I need to perform some Known-Answer-Tests with every start-up of my system. ... You're trying for your own private label validation. The OpenSSL FIPS Object Module was a good model for that (by design), but note the CMVP has recently introduced some new requirements that raise the pain threshold. On 11/26/2013 09:34 AM, Leon Brits wrote: I also need to test CCM and GCM mode and realized that I cannot use the CLI for that. So, I started writing a program to do the tests (wanted to avoid this). ... You might want to look at the existing code for handling all required FIPS 140-2 algorithm testing. See the FIPS module User Guide: http://www.openssl.org/docs/fips/UserGuide-2.0.pdf Appendix B. That will be the easy part... -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Documentation issue?
On 09/27/2013 09:38 PM, karanpopali wrote: In the FIPS User Guide (http://www.openssl.org/docs/fips/UserGuide-2.0.pdf), there is example to set the default DRBG type. It uses DRBG type as NID_hmac_WithSHA256, but it should be NID_hmacWithSHA256. Example from UserGuide: ./config -DOPENSSL_DRBG_DEFAULT_TYPE=NID_hmac_WithSHA256 \ -DOPENSSL_DRBG_DEFAULT_FLAGS=0 Good catch, thanks. Fixed in revision to be posted soon. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3089] Building OpenSSL 1.0.1e with FIPS on Win64A
On 07/10/2013 03:46 PM, Graeme Perrow via RT wrote: I am trying to build the FIPS Object Module for Windows on an AMD64 machine. I started with the instructions in section 4.3 of the User Guide 2.0, and was able to build the FIPS module itself, but the instructions for building a FIPS-capable OpenSSL are specific to 32-bit Windows. I adjusted the build procedure as follows: ... Also (and more importantly), if I have to modify the build procedure for the FIPS-capable OpenSSL but not for the FIPS Object Module itself, does that mean my Module is not FIPS 140-2 validated? I think this is more of a user list question. OpenSSL proper (as opposed to the OpenSSL FIPS Object Module) is out of scope of the FIPS 140-2 validation procedure, so you can hack it to your hearts content. You need to embed the HMAC-SHA1 integrity check (incore) digest in the FIPS module embedded in the shared library executable file, but you aren't constrained to a specific command or process. Also note that you must verify the SHA1 digest of the FIPS module files (as is done automatically in the fipsld script). Sort of moot if you just generated those files, but a technical requirement nonetheless. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3089] Building OpenSSL 1.0.1e with FIPS on Win64A
On 07/10/2013 03:46 PM, Graeme Perrow via RT wrote: I am trying to build the FIPS Object Module for Windows on an AMD64 machine. I started with the instructions in section 4.3 of the User Guide 2.0, and was able to build the FIPS module itself, but the instructions for building a FIPS-capable OpenSSL are specific to 32-bit Windows. I adjusted the build procedure as follows: ... Also (and more importantly), if I have to modify the build procedure for the FIPS-capable OpenSSL but not for the FIPS Object Module itself, does that mean my Module is not FIPS 140-2 validated? I think this is more of a user list question. OpenSSL proper (as opposed to the OpenSSL FIPS Object Module) is out of scope of the FIPS 140-2 validation procedure, so you can hack it to your hearts content. You need to embed the HMAC-SHA1 integrity check (incore) digest in the FIPS module embedded in the shared library executable file, but you aren't constrained to a specific command or process. Also note that you must verify the SHA1 digest of the FIPS module files (as is done automatically in the fipsld script). Sort of moot if you just generated those files, but a technical requirement nonetheless. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3074] On PA-RISC, OPENSSL_cleanse() causes crash when called from outside libcrypto, patch included
On 06/16/2013 05:33 AM, Mitch Blank via RT wrote: I got a strange bug report claiming that openssl md5 was dumping core on old parisc hardware. Sure enough, it was generating the correct result but then crashing... It turns out the problem is rather subtle. ... Not sure if this fix is appropriate for 32-bit parisc. I don't have an environment for testing that at the moment. ... Unfortunately it's been several years since any of the OpenSSL team have had access to any PA-RISC systems. I used to have such access to run tests for Andy but no more. So unless someone else can develop and thoroughly test a solution PA-RISC is effectively an unsupported platform. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3074] On PA-RISC, OPENSSL_cleanse() causes crash when called from outside libcrypto, patch included
On 06/16/2013 05:33 AM, Mitch Blank via RT wrote: I got a strange bug report claiming that openssl md5 was dumping core on old parisc hardware. Sure enough, it was generating the correct result but then crashing... It turns out the problem is rather subtle. ... Not sure if this fix is appropriate for 32-bit parisc. I don't have an environment for testing that at the moment. ... Unfortunately it's been several years since any of the OpenSSL team have had access to any PA-RISC systems. I used to have such access to run tests for Andy but no more. So unless someone else can develop and thoroughly test a solution PA-RISC is effectively an unsupported platform. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: turning on FIPS mode for different applications- Does POST takes place every time FIPS_mode_set() is called?
On 04/15/2013 03:16 AM, Cipher wrote: Hi, According to FIPS security requirement, untill POST and other tests are successful in FIPS mode, no crypto interfaces should be up. Now, i have a doubt here. I have two daemons, sshd and apache. I turn on FIPS in *sshd*, which runs POST and other algorithm tests and then listens on port 22 in FIPS mode. Now if i turn on FIPS mode in *apache*, will the POST and other tests will be run again? If so, i am in trouble since my ssh interface is already up which is a crypto interface. How to sync up the power on tests and other tests for different applications? This is really a question about how shared libraries work, and really should have gone to the user list. Each process, sshd and httpd, copies the writable segments of the libcrypto library (which contains the FIPS module) into private memory. So each such process performs actions which modify that private memory (such as enabling FIPS mode) entirely independently of other processes. The same is true for static linking, of course, as each process has separate copies of both readonly and writable code. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3029] Misspellings in the openssl license document
On 04/04/2013 03:01 PM, Coe, Brian via RT wrote: I was reviewing the license doc and saw some errors. Corrected words in are in bold and are red. I tried to submit this through RT but had some problems. I have also attached an RTF in case the formatting fails to go through email. License ... I'll hazard the guess that you're a native American English speaker, as am I. The original SSLeay licence was written by Commonwealth English speakers, and they do tend to spell things a bit differently. In Americanese license is both a noun and a verb, whereas in the Queen's English licence is the noun and license is the verb. Some of my British colleagues have explained that it often doesn't matter if Americanized spelling is used, but in this case I think we should respect the original presentation. I find is useful to set my spellchecker to British English, as intuition can be misleading. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3029] Misspellings in the openssl license document
On 04/04/2013 03:01 PM, Coe, Brian via RT wrote: I was reviewing the license doc and saw some errors. Corrected words in are in bold and are red. I tried to submit this through RT but had some problems. I have also attached an RTF in case the formatting fails to go through email. License ... I'll hazard the guess that you're a native American English speaker, as am I. The original SSLeay licence was written by Commonwealth English speakers, and they do tend to spell things a bit differently. In Americanese license is both a noun and a verb, whereas in the Queen's English licence is the noun and license is the verb. Some of my British colleagues have explained that it often doesn't matter if Americanized spelling is used, but in this case I think we should respect the original presentation. I find is useful to set my spellchecker to British English, as intuition can be misleading. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCB Authenticated Encryption
On 03/28/2013 10:31 AM, Matt Caswell wrote: On 27 March 2013 21:03, Ben Laurie b...@links.org wrote: The OSF is not actually the one that would benefit from such a licence, so the whole idea that it (or we) should pay for one seems weird to me. Well, I wasn't actually suggesting that the OSF should pay for it itself, merely that the OSF could be the conduit for organising the licensing (in much the same way as it has been the conduit for organising the FIPS certification). The licensing only impacts US users of OpenSSL (as I understand it the patents under discussion here are only applicable within the US), and therefore the benefits would be largely felt by its customers -although in reality we all benefit by removing a blocker from integrating a mode into the code base with some significant advantages (OCB is supposedly significantly faster than GCM). If it comes to paying for it then I would hope that it may be possible to achieve sufficient corporate sponsorship to cover the costs (as I said in my original email). However, at this stage, all that is required is for someone to open a discussion with Phil Rogaway to see what can be achieved (maybe he will grant OpenSSL a waiver without any money changing hands at all). My suggestion is that that discussion could be initiated by the OSF (it seems a natural fit to me)...but really it could be anyone from the core dev team who can claim to speak for the project. I've sent Prof. Rogaway a note on this topic, but from his web site his intent seems pretty clear. It won't hurt to ask, though. As Ben noted we're not in a position to fund external costs for a product we give away for free. We have enough overhead expenses already for our modest budget. We can and do work with commercial or government sponsors that fund such expenses, but in this case I suspect money won't be the deciding factor. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki (docbook and...)
On 03/19/2013 07:49 PM, Pierre DELAAGE wrote: Hi Steve, My own experience in my company is that OpenOffice is perfectly suited for track changes in a collaborative env. Ok, allright, it cannot offer a line by line diff as in cvs systems, and return to specific version and so on, but the track changes can help. In my company, we were using latex...and track changes was in fact even more complicated with it. Not talking about tables and graphics that were painful. OpenOffice gives the advantages of various worlds : wisywyg, open format, quite robust for big doc compared to other similar products,.. xml based... Yes, I use Libreoffice heavily for legal documents as well the OpenSSL FIPS Module User guide. I haven't had access to Microsoft Office for years and am still able to exchange documents with our commercial clients, the compare document feature works well for that. OSF-Word-ODF conversions usually skew the format rendering enough to require merges from the modified Word document, but that can be done directly. But ODF is not well suited for an open source style collaboration. Several people can't easily modify the same document at the same time. By moving to git and docbook I'm hoping to more readily accommodate input from multiple collaborators. I used LaTex years ago, very powerful but way to fiddly for a relatively simple document like the FIPS User Guide. Be careful before going away back to some raw xml format...even if it is better than latex. Heh, well that's exactly what I'm doing now for better or worse. I'll have to make a point of no return decision soon as a first pass conversion to docbook is nearly done and I have new content changes that are needed. So it's an experiment that may not work out. a question : Are you thinking to use LyX editor to produce Docbook ? I'm too new at docbook to know yet. I'll start with a regular text editor. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 03:15 PM, Ben Laurie wrote: ... Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a man page. And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... That's an interesting suggestion; I'll kick it around and see what kind of traction it gets. Seems like a good idea to me. It does raise the question of how you export back to the docs tho... Agreed, as I think about this more I'm not seeing how we could do that (same documentation in .pod files in the source repository and as markdown in the wiki). There are tools of a sort to convert between docbook, pod, and markdown. I've played with a couple of them, but I think annoying little details will keep such tools from representing any net labor savings over manual cut-and-paste. So I'm left with the conclusion that in the wiki we should just link to the .pod based pages at openssl.org/docs/ Now a link from those to the discussion in the wiki might be useful (I think someone made that suggestion already). Perhaps as we accumulate enough content to bother linking to. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Wiki
With some trepidation, and considerable assistance from a small group of earlier adopters, I hereby unleash a new OpenSSL Wiki on an unsuspecting world: http://wiki.opensslfoundation.com/ There is a need for more and better OpenSSL documentation, and the hopeful theory here is that this Wiki will serve as a focal point for collecting useful content that over time will converge into a useful and comprehensive resource. Since I and some of the initial collaborators are still learning about Wiki management it will remain on a separate server and the opensslfoundation.com domain for an indeterminate trial period. If it evolves into a useful resource, and once we're comfortable with all the security and technical implications, then we will migrate it to a wiki.openssl.org domain. We're still in the process of migrating the legacy openssl.org server to a new home and this Wiki is another complication we don't need right now. There is some content already but new contributions are welcome. We'll be wanting to add some more administrators (sysops) too. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: Dear Steve, I was wondering whether the wiki could be fed at the beginning by all the Documents available at http://www.openssl.org/docs/;. Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a man page. And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... That's an interesting suggestion; I'll kick it around and see what kind of traction it gets. ... Moreover, for the lib, I suggest to separate the reference manual, describing and commenting each api call, from a kind of programmers' manual, that could describe how to use the lib for various purposes: such manuals were available for various programming tools in the past, and I have always been happy with those 2 complementary set of docs. For the command line set, and general config/install of the tool I suggest to do the same : - reference doc of each command and conf file - advanced users' manual covering install/config/and usage for various purposes. For example : I am using the command line tools as a very basic pki system to create certificate for my company. Those certs are produced by openssl to be used by openssl based applications such as stunnel or Apache: those usage are very common and should be documented in an advanced users manual. Sometime those certs have to be imported in client apps such as Mozilla Firefox or Thunderbird, or M$ Ie and outllook : I think the wiki/adv users manual could be a good repository for all this. And of course, although openssl is for advanced users, I think some pedagogic material on cryptography and its usage, and the benefit of using openssl to fulfill those needs, could be very useful. So you're suggest three major divisions: reference, programming, and didactic. Also an interesting suggestion. Well, in fact I am wondering about the best way to structure the chapters of the wiki : depending on that, we can hope to have something as clear and useful as possible, instead of being a bazaar of various things. I think that is the major part of the challenge: organization. On the other hand useful material can always be organized later. Personnally I can contribute to some command line tools usage case, although I have to admit that I feel a little bit intimidated to publish something on this prestigious wiki... Now that made me laugh :-) You're already contributed something with your thoughtful comments, don't stop now. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 10:47 AM, Pierre DELAAGE wrote: Dear Steve, I was wondering whether the wiki could be fed at the beginning by all the Documents available at http://www.openssl.org/docs/;. Very often people are able to comment, eg, a command page with some samples or error comments, instead of rewriting from scratch a man page. And this could be a way to only have one unique set of docs to maintain, and to refer to, instead of having two... ... I took a quick look to see what utilities might be available to convert between pod and mediawiki markup formats. pod2markdown (CPAN) is close but not quite there. Side note: we're in the process of converting the OpenSSL FIPS Object Module User Guide (all 200 min-numbing pages) to docbook format. So if anyone has any brilliant insights on the smart way to manage documentation that wants to be in all three formats I'd love to hear it. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki (docbook and...)
On 03/19/2013 04:04 PM, Pierre DELAAGE wrote: hmm, Steve I highly suggest that we have a look at ...OpenOffice and its various export filters. for mediawiki it is there : http://extensions.services.openoffice.org/fr/node/738 for Docbook the filter is embedded (never tested by myself..). Does it help ? Well, I haven't specifically tried Libreoffice filters for ODF to markdown but the OpenSSL FIPS User Guide is currently in ODF and that's what I'm trying to get away from. A major drawback of ODF is that is can't easily be version controlled in a collaborative setting. Now that there are several people contributing content to that document the ODF format is very limiting, hence the ongoing attempt to convert to docbook. That has turned out to be a bit of a challenge but I'm still hoping to pull it off. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Wiki
On 03/19/2013 04:59 PM, Matt Caswell wrote: On 19 March 2013 19:38, Steve Marquess marqu...@opensslfoundation.com wrote: I took a quick look to see what utilities might be available to convert between pod and mediawiki markup formats. pod2markdown (CPAN) is close but not quite there. The pod markup language is pretty basic. If something isn't already out there I would have thought a bit of clever regex search and replace would do the job. Yes, I think in principle conversion both ways is feasible, though by the time we automate the database I/O it gets complicated. The harder issue is how the markdown and pod content will be synchronized. What I'm not clear on is if you imported them onto the wiki how that would work in practice. It's kind of a one way operation - I can't really see how you could keep both the pod version and the wiki version going - they would inevitably start to divergeunless you could somehow keep wiki as the master and then import them back in again?? Alternatively we just ditch pod altogether - but that would lose the ability to create man pages (does anyone still read man pages)? That is the dilemma. Currently most of the documentation content at openssl.org is generated from source files in the repository, so there is no ready mechanism for feeding any changes back to that source. If the wiki works out we could conceivably drop the repository controlled files entirely. That approach hasn't been proven viable yet. So perhaps a content page in the wiki consisting of a link to the openssl.org static content so the talk page could collect commentary? BTW I still read man pages daily ... I have CRS syndrome (Can't Remember Sh^h^hStuff). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCB Authenticated Encryption
On 02/06/2013 09:43 AM, Salz, Rich wrote: There are actually two licenses. The second allows all software (even closed), but only for non-military use. I would say that's still a problem. For example, we could use OpenSSL on our network to provide acceleration for public DoD sites. Is that military use? Suppose it's for use on a CIA extranet? Suppose it's for use on an internal FBI network linking field offices to HQ? To the CIA doing the same thing internationally? How do I decide? How does the OpenSSL team set things up so that their (yes, yes, non-paying) customers don't do the wrong thing by default? If you want to limit the use of your invention, which is entirely your right, it is best to distribute it yourself. +1. The intent is noble but the practical implications get messy very quickly. For better or worse OpenSSL is very widely used, for good as well as evil, and the licensing situation is muddled enough as it is. Personally I think the existence and unrestricted availability of OpenSSL benefits the good far more than evil. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS AES self test
On 01/17/2013 04:33 AM, Ranjith Kumar A. wrote: HI, Can you please let me know where can i get the FIPS Openssl test vectors (for both req and resp) for AES algo. ... Please help me in executing Openssl FIPS (1.2.3) AES self test manually. Each platform (OE) for each validation requires a unique set of test vectors, so you will need to get those from your FIPS 140-2 accredited test lab after you have contracted to obtain a new validation. If you haven't done that yet there is no point in fooling with test vectors. For the 1.2 FIPS module that you reference pursuit of a new FPS 140-2 validation is no longer feasible, as the requirements have changed since the time that validation was obtained. You can see some representative 1.2 test vectors at: http://opensslfoundation.com/testing/validation-1.2/testvectors/ but, again, they are of no practical value today. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL openssl-fips-2.0.2 and private label
On 12/12/2012 09:59 PM, bhagyalekshmi r wrote: Hi Steve, Thank you very much once again. We have plan for FIPS 140-2 validation at later point of time. For a quick method to become NIST compliance, we wanted to use openssl-fips-2.0.2 along with OpenSSL library. Right now We dont want the full functionality of openssl-fips-2.0.2. We are looking for only certain crypto operations. Hence we are leveraging a partial code from openssl-fips-2.0.2. We had 2 concerns 1. Licensing and usage terms for openssl-fips-2.0.2 were not clear. Now you have cleared this doubt, thank you once again. 2. We were thinking FIPS certification is must for NIST compliance. Looks like they are separate. So I understand from your response, we can use openssl-fips-2.0.2 even if we are not going for FIPS 140-2 certification, but it can be NIST compliance What the heck is NIST compliance? Note FIPS 140-2 validation (n.b.: validation not certification) is a U.S. government and DoD procurement requirement (and possibly of the Canadian government as well). The only way you can satisfy that requirement is by using FIPS 140-2 validated cryptography, and that means complying with the terms of the relevant Security Policy. The Security Policy for the #1747 validation clearly says no modifications, period. If you are not using FIPS 140-2 validated cryptography -- and you won't be if you make any modifications to the FIPS module source code distribution -- then there is no point in using the FIPS module. It has no technical advantages over the regular non-FIPS capable OpenSSL, in fact it is inferior in terms of performance and real-world security. So in your case don't use modified FIPS module source code, it buys you absolutely nothing and costs you unnecessary complexity. Just use OpenSSL. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL openssl-fips-2.0.2 and private label
On 12/11/2012 10:09 PM, bhagyalekshmi r wrote: Hi All, I had one question regarding usage of openssl-fips-2.0.2. I want to use openssl-fips-2.0.2 to get NIST compliance for some crypto functionality*.* I don't want to go for FIPS 140-2 certification/validation. I want to use only a part of openssl-fips-2.0.2 module. Can I use some parts of openssl-fips-2.0.2 module along with OpenSSL library to use FIPS 140-2 functionality. Is it mandatory to get a private label if I make any changes to openssl-fips-2.0.2 module or if I want to use part of openssl-fips-2.0.2 module. If you touch it you own it -- make any modifications and you will need to obtain your own FIPS 140-2 Level 1 validation. The Security Policy is pretty clear about that. Note that private label validation is a term for a specific kind of FIPS 140-2 validation, one based on an unmodified or only slightly modified OpenSSL FIPS Object Module 2.0. The private label validations are typically much less expensive that a typical from-scratch validation, because the test lab can refer to materials developed from the earlier open source based validation. Once you make non-trivial modifications you're looking at the more expensive kind of validation. Note the FIPS module proper isn't that big, in time or space (typically 1/2MB and 3 seconds for the POST initialization), so you need a pretty compelling reason to try cutting it down even further. The OpenSSL libcrypto shared library is about 15 times larger and a better place to look for size reduction opportunities. In general it will make more sense to use the FIPS module as-is and reference just the specific functionality you need. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL openssl-fips-2.0.2 and private label
On 12/12/2012 10:49 AM, bhagyalekshmi r wrote: Hi Steve, Thank you very much for your time and response. Your reply gave me pretty clear picture. I have one last question. I would like to know is there any license related issue if I dont go for FIPS validation, but still use part of openssl-fips-2.0.2 along with OpenSSL library. In other words, say I am using a specific crypto algorithm from openssl-fips-2.0.2 along with OpenSSL library. Do I need to obtain a change modification letter from OpenSSL or exsting license terms of OpenSSL will hold good? Well, you're dealing with two different concepts here. The FIPS module is available under the same permissive open source license as the rest of OpenSSL: http://openssl.org/source/license.html. That however is entirely separate from the issue of FIPS 140-2 validation. As clearly noted in the Security Policy the source distribution cannot be changed *at all* for validation certificate #1747 to remain applicable. That's what I meant by you touch it, you own it. A minor source code change that does not affect the general functionality or any previously tested platforms (more than 50 now) could possibly be accommodated under the change letter process -- but remember any such changes have to make sense, or at least not impact, the general user community. We can extend and improve the FIPS module that way, but not customize it for specific purposes. Custom modifications to the FIPS module itself will require a new validation. You are free to use the source code, under the terms of the OpenSSL license, for that purpose but there is no avoiding the need for another validation. You can try to wade through that process yourself, or you can hire either OSF or a third party to pursue it for you. Figure on 9-12 months and $50K+ for that effort. Generally speaking you can freely modify OpenSSL and the intact FIPS module remains valid, though note that if you break the parts of OpenSSL designed for interfacing with the FIPS module you'll run into many problems. Any way you look at it you need really compelling reasons to chose that route; you will have not only the initial difficulty and expense of implementing custom modifications, but also the long term burden of supporting those customizations. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS validation process
On 09/07/2012 03:14 AM, V.Ravikumar wrote: Hello All, I would be so thankful if somebody explains the application fips validation process in details. Also need purpose of below files and how they will be used in validation process. fipscanister.o fipscanister.o.sha1 fips_premain.c: fips_premain.c.sha1 fipsld. Also what is process that is taking place in linking with fipsld. Thanks in advance. Regards, Ravi This question would be more appropriate for the openssl-users list. See http://www.openssl.org/docs/fips/UserGuide-2.0.pdf -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS_mode_set(1) always returns false
On 09/07/2012 01:32 PM, Taraniteja Vishwanatha wrote: I did not see any build instructions in http://openssl.org/docs/fips/UserGuide-2.0.pdf These queries would more appropriately directed to the openssl-users list. Check the latest draft of the User Guide that hasn't been posted to openssl.org yet: http://opensslfoundation.com/testing/validation-2.0/docs/UserGuide-2.0.pdf The instructions are essentially the same as for the 1.2.x module. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Object Module 2.0 - Compliance with 186-3
On 07/09/2012 03:55 PM, John Foley wrote: According to the NIST web site, the 2.0 FIPS Object Module claims compliance for FIPS 186-3 using the Extra Random Bits method for EC public key generation. The implementation is FIPS 186-3 Section B.4.2, Key Pair Generation by Testing Candidates. The ExtraRandomBits reference is inaccurate. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module 1.2.4 support for Apple iOS and OS X
On 07/03/2012 10:42 AM, Jean-Marc Desperrier wrote: Jean-Marc Desperrier a écrit : Do they (or anyone else) also intend to sponsor the same extension for the new v2.0 module ? I must say that in the rather extensive list of OS for the new module OS X and iOS are the two that are most obviously missing. I've also fielded a number of queries about AIX. We even have (or had) sponsors interested in funding the validation testing costs for AIX/Power, but were unable to arrange for the necessary hardware and software to test on. Well :-) I've *just* seen the following text in paragraph 2.7 of the user guide of module v2.0 : [pending] Addition of Apple iOS 5.1 on ARM [pending] Addition of WinCE 5.0 on ARM [pending] Addition of Linux 2.6 on PowerPC32-e500 [pending] Addition of DSP Media Framework 1.4 on TI C64x+ So, on the other hand there's no Mac OS X pending ? Correct; to date we have had no sponsors interested in funding OS X for the 2.0 validation. The 2.0 software supports that platform (thanks to the Thursby sponsorship for 1.2.4) and it could still be added via a change letter update. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Object Module v2.0 validation now complete
The long awaited validation of the OpenSSL FIPS Object Module v2.0 (2.0 module) is now complete: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2012.htm#1747 The 2.0 module is designed for use with OpenSSL 1.0.1. This module is similar in many ways to the earlier OpenSSL FIPS Object Module 1.2 (1.2 module), currently available with the most recent revision level of 1.2.4. The 1.2 module is only compatible with OpenSSL 0.9.8. One very important difference to note is that a new requirement has been imposed on the distribution of the 2.0 module. The CMVP (the program granting the validation) has specifically disallowed the conventional process of downloading the source code distribution from a web site. To use the 2.0 module for production purposes where FIPS 140-2 validation is to be claimed the source must be obtained by a secure path, and the most feasible such mechanism is transfer via physical media, i.e. a snail-mailed CD-ROM disk. We will provide such disks at no charge for as long as possible, see: http://openssl.com/fips/verify.html for instructions on requesting a disk. The User Guide document has been extensively updated and expanded for the 2.0 module, and that document will be maintained in two separate versions for the 1.2 and 2.0 modules: http://www.openssl.org/docs/fips/UserGuide-1.2.pdf http://www.openssl.org/docs/fips/UserGuide-2.0.pdf -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Object Module v2.0 validation -- CD requests
The number of requests for CD-ROM disks arriving since our announcement of the OpenSSL FIPS Object Module v2.0 FIPS 140-2 validation earlier today has exceeded our expectations. We will need to order additional mailers and CDs, and/or arrange to have a large number of disks professionally duplicated (at the moment we're burning and printing them one at a time). So please expect some delays in receiving the CDs that have been requested. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Object Module 1.2.4 support for Apple iOS and OS X
The OpenSSL FIPS Object Module 1.2 has been extended to include support for the iOS and Mac OS X operating systems, as the newly released revision 1.2.4. This new support was made possible by a collaboration with Thursby Software Systems, Inc, (http://www.thursby.com/), a leading vendor of commercial Apple enterprise integration products. This module corresponds to the FIPS 140-2 validation certificate #1051, see http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1051 The new 1.2.4 source distribution can be found at: http://openssl.org/source/openssl-fips-1.2.4.tar.gz An update to the 1.2 User Guide document should be forthcoming in a few days: http://openssl.org/docs/fips/UserGuide-1.2.pdf Note UserGuide.pdf is currently a symlink to UserGuide-1.2.pdf, but will soon reference the new User Guide 2.0 document for the upcoming OpenSSL FIPS Object Module 2.0. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS 2 mode with shared libs : Clarification needed .....
On 04/16/2012 04:41 PM, Simon Convey wrote: Dear all, ( On a Linux 2.6.32 x86_64 ) I'm trying to build a FIPS 2 openssl When I configure the fips code, config spits out as warning ... WARNING: OpenSSL has been configured using unsupported option(s) to internally generate a fipscanister.o object module for TESTING PURPOSES ONLY; ... I *assume* that the warning is because we are using test software, rather than configuration problems ? And that the correct procedure is just ./config rather than ./config fipcanisteronly, which the README.FIPS suggests ? Secondly, once fipscansiter is built, ( and installed to /usr/local/ssl/fips-2.0 ), I should be using ... #cd openssl-1.0.1 #./config fips shared ( I want fipscanister in libcrypto.so.1 ) Is it ok to use fipscanister inside libcrypto this way ? Yes to all three questions. The validation is still pending for the 2.0 module (we're engaged in an extended dialog about the precise process used to verify the source tarball). Once a validated module is properly generated you are free to use it with any application, including an OpenSSL shared library. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Module 2.0 status update
The OpenSSL FIPS Object Module 2.0 is now in coordination status at the CMVP. That's usually a good sign that the formal validation award is imminent (as in a week or three...). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Module 2.0 status update
On 03/06/2012 08:49 AM, Vanden, Michelle CTR USAF AFMC AAC/EBYC wrote: Hello Steve, Will the new certificate support that is has been tested in a Windows 7 That validation will include the following MS Windows platforms: Windows 7 32bit on x86, SSE2 optimization Windows 7 64bit on x86, SSE2 optimization AES-NI optimization is not covered, so for instance the module cannot be used with Windows on many Intel Core i5 processors. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Module 2.0 status update
On 03/06/2012 09:55 AM, Technical Support wrote: Steve Thats where the entire fips validation really breaks down. Complete end user confusion on what machine, operating system and processer type can and cannot be used. It must be a real deployment stumbling block for large organizations. Strictly speaking that is an issue with all FIPS 140-2 validations of software modules for general purpose computers. Take a look at any such validation (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm) and note how many platforms are included in the validation. Not that many, in general. The OpenSSL FIPS Object Module 2.0 will start out with more than the usual number of platforms, roughly four dozen, but that's still less than the spectrum of devices the software could be deployed on. In practice both the vendor and user communities seem to take a fairly casual approach. Inquire about purchasing the WhizBang(tm) product from SnakeOil Enterprises and I'll bet they neglect to caution you (for instance) that the validation won't apply to your Core i5 system because AES-NI wasn't included in the validation :-) -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Module 2.0 status update
On 03/06/2012 06:47 PM, William A. Rowe Jr. wrote: On 3/6/2012 8:43 AM, Steve Marquess wrote: On 03/06/2012 08:49 AM, Vanden, Michelle CTR USAF AFMC AAC/EBYC wrote: Hello Steve, Will the new certificate support that is has been tested in a Windows 7 That validation will include the following MS Windows platforms: Windows 7 32bit on x86, SSE2 optimization Windows 7 64bit on x86, SSE2 optimization AES-NI optimization is not covered, so for instance the module cannot be used with Windows on many Intel Core i5 processors. The real question is what does it take to cripple AES-NI optimization by OpenSSL? If it's not validated, and fips mode is set on, that optimization should simply be crippled. Is this possible? I trust there is no AES-NI code in the validated fipscanister? So therefore any workaround would be possible within the openssl 1.0.1 non-validated code? There is AES-NI code in the validated module (for x86). Remember that validated is a bureaucratic designation, not a technical condition. The exact same code can be validated in one context and not in another, and in general the code itself can't tell which is which. For instance, if you built the module with the command ./config no-idea then it would by definition not be validated (Security Policy violation), even though the resulting object code would be completely indistinguishable from that of a valid module. In the specific case of AES-NI the runtime capability check can be overridden (and the AES-NI code path disabled) by setting the environment variable OPENSSL_ia32cap=~0x202, so if you were careful to do that for a AES-NI capable processor then arguably that would be a legitimate use (all other validation criteria having been met). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL validation question
On 01/25/2012 10:00 PM, Thor Lancelot Simon wrote: On Wed, Jan 25, 2012 at 06:35:58PM -0500, Steve Marquess wrote: A rough rule of thumb is that if you create a FIPS module (fipscanister.o) on a formally tested platform (O/S and processor as listed in the Security Policy), and if that binary file when copied Does the Security Policy list the compiler? When I did this, years ago, I think we did not have to specify the compiler even when we applied for our algorithm certificates. Correct, the compiler version is typically not listed. ... That seemed very, very wrong, since one of the changes most likely to break a highly optimized implementation of an algorithm is a change to the compiler! I disagree. While it is certainly possible to write software that is dependent on a specific version of a specific compiler, OpenSSL (and the OpenSSL FIPS Object Module) is carefully designed for portability across a wide range of platforms (O/S, processor, and compiler). That portability is demonstrated continuously across a very large installed user base. If the specific compiler version were to be considered a vital element of the Operational Environment, then so should be the run-time libraries, run-time loader, specific kernel modules and patches, and so forth. Or in other words, instead of a few thousand validated modules (current count as of today for all validated modules is 1,669, only some of which are software modules) you would need many tens of thousands -- with a wait time of many months for each one. Also consider the consequences of a broken compilation due to a compiler mismatch (or run-time library, or O/S, or whatever). The odds that the generated code will compile an executable file and yet fail in such a way as to still survive the POST (integrity check and algorithm KAT and continuous tests) and yet perform incorrect cryptographic operations is not high. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS 2.0 validation status, question
On 01/26/2012 09:03 AM, blaan...@rockwellcollins.com wrote: First, I saw the early update from Jan 3 that the formal submission was made and that the expected award date is roughly 2 months from there. Is late Feb or early March still the expected target, or have issues come up since that would cause more delay? Yes, that's still the estimated date ... with the caveat that such estimates can never be certain. I've never personally had a validation review completed in such a short period (two months), but we're getting consistent feedback from several test labs that the current turnaround time is indeed that short. Second, and more importantly to me than the release date -- is the new 2.0 validation done on the source code or on the module? The original validation was done in source code form, and thus the validation status was maintained on other software/hardware combinations so long as one was able to compile a set of bitwise-identical source code using the same compilation/build procedures. I assume this cross-compile capability and portable validation aspect will be maintained in the 2.0 validation -- but I feel like I should ask since it was such an extensive redesign. Well, technically speaking source code itself has never been FIPS 140-2 validated. From the perspective of the CMVP the resulting binary code is the validated module and the process of building from source is installation of the module. That's why I try to always use the term open source *based* validation. The end result is the same, though -- with this validation as for the previous OpenSSL FIPS Object Module validations, if you strictly follow the installation (build) instructions in the Security Policy from unmodified source on a formally tested platform, or one near enough to a formally tested platform, then the resulting module is validated. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL validation question
Hi, Does the FIPS module certification is missed if the fipscanister module is compiled to a configuration (architecture, compiler version etc) different from those listed on OpenSSL security policy? Our concern is if a change to something on the build tools like compiler version or architecture can invalidate the certification. That's a very general question, so I can't give a specific answer. It depends. A rough rule of thumb is that if you create a FIPS module (fipscanister.o) on a formally tested platform (O/S and processor as listed in the Security Policy), and if that binary file when copied as-is to another platform executes successfully, then you are *generally* justified in claiming it as validated. The Implementation Guidance document (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf) is a more official discussion. See in particular section G.5. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com
Re: OpenSSL FIPS Module 2.0 status update
On 01/08/2012 11:11 PM, Paul Suhler wrote: Hi, all. What is the file openssl-fips-2.0rc2.tar.gz.1, which is about an hour newer than the one listed below? It is not relevant ... an attempt to deal with a Microsoft Windows issue. We have since identified a better work-around that does not involve changes to the module code. Since we're probably going to be asked, here's the issue: we found that the Windows based compilations would occasionally fail when attempting to perform successive operations on files. For instance, 1) link executable, 2) run executable, 3) delete executable, 4) (re)link executable would fail at step 4 even though the file did not exist (previous unlink was successful). We traced the problem to the bundled Windows Defender service; stopping or replacing that avoids the problem. Other programs (anti-virus or other, such as Explorer) may also cause similar problems. For the formal FIPS 140-2 testing we build a fresh Windows image from scratch and install nothing but the essential build software (in this case MSVC++, perl, nasm, and a handful of GnuWin32 utilities). Now we have a new step, stop the Windows Defender service and/or install Windows Security Essentials as that which does not appear to trigger this problem. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Module 2.0 status update
The FIPS 140-2 validation effort for the OpenSSL FIPS Object Module 2.0 has reached an important milestone; we are now in the final phase of this effort. The formal submission prepared by the test lab has been sent to the CMVP. At this point we can only wait for their review and action. Our best estimate of the time this action will take is approximately two months, though please note we have no control over that process and little visibility into any changes in status over time. The corresponding source distribution is: http://opensslfoundation.com/testing/validation-2.0/source/openssl-fips-2.0rc1.tar.gz Note some additional cosmetic changes will be made prior to the formal validation award. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS module 2.0 certification status
On 12/21/2011 02:56 PM, Adriano Godinho wrote: Thanks Steve for the precise information. Just one more question: February is still the most likely date to the end of the process, or there is a chance that this occurs before this date? I would be (happily) surprised if it happened before late February. We don't even have the formal submission in yet, though I'm hoping to make an announcement soon. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS cross-compile for SH4
On 12/08/2011 07:54 PM, Rick Davis wrote: I'm working on a cross-compile build of openssl-fips-1.2.3. ... 2. ./Configure no-hw no-shared no-dso no-asm ... ... 4. Modify main Makefile with: ... There is something here that I am missing to build the fips modules correctly; the basic procedure in the user manual does not seem to quite work here. Unfortunately you have violated the Security Policy in several ways. No runtime options are allowed and no modifications of the source distributions are permitted, at all. In general a new cross compiled platform probably isn't going to fit in the constraints of the module as it currently exists, for the purposes of claiming FIPS 140-2 validation -- that's one reason we don't try to give general instructions. There is a procedural process that allows an existing validated module (validation #1051 in this case) to be modified (within certain limits) to accommodate new platforms. We have a couple of those modifications in process right now. These change letter modifications are less expensive and faster, by far, than a full validation but are still not painless and not free. I suspect that's your best option, contact me directly if you'd like more details. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com
OpenSSL FIPS Module 2.0 status update
The FIPS 140-2 validation effort for the OpenSSL FIPS Object Module 2.0 has reached an important milestone. We have declared code freeze, a little later than originally planned, and have submitted formal software distributions to the accredited testing laboratory. Those distributions can be found at http://opensslfoundation.com/testing/validation-2.0/source/ There are two separate versions because some sponsors have requested testing with a module that contains only prime curve EC. The 1.9 notation accommodates a test lab versioning scheme. Please note that these source code distributions *cannot* be used to generate validated modules for two reasons. First, nothing has been validated yet, and secondly the distributions still deliberately identify the contents as suitable for testing purposes only. After the test lab has finished its review we will with their oversight and approval generate new final distributions of production code. Also note that we have already been requested to make some changes to the test suite utilities used by the test lab for their test and review activities. Those interested parties wishing to examine the software as it is being tested are encouraged to reference the OpenSSL-fips-2_0-stable branch in the OpenSSL CVS repository. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Upcoming code freeze for the OpenSSL FIPS Object Module v2.0
At long last we are approaching an important milestone for the FIPS 140-2 validation of the OpenSSL FIPS Object Module v2.0. Following delays required to implement some additional cryptography requested by our major sponsors, and to obtain a full set of usable CAVS test vectors, we are now ready to release a software distribution to the accredited testing laboratory for formal review and operational testing. Once that formal test process has begun the introduction of subsequent source code changes will generally not be feasible, so the source code is effectively frozen. There is a separate process for retroactively modifying an existing validated module, for certain classes of changes such as platform portability, but that process involves additional expense and will be handled independently of the original validation. We plan to freeze the OpenSSL FIPS Object Module v2.0 baseline on 2011-10-19 1000 UDT, at which point the candidate source distribution tarball will appear as openssl-fips-2.0-rc1.tar.gz in the http://www.openssl.org/source/ directory. All interested parties are encouraged to test recent snapshots (ftp://ftp.openssl.org/snapshot/openssl-fips-2.0-test-20111013.tar.gz and later) on their platforms of interest, and report any problems to us. Build and test instructions are given in the ./README.FIPS file. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS algorithm testing tools
On 08/19/2011 01:42 PM, Wes Higaki wrote: Are there any open source (or even proprietary) tools that do FIPS algorithm testing for OpenSSL? That is, is there a tool that will take in the test vectors from the NIST tool, run them through OpenSSL and output the results ideally in the form that NIST expects? Yes, you need to take a closer look at the OpenSSL distributions that contain FIPS module code (recent 0.9.8 and HEAD). Use of the algorithm test drivers (the programs that do what you describe) is also documented in the User Guide, http://openssl.org/docs/fips/UserGuide.pdf. See Appendix B. Also note that OpenSSL is not what is tested and validated, the validations are for the OpenSSL FIPS Object Module which is a separate and distinct software component as built. The fact that the source code for the latter is embedded in the same source tarballs used to build the usual OpenSSL libraries leads to continuing confusion. For the upcoming 2.0 module we will be releasing the OpenSSL FIPS Object Module source code in a separate tarball (now available as ftp://ftp.openssl.org/snapshot/openssl-fips-2.0-test-2011MMDD.tar.gz snaphots). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
Re: Which tar.gz file I need for OpenSSL FIPS Object Module?
Hi, I'm using openssl (*openssl-0.9.8r.tar.gz *) in a project, and now we want certificate the software with FIPS certification, my question is if we must have *openssl-fips-1.2.3.tar.gz* to use OpenSSL FIPS Object Module? In * openssl-0.9.8r.tar.gz* project we already some fips files. What is the difference between *openssl-fips-1.2.3.tar.gz* and *openssl-0.9.8r.tar.gz*? In User Guide I read the following: The FIPS Object Module is the special monolithic object module built from the special source distribution identified in the Security Policy. It is not the same as the OpenSSL product or any specific official OpenSSL distribution release. If you just want to experiment with the source then you will find code relevant to FIPS 140-2 relevant functionality in most recent distributions. If you want to build a FIPS module and claim that it is FIPS 140-2 validated (n.b.: validated not certified), that is something else entirely. To make that claim you must follow the procedures outlined in the relevant Security Policy document (for instance, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1051.pdf) where you will see the source code you must start with is uniquely identified. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
Re: Call for testing - FIPS object module
On 07/07/2011 06:54 PM, Nilesh Vaghela wrote: Hi, We are interested in testing FIPS + DTLS. Can we test DTLS + FIPS ? DTLS is handled by the FIPS capable OpenSSL and is compatible with the restricted set of algorithms permitted in the FIPS mode of operation, so it should work. In general anything you can do with the regular OpenSSL libraries that only uses the cryptographic algorithms allowed by FIPS 140-2 should still work with the FIPS capable OpenSSL (the OpenSSL FIPS Object Module plus OpenSSL built with the fips option). A lot of effort went into designing the FIPS module to make that compatibility possible. Note as a happy consequence that an existing application that uses OpenSSL for all cryptography can usually be readily converted to use FIPS validated cryptography. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Call for testing - FIPS object module
Coding of the OpenSSL FIPS Object Module v2.0 (FIPS Module) is now complete except for the addition of some new cryptographic modules our sponsors have recently asked us to include. That additional coding will take approximately a month but will not affect the function of the currently coded FIPS module in any significant way. In the interest of minimizing the total time to formal validation award we usually submit the FIPS module for testing as soon as possible, at which point the code is frozen and subsequent changes are difficult or impossible. This delay provides us with an opportunity for some more extensive testing by the user community. We encourage all interested parties to download and test the current FIPS module and accompanying FIPS capable OpenSSL (the regular OpenSSL libraries built to transparently embed the FIPS module). Since some minor code changes may still be occurring as problems are reported and corrected, please use snapshots from the same day for any testing. The FIPS module will be in the snapshot file of the form ftp://ftp.openssl.org/snapshot/openssl-fips-2.0-test-2011MMDD.tar.gz and the matching FIPS capable OpenSSL distribution will be in ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-2011MMDD.tar.gz where MMDD is the same month and day for both. README files in both distributions describe how to build the composite FIPS capable libraries, the quick version is: gunzip -c openssl-fips-2.0-test-2011MMDD.tar.gz | tar xf - cd openssl-fips-2.0-test-2011MMDD ./config make make install cd .. gunzip -c snapshot/openssl-1.0.1-stable-SNAP-2011MMDD ./config fips make make install We are interested in problem reports at any time, but this special window of opportunity over the next few weeks will allow us to easily correct reported problems. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Build Error on 1.0.1 with FIPS
On 06/29/2011 04:46 PM, Dr. Stephen Henson wrote: On Wed, Jun 29, 2011, Tyrel Haveman wrote: Thanks Steve. This helps a lot. One more related question: Why are the FIPS test vectors different for different platforms? It seems like Windows and Linux, for example, should both be able to encrypt the same things and produce the same outputs. They are interchangable it's just that those are the testvectors produced by that particular platform during testing. The formal testing process requires that a unique set of test vectors (request files) be generated for each test platform (operational environment). Once such a set is used for one platform and the response files confirmed as correct it cannot be used again for any formal testing. Presumably that is to keep the vendors (i.e. us) from cheating by hard-coding the correct answers. By now we have encountered quite a few of these test vector sets, but as they are interchangeable there is no point in keeping more than a few representative samples. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS Module 2.0 status update
When the current effort to obtain a FIPS 140-2 validation began in January we announced an expected completion in Q4 of this year, based on our planned strategy of developing the FIPS module first, submitting it for validation, and then developing the corresponding FIPS capable OpenSSL 1.0.x. The FIPS module development is now essentially complete, and we were preparing to actively engage the test lab in the validation review process. However, our primary sponsors have requested a change in the original project strategy. We have been asked to implement some additional cryptographic algorithms and to focus on early release of a working FIPS module plus FIPS capable OpenSSL combination, at the expense of the formal validation award. That working code (less the new cryptographic algorithms which will not be of significant interest to most users) will be available sooner than originally planned. We have now shifted our resources to completing the FIPS capable development. That effort is expected to be substantially complete in approximately three weeks, at which point the results will be available for testing by any interested parties. Next we will implement the new cryptographic algorithms, an effort expected to take another 4-6 weeks, at which point we will then commence the FIPS validation review process with the test lab. As a consequence of this new project strategy we are now predicting availability of the formally validated module in early 2012. To summarize: 1) Working but unvalidated code should be available within a month. 2) The formally validated module should be available by Q1 2012. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
New Sponsor for the FIPS Validation (Innominate Security Technologies AG)
We are pleased to announce that Innominate Security Technologies AG (http://www.innominate.com/) has committed to sponsor a new platform for the upcoming FIPS 140-2 OpenSSL FIPS Object Module v2.0 validation: Linux on Freescale MPC8313 This new contribution will leverage the ongoing effort to include this new platform, thereby significantly increasing the value of the resulting validation. To date the following platforms are included in the validation: Android 2.2 on HTC Desire smartphone Android 2.2 on Dell Streak tablet VC++ Win32/x86 asm optimisation uCLinux on ARMv4 asm optimisation Fedora 14 on x86-64 asm optimisation HP-UX 11i on Itanium, 32bit(hpux-ia64-cc) no-asm HP-UX 11i on Itanium, 64bit(hpux64-ia64-cc) no-asm Ubuntu Linux 32bit x86 with assembler optimisations Android 3.0 on Motorola Xoom Linux on Freescale MPC8313 CPU Coding is substantially finished and we are entering the next phase where documentation and platforms are being prepared for formal testing. There is still a limited window of opportunity for including uncomplicated platforms directly in this validation, but at this point some more challenging platforms will have to be deferred to a later change letter modification process. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1 and FIPS
What is happening? No Fips in the Openssl 1.0.1 STABLe. Correct, and you won't be seeing the FIPS capable support there for some time. We're concentrating on the validation of the module (OpenSSL FIPS Object Module 2.0) now. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
Re: openssl 1.0.1 and FIPS
Steve, It looks like the FIPS 2.0 code has been going into HEAD. When do you plan to pull a branch for the FIPS Object Model 2.0? We don't. The source tarball for the eventual validated module will be generated with make -f Makefile.fips dist which extracts the relevant subset of code. Note we have begun posting FIPS module snapshots at ftp://ftp.openssl.org/snapshot/. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1 and FIPS
OK, I'm still a bit confused on the version labeling. Is it safe to assume the next stable label pulled off HEAD (e.g. 1.0.2) will include support for make -f Makefile.fips dist. Or to put the question another way, what stable label should be used to generate the FIPS Object Model 2.0 source code? For someone who wants to do FIPS validated cryptography there are two pieces to the puzzle. First you need the validated module, the OpenSSL FIPS Object Module 1.2.3 which is currently available, or the upcoming OpenSSL FIPS Object Module 2.0 which is still under development. Second you need a matching FIPS capable OpenSSL distribution. That would be 0.9.8r for the 1.2.3 module. It will eventually be 1.0.1 for the upcoming 2.0 module. If you want to write usable applications with the 2.0 module you'll have to wait awhile as neither the module nor the FIPS capable OpenSSL are ready yet. The 2.0 module is complete enough to test for platform compatibility, and we encourage all interested parties to try building it on their platforms of interest, but we're months away from having the critical mass of code that would support use by applications. Then it will be months more before the formal validation is awarded. We're hoping to reach that final goal by the end of this year. There is an option available to vendors wishing to prepare and ship products based on the upcoming validated module before that final validation is achieved. They can sign up for a separate private label validation to put their products on the CMPV pre-validation list which satisfies procurement requirements for much of the DoD and federal government market. OSF can perform those validations on a fixed fee basis; that revenue goes to support the open source based validation and the continued maintenance and development of OpenSSL. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TLS 1.2 support
On 05/13/2011 02:21 PM, John Foley wrote: It looks like TLS 1.2 is being implemented in recent commits. Is there an anticipated completion date for when v1.2 will be fully implemented? TLS 1.2 is being implemented in two stages. The first phase will be completed in a few weeks. The schedule for full implementation is still under consideration. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
New Sponsor for the FIPS Validation (Cerebus LLC)
We are pleased to announce that Cerebus LLC (http://www.cerberusftp.com/) has committed to sponsor the upcoming FIPS 140-2 OpenSSL FIPS Object Module v2.0 validation. This new contribution will leverage the ongoing effort to cover the new platform, thereby significantly increasing the value of the resulting validation. This validation effort is rapidly approaching the next phase where we will submit the software for formal testing. In the next few weeks we will announce the release of interim distributions for interested parties to test on their platforms of interest. Note there will be a limited window of opportunity for making changes to the formal baseline -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
New Sponsor for the FIPS Validation
We are pleased to announce that a sponsor has committed to fund a new platform for the upcoming FIPS 140-2 OpenSSL FIPS Object Module v2.0 validation: Ubuntu Linux 32bit x86 with asm optimisation This new contribution will leverage the ongoing effort to cover the new platform, thereby significantly increasing the value of the resulting validation. To date the following platforms are included in the validation: Android on ARM VC++ WIN32 on x86 uClinux on ARM Fedora 14 on x86-64 asm optimization HP-UX 11i on Itanium, 32bit (architecture target hpux-ia64-cc) HP-UX 11i on Itanium, 64bit (architecture target hpux64-ia64-cc) Ubuntu Linux 32bit x86 with asm optimisation Any prospective sponsors of platforms not included in that list are encouraged to contact the OSF. Note the window of opportunity for adding platforms to this validation will be closing soon, within a few weeks. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.0d or openssl-fips-1.2.2 ?
On 04/22/2011 01:09 AM, kiran s wrote: Hi Team, We are using OpenSSL 1.0.0d for our application using 3DES. My application has a constraint that it should only use FIPS approved alogithms. Yesterday we come across another openssl version which is openssl-fips-1.2.2. Please clarify us what is the difference between openssl-fips-1.2.2 and OpenSSL 1.0.0d ? The former is the source for the OpenSSL FIPS Object Module v1.2.2, a FIPS 140-2 validated cryptographic module (see http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1051). Read the User Guide (http://www.openssl.org/docs/fips/UserGuide.pdf) carefully for instructions on using that module *and* the FIPS capable OpenSSL. The latter is a recent version of the OpenSSL library and toolkit, an entirely different beast. It is not usable with the OpenSSL FIPS Object Module v1.2.2. If we are using the FIPS approved 3DES algorithm only in our application, is it fine to continue using 1.0.0d version alone ? Not if you want to claim FIPS 140-2 *validation*. Pay close attention to the wording: note use FIPS approved algorithms is not (assuming no other context) the same thing as use FIPS 140-2 validated cryptography. So, should I use 1.0.0d version or do we mandatorily use openssl-fips-1.2.2 module ? The depends on your requirements. If you just want your application to work, use 1.0.0d and forget about the FIPS validated module; it doesn't give you better cryptography, or performance, or security. If you have a mandate to use FIPS 140-2 validated cryptography then your options are very limited. There is only one currently validated open source based OpenSSL compatible cryptographic module, and that is validation #1051. It is only compatible with OpenSSL 0.9.8x, not 1.0.0x. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
Re: Please Help I am looking for openssl-fips-1.2.2.tar.gz for Windows 64 Bit
On 04/22/2011 05:20 AM, Bhaskar Raju Penumatsa wrote: Dear Steve Thanks for your reply. Actually I am new to OPENSSL. Currently I am using OpenSSL 1.0.0d. I would like to ask you whether it is FIPS enabled version? There is currently no validated OpenSSL FIPS Object Module compatible with any OpenSSL 1.0.0+ distributions, and OpenSSL 1.0.0+ is not FIPS enabled. We hope to have both available at the end of this year. I am using this OPENSSL for encryption and decryption of Data files using 3DES algorithm from the command prompt. Recently I came across http://www.openssl.org/source/openssl-fips-1.2.2.tar.gz version which I am not able to Install on Win 64 bit OS. And also I come across some blogs saying that I need to enable FIPS by FIPS_MODE_SET() to True. And some blogs say that I need to link the OPENSSL 1.2.2 to the version I am Using. For the FIPS capable OpenSSL 0.9.8+ and the OpenSSL FIPS Object Module v1.2.2 (your only current option), see the User Guide at http://www.openssl.org/docs/fips/UserGuide.pdf. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com
