[1122] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Mon May 6 15:58:46 1996
To: Marc Horowitz <marc@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Sun, 05 May 1996 23:55:39 EDT."
<199605060355.XAA07537@cutter-john.mit.edu>
Date: Mon, 06 May 1996 15:22:43 -0400
From: "Donald T. Davis" <don@cam.ov.com>
marc wrote:
> I don't think performance in session key generation in the kdc is that
> important. KDC's tend to process a fairly small number of keys, the
> blocks which get encrypted are comparatively large (order 100 bytes),
> you don't issue all that many of them (a few a second, max during peak
> login times), and computers are getting faster and faster.
in its slowness, blum/blum/shub's rng is roughly similar
to rsa private-key operations: for rsa-grade security,
using a kilobit seed, you can get 10 bits per iteration,
where each iteration involves a kbit multiply & residue.
so, that's 6 iterations per des key, or 17 per 3des key.
if you're doing this much arithmetic a few times per sec,
you shouldn't plan on doing much else at the same time.
also, beware of assuming that kdc performance can come
from faster machinery; a lot of my consulting clients ask
about key-server performance, and they shop accordingly.
they always want infrastructure to be as cheap as possible,
and extra cycles aren't cheap enough. for that matter, a
lot of corporate customers look to kerberos in the first
place, only because it's faster than rsa-based security.
if you slow the kdc down with bignum arithmetic, you'll
remove kerberos' most obvious selling-point. finally, don't
forget that in many corporate environments, load-peaks
are much steeper than in engineering shops or in academic
networks.
-don
