https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55815
Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |miyuki at gcc dot gnu.org
--- Comment #6 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
SipHash is not very slow, BTW. I remember doing some benchmarks (there was some
discussion about changing the hash function used for incremental hash in GCC),
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00179.html
Result for small strings (1-20 bytes) on x86_64, elapsed time (i.e. less is
better):
function | gcc -O3 | clang -O3
----------|---------|----------
murmur32 | 0.91 | 0.95
murmur128 | 1.33 | 1.24
sip24 | 1.88 | 1.45
sip13 | 1.66 | 1.22
lookup3 | 1.18 | 0.90
spooky | 1.24 | 0.90
I don't remember all the details about the workload used and which
implementation of SipHash I used (but most likely my own one).
(In reply to felix-gcc from comment #0)
> It may even make sense to replace the hash code gcc itself uses, as there
> are now web pages where you can paste code and see which code gcc generates
> for it, turning this problem into a security issue if someone pastes code
> with colliding symbols to exploit this problem.
There is a much more efficient way to attack them: search GCC bugzilla for open
bugs of type "compile time hog" or "memory hog" and simply use the code
provided there.
