|
BugTraq
Algorimic Complexity Attacks May 29 2003 08:33PM Scott A Crosby (scrosby cs rice edu) (1 replies) Re: Algorimic Complexity Attacks May 31 2003 03:13AM Solar Designer (solar openwall com) (1 replies) Re: Algorimic Complexity Attacks Jun 07 2003 05:01PM Pavel Kankovsky (peak argo troja mff cuni cz) (1 replies) Re: Algorimic Complexity Attacks Jun 07 2003 07:35PM Nicholas Weaver (nweaver CS berkeley edu) (1 replies) Re: Algorimic Complexity Attacks Jun 08 2003 04:17PM Pavel Kankovsky (peak argo troja mff cuni cz) (1 replies) Re: Algorimic Complexity Attacks Jun 08 2003 05:22PM Nicholas Weaver (nweaver CS berkeley edu) (2 replies) |
|
Privacy Statement |
Nicholas Weaver wrote:
> On Sun, Jun 08, 2003 at 06:17:38PM +0200, Pavel Kankovsky composed:
>
>>We need a function having a (relatively) small set of results in order to
>>build a hash table. We can also assume the information about collisions
>>leaks out via a timing channel. Ergo, a persistent attacker can find
>>enough collisions by trial and error.
>
> IF the hash is good, FINDING collisions doesn't necessarily help the
> attacker, as the attacker really needs to generate lots of collisions
> to make the searches O(n) instead of O(1), since that is teh key
> behind this attack.
You could do some improvement if you store the collisions
not in a list, but in a new hash table.
In that 2nd hash table you add a salt.
So the attacker must find many sets of data that result not only
in a collistion, but additional result in collisions in the
2nd hash table.
If the salt is some on the spot generated random data,
that should be nearly impossible...
Generating the 2nd hash table only if there at least n collissions
should keep the load on the system low...
Bye
Goetz
--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
[ reply ]