Moving to SipHash-1-3

[methane]

BPO	29410
Nosy	@malemburg, @gvanrossum, @rhettinger, @vstinner, @tiran, @methane, @markshannon, @serhiy-storchaka, @erlend-aasland
PRs	bpo-29410: Change the default hash algorithm to SipHash13. #28752
Files	siphash13.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tiran'
closed_at = <Date 2021-10-10.08:29:57.972>
created_at = <Date 2017-02-01.07:02:05.352>
labels = ['interpreter-core', '3.11', 'performance']
title = 'Moving to SipHash-1-3'
updated_at = <Date 2021-10-10.08:29:57.971>
user = 'https://github.com/methane'

bugs.python.org fields:

activity = <Date 2021-10-10.08:29:57.971>
actor = 'methane'
assignee = 'christian.heimes'
closed = True
closed_date = <Date 2021-10-10.08:29:57.972>
closer = 'methane'
components = ['Interpreter Core']
creation = <Date 2017-02-01.07:02:05.352>
creator = 'methane'
dependencies = []
files = ['46476']
hgrepos = []
issue_num = 29410
keywords = ['patch']
message_count = 50.0
messages = ['286590', '286594', '286598', '286600', '286601', '286602', '286605', '286606', '286607', '286608', '286609', '286610', '286617', '286620', '286621', '286622', '286623', '286624', '286628', '286727', '287686', '287688', '288756', '288758', '289094', '403349', '403361', '403363', '403364', '403365', '403367', '403372', '403373', '403375', '403376', '403378', '403380', '403381', '403383', '403387', '403390', '403393', '403400', '403406', '403411', '403417', '403419', '403425', '403542', '403577']
nosy_count = 9.0
nosy_names = ['lemburg', 'gvanrossum', 'rhettinger', 'vstinner', 'christian.heimes', 'methane', 'Mark.Shannon', 'serhiy.storchaka', 'erlendaasland']
pr_nums = ['28752']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue29410'
versions = ['Python 3.11']

[methane]

Rust and Ruby moved from SipHash-2-4 to SipHash-1-3.

rust-lang/rust#29754
https://bugs.ruby-lang.org/issues/13017

SipHash-1-3 seems faster than 2-4 and secure enough.

[rhettinger]

+1 The discussions on the Rust and Ruby lists seem persuasive.

[methane]

I'm running pyperformance.

BTW, hashlib doesn't provide siphash24. So can we simply replace siphash24 with siphash13, like ruby?
ruby/ruby@04c94f9

[tiran]

PEP-456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4.

On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode?

[methane]

$ ../python.default -m perf compare_to default.json patched4.json -G
Slower (2):
- scimark_sor: 479 ms +- 8 ms -> 485 ms +- 9 ms: 1.01x slower (+1%)
- genshi_xml: 196 ms +- 2 ms -> 196 ms +- 2 ms: 1.00x slower (+0%)

Faster (19):

• json_loads: 62.7 us +- 0.5 us -> 61.5 us +- 1.1 us: 1.02x faster (-2%)
• django_template: 402 ms +- 3 ms -> 395 ms +- 4 ms: 1.02x faster (-2%)
• logging_format: 36.6 us +- 0.5 us -> 36.1 us +- 0.4 us: 1.01x faster (-1%)
• xml_etree_generate: 277 ms +- 5 ms -> 274 ms +- 5 ms: 1.01x faster (-1%)
• sympy_str: 461 ms +- 5 ms -> 456 ms +- 3 ms: 1.01x faster (-1%)
• call_method_unknown: 16.6 ms +- 1.2 ms -> 16.4 ms +- 0.2 ms: 1.01x faster (-1%)
• raytrace: 1.31 sec +- 0.02 sec -> 1.30 sec +- 0.01 sec: 1.01x faster (-1%)
• python_startup_no_site: 9.81 ms +- 0.02 ms -> 9.74 ms +- 0.02 ms: 1.01x faster (-1%)
• python_startup: 16.2 ms +- 0.0 ms -> 16.1 ms +- 0.0 ms: 1.01x faster (-1%)
• logging_simple: 31.2 us +- 0.3 us -> 31.0 us +- 0.4 us: 1.01x faster (-1%)
• 2to3: 742 ms +- 4 ms -> 739 ms +- 4 ms: 1.00x faster (-0%)
• hexiom: 22.7 ms +- 0.2 ms -> 22.6 ms +- 0.2 ms: 1.00x faster (-0%)
• call_simple: 14.2 ms +- 0.5 ms -> 14.2 ms +- 0.2 ms: 1.00x faster (-0%)
• sympy_integrate: 46.2 ms +- 0.3 ms -> 46.1 ms +- 0.4 ms: 1.00x faster (-0%)
• regex_compile: 434 ms +- 4 ms -> 433 ms +- 4 ms: 1.00x faster (-0%)
• deltablue: 17.7 ms +- 0.2 ms -> 17.7 ms +- 0.2 ms: 1.00x faster (-0%)
• chaos: 299 ms +- 3 ms -> 299 ms +- 3 ms: 1.00x faster (-0%)
• call_method_slots: 14.6 ms +- 0.2 ms -> 14.6 ms +- 0.1 ms: 1.00x faster (-0%)
• regex_dna: 283 ms +- 3 ms -> 283 ms +- 2 ms: 1.00x faster (-0%)

Benchmark hidden because not significant (43)

I'm creating siphash13 from reference implementation to double check the output.

[methane]

PEP-456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4.

OK, I'll add siphash13, instead of replacing siphash24.

On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode?

siphash implementation uses 64bit unit.
I don't know how to implement partial update like: m.update(b'foo'); b.update(b'bar')

[tiran]

I added SipHash13 as additional hash algorithm in https://github.com/tiran/cpython/tree/siphash13 . Still need to verify the finalizer.

For hashlib I'd need to move to a different implementation of SipHash. The implementation in pyhash.c is optimized for speed and has a fixed key.

[malemburg]

On 01.02.2017 10:14, Christian Heimes wrote:

PEP-456 defines an API to add more hashing algorithms and make the selection of hash algorithm a compile time option. We can easily add SipHash-1-3 and make it the default algorithm. Vendors then can select between FNV2, SipHash-1-3 and SipHash-2-4.

+1 on adding the 1-3 and making it the default; the faster
the better. Hash speed for strings needs to be excellent in Python
due to the many dict lookups we use in the interpreter.

Reading up a bit on the Rust thread and looking at this benchmark
which is mentioned in the thread:

https://imgur.com/5dKecOW

it seems as if it would make sense to not use a fixed
hash algorithm for all strings lengths, but instead a
hybrid one to increase performance for short strings
(which are used a lot in Python).

Is there a good hash algorithm with provides better
performance for short strings than siphash ?

On another note should we add SipHash-2-4 and 1-3 PRF to the hashlib mode?

+1 as well.

[methane]

it seems as if it would make sense to not use a fixed
hash algorithm for all strings lengths, but instead a
hybrid one to increase performance for short strings
(which are used a lot in Python).

Is there a good hash algorithm with provides better
performance for short strings than siphash ?

There is undocumented option "Py_HASH_CUTOFF" to use DJBX33A for short string.

See https://github.com/python/cpython/blob/master/Include/pyhash.h#L98

[serhiy-storchaka]

The performance of hash algorithm shouldn't affect general benchmarks since hash value is cached inside string object. Almost all dict lookups in critical parts are lookups with interned strings. But in corner cases the difference can be measurable. We should look not on results of macrobenchmarks, but find worst cases.

There is also an alignment issue with the implementation of SipHash-2-4 (and I suppose with SipHash-1-3). See bpo-28055.

[malemburg]

On 01.02.2017 10:50, INADA Naoki wrote:

> it seems as if it would make sense to not use a fixed
> hash algorithm for all strings lengths, but instead a
> hybrid one to increase performance for short strings
> (which are used a lot in Python).
>
> Is there a good hash algorithm with provides better
> performance for short strings than siphash ?

There is undocumented option "Py_HASH_CUTOFF" to use DJBX33A for short string.

See https://github.com/python/cpython/blob/master/Include/pyhash.h#L98

Thanks. I found a reference in the PEP-456:

"""
...
However a fast function like DJBX33A is not as secure as SipHash24. A
cutoff at about 5 to 7 bytes should provide a decent safety margin and
speed up at the same time. The PEP's reference implementation provides
such a cutoff with Py_HASH_CUTOFF . The optimization is disabled by
default for several reasons. For one the security implications are
unclear yet and should be thoroughly studied before the optimization is
enabled by default. Secondly the performance benefits vary. On 64 bit
Linux system with Intel Core i7 multiple runs of Python's benchmark
suite [pybench] show an average speedups between 3% and 5% for
benchmarks such as django_v2, mako and etree with a cutoff of 7.
Benchmarks with X86 binaries and Windows X86_64 builds on the same
machine are a bit slower with small string optimization.

The state of small string optimization will be assessed during the beta
phase of Python 3.4. The feature will either be enabled with appropriate
values or the code will be removed before beta 2 is released.
"""

The mentioned speedup sounds like enabling this by default
would make a lot of sense (keeping the compile time option of
setting Py_HASH_CUTOFF to 0).

Aside: I haven't been following this since the days I proposed the
collision counting method as solution to the vulnerability, which was
rejected at the time. It's interesting how much effort went into
trying to fix the string hashing in dicts over the years. Yet the
much easier to use integer key hash collisions have still not
been addressed.