Info regarding MIT 1.8 Crypto modularity feature.

[Zhanna Tsitkova]

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.

Thanks,
Zhanna

On Aug 16, 2010, at 10:25 AM, Jeffrey Altman wrote:

> On 8/16/2010 9:48 AM, Zhanna Tsitkova wrote:
>> The selection of the crypto backend happens during the configure/ 
>> build
>> time.
>> For example, to use openssl cryptography one needs to configure MIT
>> Kerberos with option --with-crypto-impl=openssl. If this option is
>> omitted,  the default crypto. i.e. builtin, will be used.
>> Only one crypto implementation per  Kerberos crypto library is
>> supported. This means that client/server does not have an option to
>> specify the type of the desired crypto implementation during run- 
>> time.
>> That said, it would be interesting to learn about the use case when
>> one needs to have an option to switch between crypto implementations
>> at run-time.
>> Thanks,
>> Zhanna
>
>
> The most common use cases would be:
>
> * FIPS 140.2 vs non-FIPS modes.  In general non-FIPS will be faster
>   but for some situations a FIPS mode is required.
>
> * Shipping a binary that can support hardware and non-hardware
>   implemented encryption.
>
> * End user performance testing.
>
>
> Jeffrey Altman
>
>
>
> <ATT00001..c>

Zhanna Tsitkova
tsitkova at mit.edu