<tt><font size=2>Jakob Schlyter wrote on 09/09/2009 11:39:38 AM:<br>
</font></tt>
<br><tt><font size=2>> On 9 sep 2009, at 11.01, Jakob Schlyter wrote:<br>
> <br>
> > I suggest we get rid of the only HSM call that we have in the
 <br>
> > communicator/libksm, the salt generation, and use some other
random  <br>
> > function instead. generating the salt is not critical and libhsm
to  <br>
> > this doesn't really help that much.<br>
> <br>
> so I'm saying this code (now used when no HSM is found) is good enough
 <br>
> for generating the salt:<br>
> <br>
>                  srand(
time(0) );<br>
>                  for
(i = 0; i < 2*(policy->denial->saltlength); i++) {<br>
>                    
 salt[i] = hex_chars[rand()%strlen(hex_chars)];<br>
>                  }<br>
> <br>
> remember that the salt is published in the zone and does not have
to  <br>
> be very random.<br>
</font></tt>
<br><tt><font size=2>Speaking as (one of the) authors of RFC5155, the salt
has one, but only one function: to complicate enumeration efforts that
make use of dictionary containing hash to name mappings (like rainbow tables
and the like). If a zone with salt X is largely enumerated and the hash
to name mappings are stored in a dictionary, an attacker can skip those
hashes already matched when enumerating a new version of the zone, i.e.
the enumeration effort becomes incremental. A new salt makes the previous
hash to name mapping obsolete. </font></tt>
<br>
<br><tt><font size=2>So far the theory, now the practise:</font></tt>
<br>
<br><tt><font size=2>The drawback of changing a salt is that the entire
zone needs to be re-hashed and re-signed. So in highly dynamic environments
or when zones are very large, the cost of changing salt is high as well.
The costs really are the resigning effort and distributing the entire zone
again. With ixfr, it is even worse, as the old nsec3 chain needs to be
removed, and the new nsec3 chain needs to be added. Which basically doubles
the load.</font></tt>
<br>
<br><tt><font size=2>In general, we'll probably see that salts are not
changed regularly, if at all. I'm also seeing that registries which intend
to deploy with NSEC3 do that because of the opt-out functionality, not
just anti-enumeration. </font></tt>
<br>
<br><tt><font size=2>As for opendnssec, we'd need to make sure that automated
re-salting is off by default. Preferably ship it with a default salt. It
has no implication that the salt is the same for each opendnssec-deployment,
since there is no overlap of names that are hashed anyway.</font></tt>
<br>
<br><tt><font size=2>That said, I'm completely confident that using the
systems default random() function is good enough. Using a HSM for that
is just too much. Get rid of it.</font></tt>
<br>
<br><tt><font size=2>Kind regards,</font></tt>
<br>
<br><tt><font size=2>Roy Arends</font></tt>
<br><tt><font size=2>Sr. Researcher</font></tt>
<br><tt><font size=2>Nominet UK</font></tt>