> 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
> 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,
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
> 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
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
> 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
>
> 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.
> 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
> 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
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
10 matches
Mail list logo
