On Thu, Jun 24, 2004, Marquess, Steve Mr JMLFDC wrote:
> On Wednesday, June 23, 2004 1:14 PM Dr. Stephen Henson wrote:
>
> >If you look at crypto/evp/m_sha1.c there is a definition of the EVP_MD
> >structure for SHA1. The fourth value (currently 0) is the 'flags' field which
> >would be set to (for example) EVP_FIPS_MD where EVP_FIPS_MD is set to
> >some convenient value if the FIPS preprocessor symbol is set and 0 otherwise.
>
> Ok, after reading the source to improve my feeble comprehension I follow
> you now. Each of the digests has a statically defined EVP_MD struct with
> the unused flag word. This flag value does not appear to be used, so
> "#define EVP_FIPS_MD 0x1" and "#define EVP_FIPS_CIPHER 0x1" would
> be ok?
>
Well the flags field is already used for various things do you'd need a value
that wasn't already in use.
It looks like you'd need:
#define EVP_CIPH_FIPS 0x400
and
#define EVP_MD_FLAG_FIPS 0x0002
for the first unused values of each, though you could just stick 0x400 for
both for consistency.
> >The EVP_CIPHER cases are more complex because they are defined by macros but a
> >similar thing could be done.
>
> Those are some snarly macros, all right, but I was able to follow it I
> think. The IMPLEMENT_BLOCK_CIPHER references in evp/e_aes.c create the
> EVP_CIPHER structures for AES, for example, again with a zero flag word.
>
Yes there's an appropriate argument in the macros to set the flags value.
> >Then the EVP routines would just check to see if EVP_FIPS_MD or
> >EVP_FIPS_CIPHER is set in the flags field in FIPS mode.
>
> Which EVP routines need to be visited? I could leave out the non-FIPS
> algorithms in OpenSSL_add_all_{ciphers|digests} as you suggested in an
> earlier msg. EVP_add_{cipher|digest} I already have in my first patch.
> EVP_{Encrypt|Digest}Init_ex, ditto. EVP_get_{cipher|digest}byname? What
> else would you recommend for more or less graceful coverage for an end
> user like me with a weak grasp of the API who just wants to be sure he
> didn't accidentally invoke any forbidden algorithms?
>
Well my personal perference would be to give a hard assertion error in
EVP_DigestInit_ex() and EVP_CipherInit_ex() because a non-FIPS algorithm will
only appear in there due to an application source error.
EVP_add_{cipher|digest} could refuse to add non-FIPS algorithms or add them as
placeholders which will give an informative error if by EVP_get_digestbyname
for example is called.
>
> >That would make it impossible to call non-FIPS algorithms via EVP in FIPS
> >mode. However that isn't likely to be the whole story...
>
> Yes, the more I look into it the more complex it seems. Ben thought it
> would be merely tedious but straightforward, hence I volunteered to have
> a crack at it. I sure appreciate your help in trying to figure it out.
>
There are cases where the default algorithm is non-FIPS both at an application
and a source file level. This is either due to published standards or general
usage.
There are a large number of things to consider, some are fairly obvious but
messy to fix, others are less obvious and some are fiendishly subtle.
In the first category is things like the applications. The smime application
by default uses the 40 bit RC2 algorithm for encrypting messages. This is
specified by the standards: there are also command line options that set these.
The quick and dirty solution is to do nothing. This will mean that many
command line options wont work any more or give strange errors (possibly
assertion failures if the "hard error" option is taken) even specifying no
cipher will fail because of the default non-FIPS RC2.
A better way is to either disable the options or have them produce a meaningful
error message. As well as that the default would need to be changed to
something like triple DES instead of 40 bit RC2.
The less obvious cases are functions like PKCS12_create() which includes
some default values which via an indirect route use RC2.
Similar thinsg apply to cipher strings and SSL/TLS.
The more subtle cases involve things like the S/MIME signing code. This
advertises the supported encryption algorithms to the receiving party. It will
currently include, among other things RC2. With no changes to the code
everything would appear to work fine except that recipients might send S/MIME
email back which can't be decrypted because an algorithm is being advertised
which can't be supported.
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]
