[445] in Kerberos
Re: Re: Lifetimes in tickets
daemon@TELECOM.MIT.EDU (Steve Miller)
Tue Jul 12 15:44:14 1988
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
From: DECWRL::"jb%cs.brown.edu@RELAY.CS.NET" "Jim Bloom 11-Jul-88 1553 EDT" 11-JUL-1988 18:09
To: Clifford Neuman <bcn%arctic.uit.uninett@TOR.NTA.NO>
Subj: Re: Liftimes in tickets
Cc: kerberos@ATHENA.MIT.EDU
I agree that the liftimes need a longer timeout. I personally think
the granularity should be in seconds. I realize this is probably much
finer than needed, but it makes calculations easier. Most machines
have a clock which counts seconds (plus maybe finer times). Working
in minutes, more arithmetic is required every time the lifetime is
checked. The disadvantage of this is that the field would need to be
at least 3 bytes long to record a reasonable maximum timeout (2 bytes
maxs out at 18 hours).
What's the tradeoff of encrypting additional bytes versus having to
convert time units (a multiplication or division)?
Jim
>> This is a bad tradeoff; encryption is much more expensive than arithmetic.
>> For example, the moderately optimised Athena DES code took 2.5 milliseconds
>> per 8 byte block, that is over 300 usec per byte on a Microvax II. And
>> each byte in the ticket is encrypted twice at the Kerberos server, and
>> once at the client and once at the server. By comparison, a single integer
>> multiply or divide on a Microvax II is at most a few tens of microseconds
>> (I don't have the exact figures handy), which is an order of magnitude
>> cheaper.
>>
>> Steve.
