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

[Brian Dickson <[e-mail]>]

Thanks Viktor. Obviously, not enough coffee. :-)

Brian

On Sat, Feb 21, 2015 at 2:50 PM, Viktor Dukhovni <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>