Re: ssl teses forbidden in FIPS mode
The Doctor wrote: On Thu, Sep 25, 2008 at 08:22:11AM -0400, Steve Marquess wrote: David Jacobson wrote: Tim Hudson wrote: The Doctor wrote: That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? That is what the FIPS mode is for - the library built supports all algorithms and when in FIPS mode it disables the use of non-approved algorithms. A single application can work in both FIPS and non-FIPS mode. You can add in code to choose which mode to be in on a per-connection basis if that is what your application requires. See the usage of FIPS_mode_set() Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. It is not an implementation quirk, it is a requirement of FIPS 140. FIPS 140 requires that when switching modes all keys and critical security parameters must be cleared. The random number generator state is a critical security parameter. (I'm doing this from memory, but I'm quite sure I've got it right.) It is an implementation quirk (or to be honest, an outright goof). By the time we caught this problem it was too late to fix it (with the FIPS 140 validation process you freeze your code first, *then* test -- ready, fire, aim!). Maybe I don't understand what you mean by clearing the RNG. I was interpreting that to mean zeroizing its state. If you mean something else, stop reading right here. From Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program Section 1.2; see the sentence right after Resolution. Definition Approved mode of operation: a mode of the cryptographic module that employs only Approved security functions (not to be confused with a specific mode of an Approved security function, e.g., DES CBC mode). Question/Problem Are there any operational requirements when switching between modes of operation, either from an Approved mode of operation to a non-Approved mode of operation, or vice versa? Resolution In addition to the requirements specified in AS01.02, AS.01.03 and AS.01.04, a module shall not share CSPs between an Approved mode of operation and a non-Approved mode of operation. Additional Comments This separation mitigates the risk of untrusted handling of CSPs generated in an Approved mode of operation. Examples: - a module may not generate keys in a non-Approved mode of operation and then switch to an Approved mode of operation and use the generated keys for Approved services. The keys may have been generated using non-Approved methods and their integrity and protection cannot be assured. - a module shall not electronically import keys in plain text in a non-Approved mode of operation and then switch to an Approved mode of operation and use those keys for Approved services. - a module may not generate keys in an Approved mode of operation and then switch to a non- Approved mode of operation and use the generated keys for non-Approved services. The integrity and the protection of the Approved keys cannot be assured in the non-Approved mode of operation. You see that it says that a module cannot share Critical Security Parameters (CSPs) between an Approved mode and a non-Approved mode. Section 7.6 says: ANSI X9.31 specifies that the seed shall also be kept secret. As such, the seed is considered a CSP and shall meet all the requirements pertaining to CSPs. So we see that the seed is considered a CSP. (You could argue that this only applies to RNG designs based on ANSI X9.31, but I believe the CMVP would balk if you tried to use that argument.) Different documents use different terminology for the internal state, but I believe that seed in the above means not just the initial value, but the internal state. (Sorry, I don't have a copy of ANSI X9.31 to check on the definition used there.) Now you see what I said that it is a requirement, not a quirk, that the RNG (state) is cleared when transitioning in or out of FIPS mode. -- David Jacobson Since there is little practical reason to disable FIPS mode once enabled (reference earlier discussion) we elected to just leave that bug as-is rather than abort and restart the validation process. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. The end gives up either to choose FIPs and non-MD5 or non-FIPS and MD5. Please fix as compilation quirks on this is not a laughing matter. __ OpenSSL Project
Re: ssl teses forbidden in FIPS mode
Tim Hudson wrote: The Doctor wrote: That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? That is what the FIPS mode is for - the library built supports all algorithms and when in FIPS mode it disables the use of non-approved algorithms. A single application can work in both FIPS and non-FIPS mode. You can add in code to choose which mode to be in on a per-connection basis if that is what your application requires. See the usage of FIPS_mode_set() Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. It is not an implementation quirk, it is a requirement of FIPS 140. FIPS 140 requires that when switching modes all keys and critical security parameters must be cleared. The random number generator state is a critical security parameter. (I'm doing this from memory, but I'm quite sure I've got it right.) The model they use is that in non-FIPS mode, insecure things might be running that would read out the state, or allow the state to be modified. In an attacker could set the state, then transition into FIPS mode, he could predict future outputs. All FIPS approved random number generators have backtracking resistance, i.e. discovering the state does not reveal previous outputs. So transitioning out of FIPS mode with RNG state intact would be less serious than transitioning into it. But you still don't want to spill state of an RNG that was just used to make a high-value key. i.e. RAND_set_rand_method(NULL); FIPS_set_mode(1); Tim. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- David Jacobson __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
David Jacobson wrote: Tim Hudson wrote: The Doctor wrote: That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? That is what the FIPS mode is for - the library built supports all algorithms and when in FIPS mode it disables the use of non-approved algorithms. A single application can work in both FIPS and non-FIPS mode. You can add in code to choose which mode to be in on a per-connection basis if that is what your application requires. See the usage of FIPS_mode_set() Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. It is not an implementation quirk, it is a requirement of FIPS 140. FIPS 140 requires that when switching modes all keys and critical security parameters must be cleared. The random number generator state is a critical security parameter. (I'm doing this from memory, but I'm quite sure I've got it right.) It is an implementation quirk (or to be honest, an outright goof). By the time we caught this problem it was too late to fix it (with the FIPS 140 validation process you freeze your code first, *then* test -- ready, fire, aim!). Since there is little practical reason to disable FIPS mode once enabled (reference earlier discussion) we elected to just leave that bug as-is rather than abort and restart the validation process. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Thu, Sep 25, 2008 at 08:22:11AM -0400, Steve Marquess wrote: David Jacobson wrote: Tim Hudson wrote: The Doctor wrote: That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? That is what the FIPS mode is for - the library built supports all algorithms and when in FIPS mode it disables the use of non-approved algorithms. A single application can work in both FIPS and non-FIPS mode. You can add in code to choose which mode to be in on a per-connection basis if that is what your application requires. See the usage of FIPS_mode_set() Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. It is not an implementation quirk, it is a requirement of FIPS 140. FIPS 140 requires that when switching modes all keys and critical security parameters must be cleared. The random number generator state is a critical security parameter. (I'm doing this from memory, but I'm quite sure I've got it right.) It is an implementation quirk (or to be honest, an outright goof). By the time we caught this problem it was too late to fix it (with the FIPS 140 validation process you freeze your code first, *then* test -- ready, fire, aim!). Since there is little practical reason to disable FIPS mode once enabled (reference earlier discussion) we elected to just leave that bug as-is rather than abort and restart the validation process. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. The end gives up either to choose FIPs and non-MD5 or non-FIPS and MD5. Please fix as compilation quirks on this is not a laughing matter. -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God, Queen and country! Beware Anti-Christ rising! Canada vote anything but Conservative on 14 OCt 2008, join us at http://www.harpocrit.ca . -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
The Doctor wrote: ... Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. It is not an implementation quirk, it is a requirement of FIPS 140. FIPS 140 requires that when switching modes all keys and critical security parameters must be cleared. The random number generator state is a critical security parameter. (I'm doing this from memory, but I'm quite sure I've got it right.) It is an implementation quirk (or to be honest, an outright goof). By the time we caught this problem it was too late to fix it (with the FIPS 140 validation process you freeze your code first, *then* test -- ready, fire, aim!). Since there is little practical reason to disable FIPS mode once enabled (reference earlier discussion) we elected to just leave that bug as-is rather than abort and restart the validation process. ... The end gives up either to choose FIPs and non-MD5 or non-FIPS and MD5. Please fix as compilation quirks on this is not a laughing matter. Ummm, the point is that one *cannot* fix validated software, period, even for a security vulnerability. We lived that recently with the RNG ordeal for the OpenSSL FIPS Object Module v1.1.1. If you want it secure and want it bug-free, don't use validated code. You can of course use the would-otherwise-be-validated code that has been fixed (which means it is no longer validated, of course). But then why use FIPS mode at all, it really doesn't buy you anything in real-world security terms. Dr. Steve Henson has recently merged the 0.9.8 FIPS branch into the 0.9.8 stable branch, so use that if you want non-validated but bug fixed FIPS mode code. We can do bug fixes there, just can't include them in the v1.2 frozen code baseline for which the validation is still pending. -Steve M. -- Steve Marquess Open Source Software Institute [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Mon, Sep 22, 2008, The Doctor wrote: Apart from me, anyone else tried the fipdso in their configuration as extensively as I have? The fipsdso option isn't terribly useful for most users. To use it you need a corresponding binary validated shared library installed. If you want to test the shared library build of the 1.2 test module then you should instead install the test 1.2 module and just use the fips option of the 0.9.8-stable branch. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Tue, Sep 23, 2008 at 12:27:20PM +0200, Dr. Stephen Henson wrote: On Mon, Sep 22, 2008, The Doctor wrote: Apart from me, anyone else tried the fipdso in their configuration as extensively as I have? The fipsdso option isn't terribly useful for most users. To use it you need a corresponding binary validated shared library installed. If you want to test the shared library build of the 1.2 test module then you should instead install the test 1.2 module and just use the fips option of the 0.9.8-stable branch. Steve. Here is what I am using: ./Configure threads shared no-sse2 fipsdso enable-capieng enable-montasm enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779 enable-gmp enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/contrib --openssldir=/usr/contrib debug-bsdi-x86-elf -g -O3 -Wall -mcpu=pentium3 ; make update The reason being is that fipsdso does give a wider option. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God, Queen and country! Beware Anti-Christ rising! Canada vote anything but Conservative on 14 OCt 2008, join us at http://www.harpocrit.ca . -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Tue, Sep 23, 2008, The Doctor wrote: On Tue, Sep 23, 2008 at 12:27:20PM +0200, Dr. Stephen Henson wrote: On Mon, Sep 22, 2008, The Doctor wrote: Apart from me, anyone else tried the fipdso in their configuration as extensively as I have? The fipsdso option isn't terribly useful for most users. To use it you need a corresponding binary validated shared library installed. If you want to test the shared library build of the 1.2 test module then you should instead install the test 1.2 module and just use the fips option of the 0.9.8-stable branch. Steve. Here is what I am using: ./Configure threads shared no-sse2 fipsdso enable-capieng enable-montasm enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779 enable-gmp enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/contrib --openssldir=/usr/contrib debug-bsdi-x86-elf -g -O3 -Wall -mcpu=pentium3 ; make update The reason being is that fipsdso does give a wider option. Can you explain what you mean by does give a wider option? The only option end users will use in practice once the 1.2 validation is available is fips. The options fipsdso and fipscanisterbuild are only useful for generating test versions which never will be validated. I've just fixed a typo which affects the fipsdso build and it now passes make test on my setup. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Tue, Sep 23, 2008 at 06:46:31PM +0200, Dr. Stephen Henson wrote:
On Tue, Sep 23, 2008, The Doctor wrote:
On Tue, Sep 23, 2008 at 12:27:20PM +0200, Dr. Stephen Henson wrote:
On Mon, Sep 22, 2008, The Doctor wrote:
Apart from me, anyone else tried the fipdso in their configuration
as extensively as I have?
The fipsdso option isn't terribly useful for most users. To use it you
need
a corresponding binary validated shared library installed.
If you want to test the shared library build of the 1.2 test module then
you
should instead install the test 1.2 module and just use the fips option
of
the 0.9.8-stable branch.
Steve.
Here is what I am using:
./Configure threads shared no-sse2 fipsdso enable-capieng enable-montasm
enable-cms enable-seed enable-tlsext enable-camellia enable-rfc3779
enable-gmp enable-mdc2 enable-rc5 zlib-dynamic --prefix=/usr/contrib
--openssldir=/usr/contrib debug-bsdi-x86-elf -g -O3 -Wall -mcpu=pentium3
; make update
The reason being is that fipsdso does give a wider option.
Can you explain what you mean by does give a wider option?
The only option end users will use in practice once the 1.2 validation is
available is fips.
The options fipsdso and fipscanisterbuild are only useful for generating
test versions which never will be validated.
I've just fixed a typo which affects the fipsdso build and it now passes make
test on my setup.
Steve.
I mean
elsif (/^fipsdso$/)
{
$fips = 1;
$nofipscanistercheck = 1;
$fipslibdir=;
$fipscanisterinternal=y;
$fipsdso = 1;
}
Also just trying fips fails here every time.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
Member - Liberal International
This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED]
God, Queen and country! Beware Anti-Christ rising! Canada vote anything but
Conservative on 14 OCt 2008, join us at http://www.harpocrit.ca .
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Sat, Sep 20, 2008 at 06:24:31AM +1000, Michael Gray wrote: TLS uses MD5 as well in the PRF. The PRF in SSLv3 is not a true HMAC which is a problem, but the reason for not using SSLv3 is FIPS regulation. Not Exactly. The TLS PRF uses *both* SHA1 and MD5, in a way which is carefully designed to have the security properties of the stronger of the two. NIST and the labs have accepted the argument that this means that, effectively, only Approved algorithms are used for security (because even if you consider MD5 to be zero-strength, the TLS PRF is as strong as SHA1). This is not the case for SSLv3, which is why SSLv3 is not acceptable in a FIPS-140 certified product: an unapproved algorithm (MD5) is used for data integrity. There is no specific regulation, just the general requirement that only Approved algorithms be used. -- Thor Lancelot Simon [EMAIL PROTECTED] Even experienced UNIX users occasionally enter rm *.* at the UNIX prompt only to realize too late that they have removed the wrong segment of the directory structure. - Microsoft WSS whitepaper __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] Not Exactly? Both TLS and SSLv3 both use SHA1 and MD5 in the PRF, which is IMHO very cleaver as it requires both HASH functions to be broken. But, the TLS PRF is a HMAC for both SHA1 and MD5 whereas SSLv3 is not. The specific regulation is http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf page 61. Several other regulation references exist as well... SSLv3 was allowed in the past with special CipherSuites see http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html , which was never truly official AFAIK in any NIST Document, but widely used and IMHO painful. In this case these CipherSuites used the TLS PRF instead of the SSLv3 PRF (wont bother going in the fine specifics). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Sun, Sep 21, 2008 at 12:58:26PM +1000, Michael Gray wrote: On Sat, Sep 20, 2008 at 06:24:31AM +1000, Michael Gray wrote: TLS uses MD5 as well in the PRF. The PRF in SSLv3 is not a true HMAC which is a problem, but the reason for not using SSLv3 is FIPS regulation. Not Exactly. The TLS PRF uses *both* SHA1 and MD5, in a way which is carefully designed to have the security properties of the stronger of the two. NIST and the labs have accepted the argument that this means that, effectively, only Approved algorithms are used for security (because even if you consider MD5 to be zero-strength, the TLS PRF is as strong as SHA1). This is not the case for SSLv3, which is why SSLv3 is not acceptable in a FIPS-140 certified product: an unapproved algorithm (MD5) is used for data integrity. There is no specific regulation, just the general requirement that only Approved algorithms be used. -- Thor Lancelot Simon [EMAIL PROTECTED] Even experienced UNIX users occasionally enter rm *.* at the UNIX prompt only to realize too late that they have removed the wrong segment of the directory structure. - Microsoft WSS whitepaper __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] Not Exactly? Both TLS and SSLv3 both use SHA1 and MD5 in the PRF, which is IMHO very cleaver as it requires both HASH functions to be broken. But, the TLS PRF is a HMAC for both SHA1 and MD5 whereas SSLv3 is not. The specific regulation is http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf page 61. Several other regulation references exist as well... SSLv3 was allowed in the past with special CipherSuites see http://www.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html , which was never truly official AFAIK in any NIST Document, but widely used and IMHO painful. In this case these CipherSuites used the TLS PRF instead of the SSLv3 PRF (wont bother going in the fine specifics). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God, Queen and country! Beware Anti-Christ rising! Canada vote anything but Conservative on 14 OCt 2008, join us at http://www.harpocrit.ca . -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Sun, Sep 21, 2008 at 12:58:26PM +1000, Michael Gray wrote: Not Exactly? Both TLS and SSLv3 both use SHA1 and MD5 in the PRF, which is IMHO very cleaver as it requires both HASH functions to be broken. But, the TLS PRF is a HMAC for both SHA1 and MD5 whereas SSLv3 is not. The specific regulation is http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf page 61. Several other regulation references exist as well... I quote footnote 13, on that page: | The problem with SSL 3.0 is the key derivation process that applies | to all SSL 3.0 cipher suites: half of the master key that is set | up during the SSL key exchange depends entirely on the MD5 hash | function. MD5 is not a FIPS approved algorithm, and its collision | resistance property has recently been broken by Antoine Joux. | | TLS also uses MD5 in the key derivation process, but in a different | manner, so that all of the master key depends on both MD5 and SHA-1, | and nothing in TLS actually depends on MD5 for its security. In other words, the construction used in SSLv3 key derivation leaves bits in the resulting key dependant only on the output of MD5, which is not an Approved algorithm; the TLS construction does not. There is no special regulation here, just -- note that the document you quoted is the implementation guidance -- careful application of the usual rules. Isn't that pretty much exactly what I said before? Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
The Doctor wrote: That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? That is what the FIPS mode is for - the library built supports all algorithms and when in FIPS mode it disables the use of non-approved algorithms. A single application can work in both FIPS and non-FIPS mode. You can add in code to choose which mode to be in on a per-connection basis if that is what your application requires. See the usage of FIPS_mode_set() Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. i.e. RAND_set_rand_method(NULL); FIPS_set_mode(1); Tim. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Tue, Sep 23, 2008 at 08:26:23AM +1000, Tim Hudson wrote: The Doctor wrote: That being said, how do you get openssl to compile with FIPS and be backwards compatable at the same time? That is what the FIPS mode is for - the library built supports all algorithms and when in FIPS mode it disables the use of non-approved algorithms. A single application can work in both FIPS and non-FIPS mode. You can add in code to choose which mode to be in on a per-connection basis if that is what your application requires. See the usage of FIPS_mode_set() Note also that due to an implementation quirk you need to clear the currently set RNG when switching back into FIPS mode. i.e. RAND_set_rand_method(NULL); FIPS_set_mode(1); Tim. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Apart from me, anyone else tried the fipdso in their configuration as extensively as I have? -- Member - Liberal International This is [EMAIL PROTECTED] Ici [EMAIL PROTECTED] God, Queen and country! Beware Anti-Christ rising! Canada vote anything but Conservative on 14 OCt 2008, join us at http://www.harpocrit.ca . -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ssl teses forbidden in FIPS mode
On Sat, Sep 20, 2008 at 06:24:31AM +1000, Michael Gray wrote: TLS uses MD5 as well in the PRF. The PRF in SSLv3 is not a true HMAC which is a problem, but the reason for not using SSLv3 is FIPS regulation. Not Exactly. The TLS PRF uses *both* SHA1 and MD5, in a way which is carefully designed to have the security properties of the stronger of the two. NIST and the labs have accepted the argument that this means that, effectively, only Approved algorithms are used for security (because even if you consider MD5 to be zero-strength, the TLS PRF is as strong as SHA1). This is not the case for SSLv3, which is why SSLv3 is not acceptable in a FIPS-140 certified product: an unapproved algorithm (MD5) is used for data integrity. There is no specific regulation, just the general requirement that only Approved algorithms be used. -- Thor Lancelot Simon[EMAIL PROTECTED] Even experienced UNIX users occasionally enter rm *.* at the UNIX prompt only to realize too late that they have removed the wrong segment of the directory structure. - Microsoft WSS whitepaper __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ssl teses forbidden in FIPS mode
Is this correct for openssl 0.9.8 using FIPS? test SSL protocol test ssl3 is forbidden in FIPS mode *** IN FIPS MODE *** Available compression methods: 1: zlib compression SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA 1 handshakes of 256 bytes done gmake[1]: *** [test_ssl] Error 1 gmake[1]: Leaving directory `/usr/source/openssl-0.9.8-stable-SNAP-20080918-fips/test' gmake: *** [tests] Error 2 If your question is whether SSLv3 should be prohibited in FIPS mode, the answer is yes. SSLv3's use of MD5 is not acceptable under FIPS rules. DS TLS uses MD5 as well in the PRF. The PRF in SSLv3 is not a true HMAC which is a problem, but the reason for not using SSLv3 is FIPS regulation. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: ssl teses forbidden in FIPS mode
Is this correct for openssl 0.9.8 using FIPS? test SSL protocol test ssl3 is forbidden in FIPS mode *** IN FIPS MODE *** Available compression methods: 1: zlib compression SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA 1 handshakes of 256 bytes done gmake[1]: *** [test_ssl] Error 1 gmake[1]: Leaving directory `/usr/source/openssl-0.9.8-stable-SNAP-20080918-fips/test' gmake: *** [tests] Error 2 If your question is whether SSLv3 should be prohibited in FIPS mode, the answer is yes. SSLv3's use of MD5 is not acceptable under FIPS rules. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
