Info regarding MIT 1.8 Crypto modularity feature.
Henry B. Hotz
hotz at jpl.nasa.gov
Mon Aug 16 21:24:12 EDT 2010
On Aug 16, 2010, at 9:05 AM, krbdev-request at mit.edu wrote:
> Date: Mon, 16 Aug 2010 11:31:51 -0400
> From: Zhanna Tsitkova <tsitkova at MIT.EDU>
> Subject: Re: Info regarding MIT 1.8 Crypto modularity feature.
> To: "jaltman at secure-endpoints.com" <jaltman at secure-endpoints.com>
> Cc: "krbdev at mit.edu" <krbdev at mit.edu>
> Message-ID: <74E2309B-04BF-4712-A59B-FE445293214B at mit.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> Well, we have discussed these scenarios internally and ended up with
> "one crypto implementation per kerberos crypto library" scenario for
> the reasons of better sense of security and integrity.
> For example, mixing FIPS 140.2 and non-FIPS modes - who wants to be
> FIPS approved? - finance, government, heathcare and friends. It is
> unlikely that any of them would consider refining and potentially
> jeopardizing their configuration to speed-up things for the sake of
> slight (or even significant) performance gain. Or, at least, they
> would definitely use different machines for these different tasks.
> As for Shipping a binary that can support hardware and non-hardware
> implemented encryption, this case is tougher one to ague with.
> However, I think, if hardware accelerators are available, one will
> always prefer to take advantage of them.
> Finally, performance testing, in my opinion, is much cleaner when it
> does not resolve the specifics of the configuration setup during run-
I think these are all arguments that it's possible to live without run-time library selection, rather than arguments that users necessarily prefer being locked into a single selection.
Ignoring implementation difficulty (which is a big deal, I know) I would always prefer to have the run-time option as long as the option never causes any run-time failures. ;-)
FIPS-mode seems like a special case. A FIPS-approved library (well, at least openssl) is likely to have a non-FIPS mode which may be faster and probably supports additional encryption types (RC4, Camillia?). I'd think it was trivial to select FIPS/non-FIPS at run time, and that might make it easier to flag non-FIPS to a user who is expecting FIPS mode.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the krbdev