AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 17 Bitcoin

Add the SHA3-256 hash function

Public commit record

What the developer wrote

Authored by rustaceanrob

76/100 · Adequate
Add the SHA3-256 hash function

There is a substantial amount of bitcoin listening nodes only reachable
by Tor. This is backed by some relatively old research, but I would
imagine this remains the case today. When it comes to peer-to-peer
gossip, Tor nodes are reachable by a 32-byte ed25519 public key. In
practice, most applications will run a Tor daemon, and other
applications will communicate with Tor via a Socks5 proxy. With Socks5,
you may connect to an IPv4, IPv6, or domain.

The problem is to go from Tor public key to onion address (domain), you
must take a Sha3-256 hash of a public key and some concatinated data. In
effect this makes Tor nodes unreachable for those that do not want to
use `RustCrypto` or god forbid the Arti project.

Here I propose we add this hash to `bitcoin_hashes`. While it is not
explicitly a hash used in bitcoin, many bitcoin nodes use Tor, and more
importantly, accept inbound connections using Tor. Others are of course
free to use this hash however their heart desires.

As far as implementation, from a high level, the hash is a number of
permutation operations on a state array of 1600 bits. These bits can be
visualized/represented as a 5x5 matrix of 64-bit "lanes." I will leave
the rest to the code comment in the file. The Keccak team designed this
function to be robust theoretically but easy to implement. Each of these
lanes may be mutated directly, and I also try to abuse `for_each` to
give SIMD hints. To review the implementation, you may follow the
psuedo-code provided by the Keccak team, linked below.

ref
Psuedo-code: https://keccak.team/keccak_specs_summary.html
Full Keccak reference: https://keccak.team/files/Keccak-reference-3.0.pdf
Tor spec: https://spec.torproject.org/rend-spec/encoding-onion-addresses.html
Tor post: https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-dev/2017-January/011816.html
P2P data: https://github.com/virtu/p2p-metrics
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds a new SHA3-256 hashing implementation to the rust-bitcoin library's bitcoin_hashes crate. It is a feature addition intended to support computing Tor onion addresses from ed25519 public keys, not a fix for any known security issue. There is no evidence in the commit or supplied references that this change addresses a vulnerability or introduces one.

Recommended action

No security action required. Treat as routine feature review: verify test vectors against NIST CAVP or other authoritative SHA3-256 test vectors, and consider an independent audit of the new cryptographic implementation before relying on it for production Tor address derivation.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 17/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 5/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.