> So anything that uses LD_PRELOAD is suspect, such as ElectricFence? Well, it shouldn't be; that's the point. And the problem with the current code.
> Since using the same malloc() and calloc() implementations are > extremely important for application compatibility [especially on > Windows as a DLL], those functions have to be overrideable to use > whatever implementation the host program has... even if it differs > from the OS-specific one. There are limits and trade-offs. Classic OS/library features don't have to be within the secure boundary. But to say that something like the big number package, or the DES implementation used by the exported API needn't be? > have any hard data at all. However, I can hypothesize, and so I > shall: > > There are likely architectures where an alternative BN implementation > may be more efficient -- and there are definitely architectures where > the current BN implementation will not run at all. Nope, you can't do that. What's the point of validation of the real part of the implementation (e.g., RSA without a bignumber package??) isn't part of the validated code? > After more serious reflection (and input > from the open community, since the CMVP does not discuss validation > with people outside of the company which submitted the validation > request until the validation passes), they most likely recognized the > sub-optimal nature of that decision, and decided to suspend the > validation. It is unfortunate that the FIPS module was developed in such a closed source manner. There are many people who would have caught these flaws much earlier in the process. > As long as the validation query/response uses the externally-available > APIs, and the code path during self-test goes through the same > internal implementation, it would appear to be fine. If it doesn't, > though, there's a problem. And that is exactly what is the problem with the DES self-test. I was wrong when I said that decryption isn't tested -- I took another look at the code and misread it. But still, the wrong routine is what's tested. > If the CMVP and NIST both are satisfied, the certificate will be > reissued. Current implementations of OpenSSL-fips-1.0 are, notably, > still validated unless it is truly revoked by the NIST. (Clerical > errors notwithstanding.) I assume you mean the validation lab and CMVP/NIST... As for whether or not it's still validated, you have to read http://csrc.nist.gov/cryptval/140-1/1401val.htm . As I interepret it, if you downloaded the code prior to the date of suspension, you can still use it. If you downloaded it /after/ the suspension, you cannot use it. Is there any other way to view 'procurement' for OSS than download? > ...I just wish that it were more transparent so that any further > disasters could be foreseen and averted. Yes. This is primarily what I was alluding to when I said changes in process. /r$ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
