Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.

[Viktor Dukhovni <[e-mail]>]

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.