> On Aug 26, 2018, at 3:59 PM, Paul Vixie <vi...@fsi.io> wrote: > >> On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote: >> ... >> Nice properties of the hash: >> >> 1. the length of the output value is consistent across varying input lengths >> of any RR type (128 bits in the case of the algorithm specified in the >> draft) making it easy to sequence through. 2. it’s independently verifiable >> between servers and across time on the same server 3. it’s independent of >> position of the RR it covers >> 4. it works the same for all existing RR’s as well as RR’s yet to be defined >> >> Other methods may share some of these properties but I’m just listing all of >> the ones I can think of. > > as i wrote about a hash that was proposed in part of zone catalog work, there > are two things that are really bad about these. > > 1. the resulting design is not collision-resilient > > 2. the hash will have to change some day, invoking rollover complexity cost > > while DHT is a better example of "use a hash because it's magic and makes it > look like our coherency problems have gone away", in fact all non-security- > related hash uses should be suspected of the same. you won't want to use a > hash in a distributed system (where hash values have to be portable) unless > every alternative has a vastly higher cost. > > -- > Vixie
SHAKE128 as well as other SHA-3 algorithms have been found to be quite collision resistant. Tom _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
