Info regarding MIT 1.8 Crypto modularity feature.

[Henry B. Hotz]

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- 
> time.

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