[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] On Hash Collisions (28C3)
From: |
John Cowan |
Subject: |
Re: [Chicken-hackers] On Hash Collisions (28C3) |
Date: |
Sun, 1 Jan 2012 10:29:18 -0500 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Peter Bex scripsit:
> Yes, and doing it in *every* *freaking* program. Including
> third-party libraries written long ago or by people assuming a sane
> srfi-69 implementation (or more likely, not having thought about it).
Not at all. Only fixing programs that are exposed to potentially
malicious data, like HTTP request parameters.
> There is almost no cost; just one call to get a random number when
> creating the hash table and one extra xor when hashing a value.
Well, that would certainly be reassuring, except for this:
1) If the number is only pseudo-random a la SRFI 27, you have only
increased the resistance but not eliminated the problem. The algorithm
is still published and predictable, just more complex.
2) If the number is truly random (from /dev/random or what not) it is
definitely not cheap. A program that allocates lots of hash tables will
find itself running very slow indeed.
--
I marvel at the creature: so secret and John Cowan
so sly as he is, to come sporting in the pool address@hidden
before our very window. Does he think that http://www.ccil.org/~cowan
Men sleep without watch all night?
[Chicken-hackers] [PATCH] Proper fix for hash collision attack [Was: Re: On Hash Collisions (28C3)], Peter Bex, 2012/01/04