Re: secure CRNGs and FIPS (Re: How important is FIPS 140-2 Level 1 cert?)
Adam Back wrote: > About the criticisms of Common Critera evaluation in general, I think > why people complain it is a documentation exercise is because pretty > much all it does ensure that it does what it says it does. So > basically you have to enumerates threats, state what threats the > system is designed to protect against, and which are out of scope. > > Then the rest of the documentation is just saying that in increasing > detail, that you have not made mistakes in the design and > specification and to some extent implementation. CC has very good points. One of the best points is IMO the ST/PP concept which encourages to think what to protect against what. And I do think that most of the CC documents are helpful. But some, esp. these which occupy the most paper, are IMO not worth their effort. These are the low- and high-level design. They are meant to be the link between specification and implementation, but I am sure that there are simpler ways to show the link. And my experience is that these two documents do not change the product in any way. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
On 27 Dec 2006 14:10:10 -0500, Thor Lancelot Simon wrote: > On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote: >> In addition I've heard of evaluations where the generator is required to use >> a >> monotonically increasing counter (clock value) as the seed, so you can't just >> use the PRNG as a postprocessor for an entropy polling mechanism. Then again >> I know of some that have used it as exactly that without any problems. I have never heard of the seed being required to use a clock value, and, under FIPS 140-2, using only a clock value to seed a PRNG is not going to pass the key management requirements. > This (braindamaged) requirements change was brought in by the creation of > a Known Answer Test for the cipher-based RNG. Prior to the addition of > that test, one could add additional entropy by changing the seed value at > each iteration of the generator. But that makes it, of course, impossible > to get Known Answers that confirm that the generator actually imlements > the standard. So suddenly the alternate form of the generator -- in my > opinion much less secure -- which uses a monotonically-increasing counter > for the seed, was the only permitted form. Now we are talking about something different, the date/time (DT) vector of the X9.31 PRNG, which is not the seed of the X9.31 PRNG. I don't think anything changed with the introduction of a power-up PRNG KAT or PRNG algorithm testing. Even the NIST-defined PRNGs, which are based upon the X9.31 PRNG, are open in regard to what an implementer chooses to use as the DT vector. Take the power-up PRNG KAT. By definition, this requires the use of known values, which means, for an X9.31 PRNG, even the DT vector needs to be set to a known value. Adding in entropy violates this requirement, but, after the KAT is performed (and passed), the PRNG is required to be seeded with "real" data before assuming its normal operational state. Take algorithm testing. This testing too requires the use of known values, in this case provided by a testing lab, which are run through an implementation to produce results that can then be verified by a testing lab. For an X9.31 PRNG, this testing requires access to a parameter (DT) of the X9.31 PRNG that may not normally be accessible outside of the PRNG. It is just fine to have a test mode to provide this access, and then the counter woes can be made to go away as part of this test mode. (Note: Algorithm testing is once off testing performed by the vendor and not normally deployed in a product.) > I have yet to hear of anyone who has found a test lab that will certify > a generator implementation that uses the mono counter for the KAT suite > but a random seed in normal operation. For good reason, labs are usually > very leery of algorithm implementations that come with a "special test > mode". It seems to me that an implementation of an X9.31 PRNG without a test mode makes no sense, for the reasons cited above. This mode would be used in a self-testing state, or during algorithm testing, but not in normal operational state. As an example of a module with public source code, OpenSSL made it through FIPS validation doing this. Their X9.31 PRNG normally uses clock data for DT, but, in test mode, DT can be set from the outside instead. This test mode is utilized for the power-up KAT as well as algorithm testing. I can imagine this is not a unique occurrence. -Andrew - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
Peter Gutmann wrote: > Ben Laurie <[EMAIL PROTECTED]> writes: > >> While we're at it, an amusing fact I learnt about FIPS-140 while I was >> implementing it for OpenSSL is that some of the Monte Carlo tests have output >> that's independent of the input. > > Did you also notice that the MCT test vectors published in "The Random Number > Generator Validation System (RNGVS)" are wrong? Or is that what you meant by > "independent of the input"? When I did FIPS, there was no RNGVS :-) -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
Ben Laurie <[EMAIL PROTECTED]> writes: >While we're at it, an amusing fact I learnt about FIPS-140 while I was >implementing it for OpenSSL is that some of the Monte Carlo tests have output >that's independent of the input. Did you also notice that the MCT test vectors published in "The Random Number Generator Validation System (RNGVS)" are wrong? Or is that what you meant by "independent of the input"? Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
Thor Lancelot Simon wrote: > On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote: >> In addition I've heard of evaluations where the generator is required to use >> a >> monotonically increasing counter (clock value) as the seed, so you can't just >> use the PRNG as a postprocessor for an entropy polling mechanism. Then again >> I know of some that have used it as exactly that without any problems. > > This (braindamaged) requirements change was brought in by the creation of > a Known Answer Test for the cipher-based RNG. Prior to the addition of > that test, one could add additional entropy by changing the seed value at > each iteration of the generator. But that makes it, of course, impossible > to get Known Answers that confirm that the generator actually imlements > the standard. So suddenly the alternate form of the generator -- in my > opinion much less secure -- which uses a monotonically-increasing counter > for the seed, was the only permitted form. > > I have yet to hear of anyone who has found a test lab that will certify > a generator implementation that uses the mono counter for the KAT suite > but a random seed in normal operation. For good reason, labs are usually > very leery of algorithm implementations that come with a "special test > mode". > > However, you are free to change the actual key for the generator as often > as you like. I'm not sure why OpenSSL doesn't implement "fork protection" > that way, for example -- or does it use the MAC-based generator instead? No, it doesn't. Fork protection was originally implemented inside the "FIPS boundary" - which the test lab made us remove. I guess it might be possible to re-insert it outside the boundary, I'm not sure that occurred to us at the time. I seem to remember there was some obstacle to this, though, but I can't remember what it was. While we're at it, an amusing fact I learnt about FIPS-140 while I was implementing it for OpenSSL is that some of the Monte Carlo tests have output that's independent of the input. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
Thor Lancelot Simon <[EMAIL PROTECTED]> writes: >On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote: >> In addition I've heard of evaluations where the generator is required to use >> a >> monotonically increasing counter (clock value) as the seed, so you can't just >> use the PRNG as a postprocessor for an entropy polling mechanism. Then again >> I know of some that have used it as exactly that without any problems. > >This (braindamaged) requirements change was brought in by the creation of a >Known Answer Test for the cipher-based RNG. Prior to the addition of that >test, one could add additional entropy by changing the seed value at each >iteration of the generator. But that makes it, of course, impossible to get >Known Answers that confirm that the generator actually imlements the >standard. So suddenly the alternate form of the generator -- in my opinion >much less secure -- which uses a monotonically-increasing counter for the >seed, was the only permitted form. I don't know if it's the only permitted form, the KAT simply feeds in known input and checks that the output is as required. You can feed in anything you want, there's no need for it to be a counter. The known input just happens to be in the form of a monotonically increasing counter (for the Variable Seed Test (VST), these are from test vectors that NIST has published), the other test, the Monte Carlo Test (MCT) is just a single random seed value which isn't a counter. The values created by the NIST tool are actually rather odd and consist of a one bit shifted down from the MSB, so you get a successively longer string of one bits as input to the VST until all 64 bits are ones. I have no idea why they chose these particular values. >I have yet to hear of anyone who has found a test lab that will certify a >generator implementation that uses the mono counter for the KAT suite but a >random seed in normal operation. I know of at least one and possibly two (I'd have to go back through old email to see who did what), certified at the same time that others couldn't get certified when doing more or less the same thing. >However, you are free to change the actual key for the generator as often as >you like. I'm not sure why OpenSSL doesn't implement "fork protection" that >way, for example -- or does it use the MAC-based generator instead? I'm not sure, I just read through the certification docs on their web site, but they don't go into this. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
On 22 Dec 2006 11:43:58 -0500, Perry E. Metzger wrote: > [I was asked to forward this anonymously. --Perry] > > From: [Name Withheld] > To: [email protected] > Subject: Re: How important is FIPS 140-2 Level 1 cert? > > Paul Hoffman <[EMAIL PROTECTED]> wrote: > >> At 11:25 AM -0500 12/21/06, Saqib Ali wrote: >>> If two products have exactly same feature set, but one is FIPS 140-2 >>> Level 1 certified but cost twice. Would you go for it, considering the >>> Level 1 is the lowest. > >> Assuming that the two products use Internet protocols (as compared to >> proprietary protocols): no. Probably the only thing that could >> differentiate the two is if the cheaper one has a crappy random number >> generator, the more expensive one will have a good one. > > Actually you cant even guarantee that because the FIPS 140 requirements > for the ANSI X9.17/X9.31 PRNG include a pile of oddball things that made > sense for the original X9.17 use (where it was assumed the only source > of entropy was a DES3 key embedded in secure hardware) but are severe > restrictions on current implementations. As a result a FIPS 140- > certified key generator will be worse than a well-designed non-FIPS-140 > one because the FIPS requirements prevent you from doing several things > that would improve the functioning like injecting extra entropy into the > generator besides the DES3 key. In addition since no two eval labs can > agree on exactly what is and isnt OK here its pretty much a crap-shoot > as to what you can get through. Ive heard stories from different vendors > of Lab B disallowing something that had already been certified by Lab A > in a previous pass through the FIPS process. These statements are not entirely correct for FIPS 140-2 under current interpretations (to my understanding, at least). For example, ANSI X9.31 is not the only FIPS-approved PRNG. There are a few of them [1], although most of them are closely related. You can reseed a FIPS-approved PRNG all you want, which means you could even effectively reduce a FIPS-approved PRNG to a whitener if you desired. (There are some caveats here.) IIRC, yarrow takes this sort of approach. Also, as noted elsewhere, some of the PRNGs have explicit mechanisms for you to feed in more entropy. For an X9.31 PRNG, (re)seeding can include (re)keying the 2-key TDES and often does as implementers try to cram as much gathered entropy into the PRNG as possible. Also, lab interpretations of requirements can vary a bit in some of the more ambiguous areas, especially on the things like the stretches made for validating software, or with novel implementations; however, overall, they are quite similar. I think the bigger lab variations revolve around things like the staff on hand , which can effect, for example, how quickly a lab can understand a product, how effectively a lab can interpret that understanding against the requirements, and how much bandwidth the lab has to just get the job done. > In terms of its value, particularly for level 1, what itll give you is > (1) protection from egregiously bad implementations (which a quick > source code check will do as well) and (2) the ability to sell to US > federal agencies. Beyond that I concur that 10 minutes of interop > testing with the standardised protocol of your choice (e.g. TLS, S/MIME, > IPsec) will give you more than FIPS 140 will since a run of TLS tests > much more of the crypto than FIPS 140 does. As to the original direction of this thread, I agree with these value adds. Point two is the main reason anyone pursues FIPS 140-2 at this point, although this might change with the internationalization efforts. As to point one, it is worth noting that many vendors have not had anyone review their crypto up until going through a FIPS 140-2 validation. And, FIPS 140-2 looks at the overall picture more than just particular protocols, by including requirements in areas like the whole of key management, and authentication and authorization (noting this applies at level 2). So, even at level 1, this can mean a fair amount of "real" problems being discovered and resolved as a result of the process. (Of course, if you require stronger levels of third party review of a product, then higher levels of FIPS 140-2 validation or perhaps other programs like NSA certifications are more what you should be looking at.) And, to add a third value, FIPS 140-2 validation can function much like having letters like CISSP following one's name. With regards to protocol interop, as part of the FIPS 140-2 process currently, algorithm testing is involved. Perhaps protocol testing requirements should be included in the next revision of the standard being worked on at the moment [2]. I do agree this would help to strengthen the FIPS 140 process. (Reading
Re: How important is FIPS 140-2 Level 1 cert?
On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote: > > In addition I've heard of evaluations where the generator is required to use a > monotonically increasing counter (clock value) as the seed, so you can't just > use the PRNG as a postprocessor for an entropy polling mechanism. Then again > I know of some that have used it as exactly that without any problems. This (braindamaged) requirements change was brought in by the creation of a Known Answer Test for the cipher-based RNG. Prior to the addition of that test, one could add additional entropy by changing the seed value at each iteration of the generator. But that makes it, of course, impossible to get Known Answers that confirm that the generator actually imlements the standard. So suddenly the alternate form of the generator -- in my opinion much less secure -- which uses a monotonically-increasing counter for the seed, was the only permitted form. I have yet to hear of anyone who has found a test lab that will certify a generator implementation that uses the mono counter for the KAT suite but a random seed in normal operation. For good reason, labs are usually very leery of algorithm implementations that come with a "special test mode". However, you are free to change the actual key for the generator as often as you like. I'm not sure why OpenSSL doesn't implement "fork protection" that way, for example -- or does it use the MAC-based generator instead? Thor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
secure CRNGs and FIPS (Re: How important is FIPS 140-2 Level 1 cert?)
Anoymous wrote: > [criticizing FIPS CRNGs] You can make a secure CRNG that you can obtain FIPS 140 certification on using the FIPS 186-2 appendix 3.1 (one of my clients got FIPS 140 on an implementation of the FIPS 186-2 RNG that I implemented for general key generation and such crypto use.) You should apply change notice 1 under the section "general purpose random number generation", or you will be doing needless modulo q bignum operations for general RNG use (the default, non-change-note modified RNG is otherwise hard code for DSA k value generation and related things 186-2 being the FIPS DSA standard doc). Also about continuously adding seeding this is also provided with 186-2 rng via the XSEED parameter, which allows the system to add extra entropy at any time. About the criticisms of Common Critera evaluation in general, I think why people complain it is a documentation exercise is because pretty much all it does ensure that it does what it says it does. So basically you have to enumerates threats, state what threats the system is designed to protect against, and which are out of scope. Then the rest of the documentation is just saying that in increasing detail, that you have not made mistakes in the design and specification and to some extent implementation. So as someone else said in the thread, as a user you need to read the security target document section on security objectives and assumptions, and check if they protect against attacks that are relevant to you. Another aspect of security targets is protection profiles. A protection profile is basically a sort of set of requirements for security targets for a given type of system. So you might get eg a protection profile for hard disk encryption. The protection profile will be standardized on and so it makes it a bit easier for the consumer as its less likely the protection profile will be massaged. (I mean the consortium or standardization body creating the protection profile will want some security quality bar). Adam - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
"Leichter, Jerry" <[EMAIL PROTECTED]> writes: >| From: [Name Withheld] >| Actually you cant even guarantee that because the FIPS 140 requirements >| for the ANSI X9.17/X9.31 PRNG include a pile of oddball things that made >| sense for the original X9.17 use (where it was assumed the only source >| of entropy was a DES3 key embedded in secure hardware) but are severe >| restrictions on current implementations. As a result a FIPS 140- >| certified key generator will be worse than a well-designed non-FIPS-140 >| one because the FIPS requirements prevent you from doing several things >| that would improve the functioning like injecting extra entropy into the >| generator besides the DES3 key. >I think this was changed as FIPS 140 evolved. Several things about the >random number generator evolved. For example, in earlier versions, you had >to run some tests on your generator at every startup. That disappeared by >FIPS 140-2. That was because for a good RNG the only thing you'd ever get are false positives, so it acted as a "make your generator fail randomly" test. >(It makes sense for a hardware generator, but never did for software.) There are already a pile of huge mental leaps you have to make to apply some of the more hardware-oriented bits of FIPS 140 to software implementations, if you read Microsoft's CryptoAPI FIPS docs you'll see some examples of these in there. For example the physical module boundary is the case of the PC that Windows is running on, the role-based access control covers one single user, whoever's using the PC at the moment, and so on - it's compliance by creating paperwork rather than by engineering. (I'm not trying to bash Microsoft here, other vendors have to resort to the same thing, see e.g. the Crypto++ docs for another public example of this). The problem here is that FIPS 140 was designed for military-security-model crypto hardware, has been stretched to cover embedded device crypto, and has been seriously over-stretched to try and cover software crypto (that is, instead of creating a distinct profile to cover software implementations, the hardware implementation was taken into places it was never meant to go). The only way to reconcile the two is through increasingly tortuous interpretations of various hardware-derived requirements that don't really work for software. >You're definitely free to set the starting state using any source of entropy >you like. I *think* you can add extra entropy along the way; though even if >this were not allowed, you could probably declare that you were restarting. Depends entirely on who's doing the eval. For example if you read the OpenSSL FIPS docs (http://www.openssl.org/docs/fips/) they have an entire appendix dedicated to a discussion of the absence of fork protection, which they weren't allowed to add: The fact that this 'fork protection' is absent in the FIPS object module PRNG concerns many in the OpenSSL developer and user community, and will be the primary obstacle to making the fips configuration option a default. In addition I've heard of evaluations where the generator is required to use a monotonically increasing counter (clock value) as the seed, so you can't just use the PRNG as a postprocessor for an entropy polling mechanism. Then again I know of some that have used it as exactly that without any problems. (Maybe we could come up with a cross-reference of who will allow what, and then people could choose the most sensible evaluator to submit things to). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
| From: [Name Withheld] | To: [email protected] | Subject: Re: How important is FIPS 140-2 Level 1 cert? | | Paul Hoffman <[EMAIL PROTECTED]> wrote: | | > At 11:25 AM -0500 12/21/06, Saqib Ali wrote: | > >If two products have exactly same feature set, but one is FIPS 140-2 | > >Level 1 certified but cost twice. Would you go for it, considering the | > >Level 1 is the lowest. | | > Assuming that the two products use Internet protocols (as compared to | > proprietary protocols): no. Probably the only thing that could | > differentiate the two is if the cheaper one has a crappy random number | > generator, the more expensive one will have a good one. | | Actually you cant even guarantee that because the FIPS 140 requirements | for the ANSI X9.17/X9.31 PRNG include a pile of oddball things that made | sense for the original X9.17 use (where it was assumed the only source | of entropy was a DES3 key embedded in secure hardware) but are severe | restrictions on current implementations. As a result a FIPS 140- | certified key generator will be worse than a well-designed non-FIPS-140 | one because the FIPS requirements prevent you from doing several things | that would improve the functioning like injecting extra entropy into the | generator besides the DES3 key. I think this was changed as FIPS 140 evolved. Several things about the random number generator evolved. For example, in earlier versions, you had to run some tests on your generator at every startup. That disappeared by FIPS 140-2. (It makes sense for a hardware generator, but never did for software.) I don't have the actual text handy now, but to the best of my recollection, there are now two approved PRNG's you can use, and the way the text is written, what's mainly important is that you run the internal state through the PRNG before exporting it. You're definitely free to set the starting state using any source of entropy you like. I *think* you can add extra entropy along the way; though even if this were not allowed, you could probably declare that you were restarting. (Of course, this might allow the silly implementation that restarts with state 0 on every call. There's enough leaway in the wording of the standard to allow a lab to toss out such a thing.) | In addition since no two eval labs can | agree on exactly what is and isnt OK here its pretty much a crap-shoot | as to what you can get through. Ive heard stories from different vendors | of Lab B disallowing something that had already been certified by Lab A | in a previous pass through the FIPS process. This could happen, but probably not because of a disagreement between the labs as such: The interpretation of the standard changes over time. In fact, it's the interpretations - which only insiders really get to learn about - that really define what the thing means; the written standard leaves way too much open, most especially for software. (It's reasonably clear what it means to isolate hardware - though beyond that there are some pretty specific discussions of potting technology and such - but isolation for software? That whole area has been defined by interpretation.) For what it's worth, I've been involved in (parts of, never worked through the whole process) both FIPS 140 and Common Criteria validations. The latter strike me as fairly vacuous: Shoot your arrow (write your code), paint circles around it (define your protection profile), declare you shot a bull's eye (certified!). FIPS 140 *can* have some real teeth, but it can also be gamed - again, especially for software. All the real meat is in the definition of the envelope. I can declare I have a FIPS 140 certification for my AES implementation - and then use a completely separate, insecure implementation, just so long as I use it for "data scrambling" instead of "encryption". A good lab will call you if you play too many games, but ultimately labs are paid to complete certifications, not to block them. So it's caveat emptor: The full certification report is available for the customer's review. If you're concerned, get a copy and read it. If the vendor was gaming the system, that will show. If he made a really serious effort, that will show, too. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
> restrictions on current implementations. As a result a FIPS 140- > certified key generator will be worse than a well-designed non-FIPS-140 > one because the FIPS requirements prevent you from doing several things > that would improve the functioning like injecting extra entropy into the > generator besides the DES3 key. That's interesting. I would have expected to revise things like that for FIPS140-*2*. > In addition since no two eval labs can > agree on exactly what is and isnt OK here its pretty much a crap-shoot > as to what you can get through. Ive heard stories from different vendors > of Lab B disallowing something that had already been certified by Lab A > in a previous pass through the FIPS process. I had a talk with a FIPS-140 lab. I have been told, that undocumented wording has to be used that only the labs know. The FIPS-140 is to me a obscure process. And btw. the lab told me, that "they" don't want to have called it a "certification" (despite getting a certificate), but a "validation". Mahlzeit, Matthias -- Matthias Bruestle, Managing Director - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
[I was asked to forward this anonymously. --Perry] From: [Name Withheld] To: [email protected] Subject: Re: How important is FIPS 140-2 Level 1 cert? Paul Hoffman <[EMAIL PROTECTED]> wrote: > At 11:25 AM -0500 12/21/06, Saqib Ali wrote: > >If two products have exactly same feature set, but one is FIPS 140-2 > >Level 1 certified but cost twice. Would you go for it, considering the > >Level 1 is the lowest. > Assuming that the two products use Internet protocols (as compared to > proprietary protocols): no. Probably the only thing that could > differentiate the two is if the cheaper one has a crappy random number > generator, the more expensive one will have a good one. Actually you cant even guarantee that because the FIPS 140 requirements for the ANSI X9.17/X9.31 PRNG include a pile of oddball things that made sense for the original X9.17 use (where it was assumed the only source of entropy was a DES3 key embedded in secure hardware) but are severe restrictions on current implementations. As a result a FIPS 140- certified key generator will be worse than a well-designed non-FIPS-140 one because the FIPS requirements prevent you from doing several things that would improve the functioning like injecting extra entropy into the generator besides the DES3 key. In addition since no two eval labs can agree on exactly what is and isnt OK here its pretty much a crap-shoot as to what you can get through. Ive heard stories from different vendors of Lab B disallowing something that had already been certified by Lab A in a previous pass through the FIPS process. In terms of its value, particularly for level 1, what itll give you is (1) protection from egregiously bad implementations (which a quick source code check will do as well) and (2) the ability to sell to US federal agencies. Beyond that I concur that 10 minutes of interop testing with the standardised protocol of your choice (e.g. TLS, S/MIME, IPsec) will give you more than FIPS 140 will since a run of TLS tests much more of the crypto than FIPS 140 does. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
At 8:15 PM -0500 12/21/06, Saqib Ali wrote: Assuming that the two products use Internet protocols (as compared to proprietary protocols): I don't understand this statement. What do you mean by internet protocol vs proprietary protocol??? Now seeing what your company does, I can see where you might have that question. An overly-simple but sufficient answer comes from whether or not you need to be able to interoperate with other vendors over a non-secured network. If so, call it an "internet protocol". In your case (local disk encryption), it is fine to be proprietary. And also we are looking at FDE solutions, so there are no internet protocols involved in that. Right. no. Probably the only thing that could differentiate the two is if the cheaper one has a crappy random number generator, the more expensive one will have a good one. well I think FIPS 140-2 Level 1 ensures more than just a good PRNG. Even if a public crypto (e.g. AES) is used in a product, there are many mistakes that can be made during the implementation. ... and essentially all of those mistakes are caught by even mild interop testing. Again, this is not valid in your case. You could completely mis-implement AES and never know it, but a FIPS 140-2 test would find that. And FIPS 140-2 Level 1 is expected to catch these egregious mistakes. You can catch such mistakes for a lot less money than it will cost for a FIPS certificate. Assuming that you are using a standard encryption algorithm like AES, there are probably a dozen people on this mailing list who could sanity check your product's implementation of AES (and probably even of key storage) in less than 50 hours of consulting time, --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
Assuming that the two products use Internet protocols (as compared to proprietary protocols): I don't understand this statement. What do you mean by internet protocol vs proprietary protocol??? And also we are looking at FDE solutions, so there are no internet protocols involved in that. no. Probably the only thing that could differentiate the two is if the cheaper one has a crappy random number generator, the more expensive one will have a good one. well I think FIPS 140-2 Level 1 ensures more than just a good PRNG. Even if a public crypto (e.g. AES) is used in a product, there are many mistakes that can be made during the implementation. And FIPS 140-2 Level 1 is expected to catch these egregious mistakes. saqib http://www.full-disk-encryption.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
At 11:25 AM -0500 12/21/06, Saqib Ali wrote: I would like to know how much weight people usually give to the FIPS 140-2 Level 1 certification. US federal agencies are supposed to require that certification for any system they buy that uses crypto. Sometimes, US state agencies require it as well. Sometimes, clueless corporations require it because it has the word "certification" in it and, well, if it's good enough for the feds, it should be good enough for everyone. If two products have exactly same feature set, but one is FIPS 140-2 Level 1 certified but cost twice. Would you go for it, considering the Level 1 is the lowest. Assuming that the two products use Internet protocols (as compared to proprietary protocols): no. Probably the only thing that could differentiate the two is if the cheaper one has a crappy random number generator, the more expensive one will have a good one. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
