Proposed modifications to replay cache to prevent false positives

Roland Dowdeswell elric at imrryr.org
Thu Jun 2 11:21:41 EDT 2005


On 1117226762 seconds since the Beginning of the UNIX epoch
Jeffrey Altman wrote:
>

>One question that is outstanding is which hash algorithm should be used?

It's probably not terribly important which algorithm is used with the
caveats that:

	1.  there are enough bits to reduce the possibility of
	    false positives, and

	2.  the hash should be performed on the authenticator prior
	    to decryption so that the ticket used is implicitly
	    part of the hashed data (since it's session key should
	    be different than any other session key) and the
	    authenticator's IV should eliminate the chance of
	    false positives using the same ticket.

Since we're only trying to stop replays, I do not think that the
hash needs to have any serious cryptographic properties at all.
The same authenticator only needs to always hash to the same value.
Collision resistance is meaningless, unless you are trying to create
false replays (for some... reason...) I'd be willing to guess that
a simple CRC would have the properties that you want.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/


More information about the krbdev mailing list