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