Paul McMillan <p...@mcmillan.ws> added the comment: > Those who use or advocate a simple randomized starting hash (Perl, Ruby, > perhaps MS, and the CCC presenters) are presuming that the randomized hash > values are kept private. Indeed, they should be (and the docs could note > this) unless an attacker has direct access to the interpreter.
Except that this is patently untrue. Anytime any programmer iterates over a dictionary and returns the ordered result to the user in some form, they're leaking information about the hash value. I hope you're not suggesting that any programmer who is concerned about security will make sure to sort the results of every iteration before making it public in some fashion. > I do not think we, as Python developers, should be concerned about esoteric > timing attacks. Timing attacks are less esoteric than you think they are. This issue gets worse, not better, as the internet moves (for better or worse) towards virtualized computing. > And if hashing were randomized per process, and probes were randomly > distributed among processes, and processes were periodically killed and > restarted with new seeds, could such an attack get anywhere... You're suggesting that in order for a Python application to be secure, it's a requirement that we randomly kill and restart processes from time to time? I thought we were going for a good solution here, not a hacky workaround. > We could also consider, for 3.3, making the output of hash() be different > from the internal values used for dicts, perhaps by switching random seeds in > hash(). So even if someone does return hash(x) values to potential attackers, > they are not the values used in dicts. (This would require a slight change in > the doc.) This isn't a bad idea, but I'd be fine documenting that the output of hash() shouldn't be made public. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13703> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
