Info regarding MIT 1.8 Crypto modularity feature.

Henry B. Hotz hotz at
Thu Aug 19 12:28:20 EDT 2010

Theoretically it can't, and it really shouldn't cause any interop issues because the wire protocol is specified and (to some real extent) independently tested.  The real world has a way of not living up to those ideals perfectly of course, but I'd worry more about cross-implementation issues:  MIT<-->Heimdal, MIT<-->Microsoft, etc.

On Aug 18, 2010, at 10:55 PM, Use Nas wrote:

> I have another questions regarding crpto modularity implementation for openssl. Will it break anything if the client and server are at different levels.  ( Server with latest MIT 1.8. & client with MIT 1.5 ) ?  What needs to be taken care of in these cases?..  And i believe openssl is supporting only limited encrytion alogos .. The rest are in krb folder?  Please help me understand it
> Thanks in advance.
> On Tue, Aug 17, 2010 at 12:02 PM, Use Nas <usenas at> wrote:
> I would like to have a framework on top of crypto implementation, which virtualizes these implementations [ using virtual crypto interfaces ] and based on the user input [ configurable option ], switch to specific type of crypto implementation.
> Thanks
> On Tue, Aug 17, 2010 at 6:54 AM, Henry B. Hotz <hotz at> wrote:
> On Aug 16, 2010, at 9:05 AM, krbdev-request at 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" <jaltman at>
> > Cc: "krbdev at" <krbdev at>
> > Message-ID: <74E2309B-04BF-4712-A59B-FE445293214B at>
> > 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, or hbhotz at
> _______________________________________________
> krbdev mailing list             krbdev at

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the krbdev mailing list