Info regarding MIT 1.8 Crypto modularity feature.

[Use Nas]

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 gmail.com> 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 jpl.nasa.gov> wrote:
>
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>
>