Re: secure CRNGs and FIPS (Re: How important is FIPS 140-2 Level 1 cert?)

2007-01-08 Thread Matthias Bruestle
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?

2007-01-02 Thread Peter Gutmann
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?

2007-01-02 Thread Peter Gutmann
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?

2007-01-02 Thread Ben Laurie
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?

2007-01-02 Thread lists
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?

2006-12-27 Thread Thor Lancelot Simon
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]


Re: How important is FIPS 140-2 Level 1 cert?

2006-12-27 Thread lists
On 22 Dec 2006 11:43:58 -0500, Perry E. Metzger wrote:
 [I was asked to forward this anonymously. --Perry]
 
 From: [Name Withheld]
 To: cryptography@metzdowd.com
 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 this overall thread, it seems FIPS 140 is still considered some sort 
of voodoo. The FIPS 140-2 requirements are public [3], and
even the ambiguous areas have standard interpretations at this point.)

-Andrew

[1] http

Re: How important is FIPS 140-2 Level 1 cert?

2006-12-26 Thread Peter Gutmann
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]


secure CRNGs and FIPS (Re: How important is FIPS 140-2 Level 1 cert?)

2006-12-26 Thread Adam Back
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?

2006-12-24 Thread Matthias Bruestle
 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?

2006-12-24 Thread Leichter, Jerry
| From: [Name Withheld]
| To: cryptography@metzdowd.com
| 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?

2006-12-22 Thread Paul Hoffman

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]


Re: How important is FIPS 140-2 Level 1 cert?

2006-12-22 Thread Saqib Ali

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?

2006-12-22 Thread Paul Hoffman

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?

2006-12-22 Thread Perry E. Metzger

[I was asked to forward this anonymously. --Perry]

From: [Name Withheld]
To: cryptography@metzdowd.com
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]