A proposal on the Erlang forums argues for replacing MD5 with a modern non-cryptographic hash like XXH3-128 for BEAM module checksums, citing benchmarks on OTP 29.0.5 showing checksum time dropping from 19.5ms to 0.3ms when loading 168 stdlib modules, a meaningful chunk of VM boot time for short-lived processes. The proposal outlines deprecating the md5 field in module_info/1, adding a new checksum field returning an algorithm/digest tuple, and eventually returning undefined for md5. It also raises open questions about migrating MD5 usage in ETF's NEW_FUN_EXT Uniq field, including distribution protocol negotiation between nodes during a transition period.
Questions this post answers
How much faster is XXH3-128 than MD5 for hashing Erlang BEAM module checksums?
XXH3-128 reduced checksum calculation time from about 19.563ms to 0.327ms when loading 168 stdlib modules on OTP 29.0.5 (Linux/aarch64, one scheduler), a roughly 60x speedup. This cut the MD5 checksum share of VM boot time from 11.17% to 0.20%, saving about 13-19ms of boot time depending on the machine, which matters for short-lived VM instances like browser-compiled BEAM. Anyone optimizing Erlang VM boot times can track proposals like this hashing change on daily.dev.
What changes are being proposed to remove MD5 as the Erlang BEAM module checksum algorithm?
The proposal suggests deprecating the md5 field in module_info/1, adding a new beam_lib:checksum/1 function and checksum field returning an {algorithm, digest} tuple, and eventually returning undefined for the md5 field after a deprecation period. It also flags open questions about migrating MD5 usage in ETF's NEW_FUN_EXT Uniq field, which would require distribution nodes to negotiate hash algorithms during a transition period. Erlang maintainers weighing this checksum migration can follow the discussion's progress on daily.dev.