Thanks Viktor. Obviously, not enough coffee. :-) Brian
On Sat, Feb 21, 2015 at 2:50 PM, Viktor Dukhovni <[email protected]> wrote: > On Sat, Feb 21, 2015 at 02:15:31PM -0800, Brian Dickson wrote: > > > If the same NSEC3PARAMs are used, the same input -> same output, i.e. for > > owner FOO, NSEC3 owner is BAR. Changing the SALT and leaving the alg and > > iterations unchanged, means FOO now hashes to BAR_PRIME. > > > > If everyone used the same SALT, alg, and iterations, the attacker would > > be able to add to her dictionary by attacking each hashed value once. > > This is not the case. Even with the same salt everywhere, the same > relative names yield different NSEC3 hashes in different domains. > > $ ldns-nsec3-hash -t 10 -s deadbeef www.example.com > posh7b8ariqtee5s9bji4jvlhmj5qtbn. > > $ ldns-nsec3-hash -t 10 -s deadbeef www.example.net > mj2fbsp4rqaqd2u1d1jhlr3scqeqi11i. > > That's because the hash covers the full domain name, not just some > "prefix" labels. So NSEC3 hashes are already effectively "salted" > with the zone name. What "salts" do is allow each domain to further > impede off-line dictionary attacks (via per-domain rainbow tables) > by periodically changing the salt. > > > > However, if everyone used random SALT, even with same alg and iterations, > > the dictionary of hashed values becomes worthless, and the attacker needs > > to maintain a dictionary of unhashed values, and need to hash the entire > > dictionary to find matches on each subsequent zone. > > No, it is OK for everyone to use the same salt, because that salt > is combined with their unique domain name. For high value domains, > what is perhaps useful is to change the salt periodically. > > For example, everyone could use the calendar YYYYMM (year + month) > as the salt. And the attacker would need a new rainbow table for > each domain every month. The fact that the salt is the same > everywhere would not be helpful to the attacker. Of course knowing > future values of the salt would make it possible to start computing > the rainbow tables sooner, so the problem with YYYYMM is predictability, > rather than use by multiple domains. > > -- > Viktor. > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
