On Fri, Sep 05, 2003 at 06:02:10PM -0400, Wei Dai wrote:
> In fact they wouldn't even validate Crypto++ as a 
> static library despite an earlier verbal agreement that a static 
> library was ok. It had to be turned into a DLL at the last moment (i.e. 
> during the review phase).

That's unfortunate.  The answer as to the static vs dynamic library issue
seems to vary according to who at NIST reviews the report.  I've never
understood NIST's general objection to static libraries.

> (We wanted to avoid making a DLL from Crypto++ since it has so many 
> algorithms. With a static library the linker would only bring in the 
> algorithms you use, but a DLL has to contain a pre-selected set of 
> algorithms. I ended up putting only FIPS Approved algorithms in the 
> DLL, and made a second static library that contains only 
> non-Approved algorithms, so that both could be used together.)

So, having said that, I can say that pulling out bits of the evaluated
module won't fly.  All of it would have to go in, or none of it.  Further,
the module needs to have some way of checking its authenticity (for the
operating environment area requirements) and its integrity on "power up".
As such, you'll either need to be able to "locate" the module within
the resulting executable, or verify the entire resulting executable.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to