Proposed modifications to replay cache to prevent false positives
jhutz at cmu.edu
Fri May 27 17:54:30 EDT 2005
On Friday, May 27, 2005 05:21:56 PM -0400 Jeffrey Altman
<jaltman at columbia.edu> wrote:
>>> One question that is outstanding is which hash algorithm should be used?
>> I'd suggest SHA-1. Yeah, we could have collision issues, but if
>> someone's trying to generate authenticators that will produce false
>> replay detections, let 'em. And any work done to optimize either the
>> replay cache code or the AES/SHA1 cryptosystem will benefit both.
>> Or, truncated SHA-1, to maybe 128 bits (quick to compare on a 64-bit
>> Maybe make it configurable, by writing some identifying value into the
>> record (the server field, maybe). We wouldn't have to support any other
>> value right now, but maybe having a marker there might help a
>> transition? Then again, in the long term, we probably want to change
>> the format more drastically anyways, so never mind....
> I think we want to avoid the configurability at the moment. We can
> use the server string as a marker for the type but I think having
> multiple hash types in the file is only going to get us into trouble.
Configurability in this dimension is not that important, at least for the
moment. However, _extensibility_ is important. Don't paint yourselves
into a corner in which you can't transition from one hash to another. In
my mind, this means the hash type would need to be recored in each entry,
so that future code can handle caches with two hash types, for transition
I'd also suggest including the hash type in the client-principal entry,
leaving the server entry available for future extension or for use in
easing a transition to a completely different format. I'm not saying it'll
definitely be needed for that purpose, but it can't hurt to leave the
As far as the timestamp goes, I would recommend the use of a 32-bit
timestamp, and transitioning to a new file format sometime in the next 30
More information about the krbdev