It's worth pointing out that if the salt is somehow exposed to an
attacker, or is guessable, much of the benefit goes away. It's likely
that a timing attack could be used to discover the salt if it is fixed
per machine or process over a long period of time.
If a salt is generally fixed per machine
> I'm not too concerned about a 3rd party being able to guess the random seed
> -- this would require much more effort on their part, since they would have
> to generate a new set of colliding keys each time they think they have
> guessed the hash
This is incorrect. Once an attacker has guessed th
> Still, it would represent an effort for the attacker of a much greater
> magnitude than the current attack. It's all a trade-off -- at some point
> it'll just be easier for the attacker to use some other vulnerability. Also
> the class of vulnerable servers would be greatly reduced.
I agree that
> But how about precomputing the intermediate value (x)? The hash is (mostly)
> doing x = f(x, c) for each c in the input.
That's a fair point. If we go down that avenue, I think simply
choosing a random fixed starting value for x is the correct choice,
rather than computing an intermediate value.
> Different concern. What if someone were to have code implementing an
> external, persistent hash table, using Python's hash() function? They might
> have a way to rehash everything when a new version of Python comes along,
> but they would not be happy if hash() is different in each process. I
>
I fixed a couple things in my proposed algorithm:
https://gist.github.com/0a91e52efa74f61858b5
I had a typo, and used 21 instead of 12 for the size multiplier. We
definitely don't need 2MB random data.
The initialization of r was broken. Now it is an array of ints, so
there's no conversion when i
> As I understand it, the way the attack works is that a *single*
> malicious request from the attacker can DoS the server by eating CPU
> resources while evaluating a massive collision chain induced in a dict
> by attacker supplied data. Explicitly truncating the collision chain
> boots them out a
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb wrote:
> I agree; it sounds really odd to throw an exception since nothing is actually
> wrong and there's nothing the caller would do about it to recover anyway.
> Rather than throwing an exception, maybe you just reseed the random value for
> the h
> I may have a terminology problem here. I expect that a random seed must
> change every time it is used, otherwise the pseudorandom number generator
> using it just returns the same value each time. Should we be talking about a
> salt rather than a seed?
You should read the several other threads,
> We may use a different salt per dictionary.
If we're willing to re-hash everything on a per-dictionary basis. That
doesn't seem reasonable given our existing usage.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
10 matches
Mail list logo
