[Cryptography] Creating a Parallelizeable Cryptographic Hash Function

Tom Mitchell mitch at niftyegg.com
Wed Oct 8 21:56:12 EDT 2014


On Wed, Oct 8, 2014 at 9:20 AM, Bear <bear at sonic.net> wrote:

> On Sat, 2014-10-04 at 17:11 -0700, Christian Huitema wrote:
> > > To a programmer a good hash table is not the same as a good crypto
> hash.
> > > A programmer simply wants a fast lookup with a minimum miss, collision.
> > > Most programmers do not care if a collision is moderately easy to
> fabricate
> > > because they want to get close enough not exactly and will walk their
> way to
> > > the desired data (short walk).
> >
> > Actually, it is a bit more complex than that. In many applications, you

....

> > and ports that result in hash collisions.
>
> True, but he has a point.  In most programming applications a hash
> drives a hash table in a context where we aren't at all worried about
> an attacker.
>
......

> For example,
> Table hashes, usually, are not cryptographic hashes.
>
>
Thank you..
Exactly my point.   As people research ways to speed up
hash functions knowing exactly what the goal is is key.  More importantly
when something changes and an internal hash lookup becomes external
because it is a handy handle a risk surfaces.   Anytime specifications
change
it is necessary to flip the full chain of dominoes to see what gets touched
and what might get exposed.     Incautious use of a single word in a
specification
can insert a problem inadvertently.   T.hash  C.hash and others?



-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141008/0ea38dbe/attachment.html>


More information about the cryptography mailing list