Marc-Andre Lemburg <m...@egenix.com> added the comment:
On 07.10.2021 12:48, Christian Heimes wrote: > >> I don't quite follow. Why is it fine that you discuss DoS, but it's not > fine when others discuss DoS ? > > But this BPO is not about discussing mitigations against DoS attacks in > general. It's about adding SipHash1-3- and following the example of Rust and > Ruby. > > If you like to discuss DoS attacks on hashing of numeric types or other > mitigations, then please do this in a dedicated ticket. I like to keep this > BPO focused on a single topic. The point that both Victor and I wanted to make is that we have different views on the relevance of DoS attack mitigations on selecting the default hash algorithm to use with Python strings (and other objects which use pyhash.c). The motivation for moving to siphash 1-3 is performance and we can potentially get even better performance by looking at today's hash algorithms and revisiting the decision to go with siphash. This broadens the discussion, yes, but that can easily be addressed by changing the title to e.g. "Revisiting the default hash algorithm for strings". Since siphash is a crypto hash function, whereas xxhash (and other faster hash algorithms) are non-crypto hash functions, the topic of hash collisions which can be used for DoS becomes relevant, so I don't see why such discussions are off-topic. With non-crypto hash algorithms available which exhibit good collision stats and taking into account that DoS can be mitigated using other ways (which is essential anyway, since Python doesn't protect again hash based DoS in all cases), we get to a better Python. More details on xxhash collision stats: https://github.com/Cyan4973/xxHash/wiki/Collision-ratio-comparison#collision-study ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29410> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
