This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients Arfrever, PaulMcMillan, Vlado.Boza, alex, arigo, benjamin.peterson, camara, christian.heimes, dmalcolm, koniiiik, lemburg, serhiy.storchaka, vstinner
Date 2012-11-06.16:08:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352218083.47.0.0151481153495.issue14621@psf.upfronthosting.co.za>
In-reply-to
Content
I deem hash randomization and collision counting as a poor man's workaround for the actual issue. Perhaps we shouldn't try too hard to fix an unsuitable data type. Hash maps have a known worst case complexity of O(n). A O(log n) algorithm should be used to parses and malicious key/value pairs.

How about Python grows a additional btree implementation in its collections module? I know that it's not going to fix existing code. However in the long run it's the best safeguard against hash collision attacks. I'm thinking about a simple, self balancing btree like red-black-tree. A quick search on Wikipedia also revealed Scapegoat and Splay tree with interesting properties.
History
Date User Action Args
2012-11-06 16:08:03christian.heimessetrecipients: + christian.heimes, lemburg, arigo, vstinner, benjamin.peterson, Arfrever, alex, dmalcolm, PaulMcMillan, serhiy.storchaka, Vlado.Boza, koniiiik, camara
2012-11-06 16:08:03christian.heimessetmessageid: <1352218083.47.0.0151481153495.issue14621@psf.upfronthosting.co.za>
2012-11-06 16:08:03christian.heimeslinkissue14621 messages
2012-11-06 16:08:02christian.heimescreate