[16059] in Kerberos_V5_Development
Re: Info regarding MIT 1.8 Crypto modularity feature.
daemon@ATHENA.MIT.EDU (Zhanna Tsitkova)
Mon Aug 16 11:32:04 2010
Message-Id: <74E2309B-04BF-4712-A59B-FE445293214B@mit.edu>
From: Zhanna Tsitkova <tsitkova@mit.edu>
To: "jaltman@secure-endpoints.com" <jaltman@secure-endpoints.com>
In-Reply-To: <4C694A6A.5080409@secure-endpoints.com>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 16 Aug 2010 11:31:51 -0400
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@mit.edu
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
