[390] in Kerberos
Re: faster encrypted rlogin
daemon@TELECOM.MIT.EDU (Ken Raeburn)
Mon Jun 6 19:57:02 1988
From: Ken Raeburn <raeburn@ATHENA.MIT.EDU>
To: Mike Kazar <kazar+@ANDREW.CMU.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Mike Kazar's message of Mon, 6 Jun 88 18:21:21 -0400 (EDT),
Date: Mon, 6 Jun 88 18:21:21 -0400 (EDT)
From: Mike Kazar <kazar+@andrew.cmu.edu>
So, for instance, if I have a ticket authenticating me as "bogon", and it is
encrypted via your scheme (using DES/XOR with these quasi-random
numbers), then if I can find the ticket in the cleartext (which
should be easy, given the sources), I can change the ticket to
authenticate me as "kazar" instead of "bogon" by XORing the ticket
with ("kazar" XOR "bogon").
I don't think this attack would work quite as described, but there is
some possible risk here. Remember, we aren't using XOR for the
authentication encryption, just for later data. The
authenticator/ticket itself would be DES-encrypted such that only the
intended receiver could decrypt it. An XOR on this data would produce
meaningless garbage.
However, a known sequence of data could be tampered with through the
attack you describe, but only that portion for which the cleartext
(and position in the data stream) is known, but this isn't difficult.
Hmm...perhaps a randomly-generated (and constantly changing)
translation table, with offsets transmitted? It wouldn't need to be
too sophisticated, just something that couldn't be reversed (and used
in the forward direction) with a known cleartext. Perhaps using two
numbers to generate the table; for example:
Use #1 for the character \000 translates to.
Use #2 as an offset into a table of the first N numbers relatively
prime to 256, and use it as an offset to get the consecutive
numbers in the translate table. (I.e., \001 maps to (#1 + #2) mod
256, \002 maps to (#1 + 2 * #2) mod 256, etc.)
There are simpler mathematical methods for getting the results in both
directions here, but I think this provides a means by which we'd be
safe sending data without fear of eavesdropping or tampering, since in
order to substitute a (known) second value, the second random byte
would have to be known.
Would we be safe in taking two bytes of the encryption output for the
random number sequence, or should it require two passes? Doing the
latter would slow it down, but we can see how it compares against
realtime encryption....
