Joshua Hill wrote:

> 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.

I disagree. OpenSSL has a check of authenticity that works with static
libraries and linking only some of the module. I'll shout to this list
when I've written down exactly how the process works (or you can look at
CVS, coz I checked it in this afternoon [err, I think, I had some weird
problems with CVS later, so perhaps waiting a little might be advised]).




"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]

Reply via email to