"
The non-sequestered versions of the FIPS algorithms are
omitted entirely
(by "#ifndef OPENSSL_FIPS..." wrappers) when building in fips
mode, so how
would both FIPS and non-FIPS implementations co-exist? You are thinking
of
the possibility of adding both implementations using different names...?
"
We have code which "namespaces" OpenSSL.
It was written to allow our code to coexist with other versions of OpenSSL in the same process, but that's pretty much what you are talking about.
It's tidy enough to allow the SSL layer to continute to work with only a recompile.
We are planning on donating that code to OpenSSL anyway - so if you want to go that route, let me know.
Peter
Peter
Peter Waltenberg
Architect
IBM Crypto for C Team
IBM/Tivoli Gold Coast Office
Phone: +61-7-55524016
| "Marquess, Steve Mr
JMLFDC" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 25/06/2004 12:31 AM
|
|
On Wednesday, June 23, 2004 1:14 PM Dr. Stephen Henson wrote:
>The flag would be set in the definitions of the EVP_CIPHER
and EVP_MD
>structures if the FIPS compilation flag is set. This would also allow
FIPS and
>none FIPS implementations of the same algorithms to coexist.
The non-sequestered versions of the FIPS algorithms are
omitted entirely
(by "#ifndef OPENSSL_FIPS..." wrappers) when building in fips
mode, so how
would both FIPS and non-FIPS implementations co-exist? You are thinking
of
the possibility of adding both implementations using different names...?
>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?
>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.
>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?
The one exception I would make is MD5, as Ben has already
disabled it
in non-FIPS mode and provided a mechanism for explicitly re-enabling
it as required for legacy support. At least the developer will be
aware of this usage.
>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.
-Steve M.
