On Wed, Dec 14, 2016 at 12:48 AM, Stephen Farrell <[email protected] > wrote:
> > Hiya, > > Just a comment from the sidelines... > > On 14/12/16 00:20, Bill Frantz wrote: > > > > "Suitable for use as a cryptographic hash with no known preimage or > > collision attacks. These attacks can damage the integrity of the log." > > If taking this approach it might be useful to consider the > duration for which any such properties are desired, e.g. to > consider how that duration maps to hashes used in certificate > signing would seem like a natural enough thing to do. And it > might even be the case that such consideration provides a way > to avoid a separate registry maybe, not sure. > IIUC the question is for how long a hash algorithm used in a log should be resistant to preimage or collision attacks. A simple answer would be "for the entire lifetime of the log" (with the expectation that new logs would be spun up with better hash algorithms if the one in current use doesn't have these properties anymore). A more in-depth analysis of how the protocol would break if the hash algorithm used by logs is a good idea, merits more thought though (and may belong in the threat analysis document?). Re a separate registry, I've looked into re-using existing registries (following a suggestion from a colleague, David Drysdale), but concluded that it would complicate implementation by tying them to implementations of more hash algorithms than is necessary or useful to the protocol. Since each hash algorithm has to be evaluated for suitability for use in CT logs anyway, I didn't see much point in re-using an existing registry and specifying a bunch of exceptions on top of it. > > S. > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
