On Tue, Jun 22, 2004, Marquess, Steve Mr JMLFDC wrote: > > So far I've been pestering Ben directly, but now that we've reached > the formal submission watershed I'd like to ask for assistance of > the larger developer team. Two patches are enclosed. One removes > non-FIPS algorithms from the SSL ciphersuite. The other attempts to > disable non-FIPS algorithms at a fairly low level using NID ids. >
It looks like the NID approach is checking a list of unapproved algorithms and returning false otherwise returning true. New algorithms can be added and new NIDs assigned including some external implementations which may use invalid NIDs which would become acceptable with that logic. I'd recommend the reverse: maintain a table of approved NIDs and use return true otherwise return false. That would only work however for internal implementations. An ENGINE could, for example, implement AES and use the AES NID but it might not be FIPS certified. I'd say a better approach is to include a flag in the EVP_CIPHER and EVP_MD structures which is set for an FIPS certified implementation. This would also need some code to ensure that a none FIPS implementation can't become the default algorithm or perhaps can't be added at all. None of that will help the low level APIs though: an application could use those directly. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
