<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 4, 2014 at 5:11 PM, Christian Huitema <span dir="ltr"><<a href="mailto:huitema@huitema.net" target="_blank">huitema@huitema.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> To a programmer a good hash table is not the same as a good crypto hash.<br></span></blockquote><div>..... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>Actually, it is a bit more complex than that. In many applications, you have to be concerned about denial of service attacks. If an outsider can manufacture hash collisions, then you can end up with a serious issue, the hash resolution moving for example from O(1) to O(N). Think for example of a hash table going from TCP headers to TCP context, and a SYN attack amplifying the damage by picking combinations of address and ports that result in hash collisions.<br></blockquote><div><br></div><div>Absolutely....  it is clearly necessary to understand how data can be messed with</div><div>and more to the point that it can or cannot be messed with.</div><div><br></div><div>It gets interesting when an application fully in control of data in and out is modified</div><div>and opened to the world in a more general case.   The initial assumptions are now</div><div>invalidated and the new context needs to be reconsidered.   The impact is often</div><div>less obvious than one might hope (and could make your heart bleed).</div><div><br></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr">  T o m    M i t c h e l l</div>
</div></div>