Back to Newsroom
Threat Intel

GoBalance Signing Bug Lets Attackers Recover Tor .onion Master Keys

A truncated Ed25519 key in GoBalance leaks an onion site's long-term private key from one public descriptor, enabling permanent .onion address hijacks. Dread and Omega are among the services hit.

GoBalance Signing Bug Lets Attackers Recover Tor .onion Master Keys

GoBalance Signing Bug Lets Attackers Recover Tor .onion Master Keys

A flaw in GoBalance, a load-balancing tool widely used by dark-web services, can leak an onion site's long-term private key from public data alone. Whoever recovers that key can take over the site's .onion address. The incident is a clear reminder that a small mistake in cryptographic code can have permanent consequences.

What happened

GoBalance is a Go rewrite of Tor's Onionbalance. It spreads a hidden service across several backend servers so the service stays reachable under denial-of-service pressure, and it ships with the EndGame anti-DDoS toolkit. Researchers at Searchlight Cyber found that GoBalance mishandles the site's signing key when it publishes the service's descriptor, the signed record that Tor clients fetch to reach an onion address.

Tor stores an onion service's Ed25519 private key in an expanded 64-byte form. The first half is the secret signing scalar. The second half is the secret input used to derive each signature's one-time nonce. GoBalance passed only the first 32 bytes to the signer and threw away the rest. Without that second half, the nonce stops being secret and anyone can compute it. A single published descriptor then holds enough information to solve for the private key.

Because this is the site's master key, a recovered key doesn't just impersonate the site for a moment. It can sign valid descriptors long into the future, which amounts to a permanent hijack of the address.

Who is affected

  • GoBalance only. According to the researchers, the original Onionbalance and Tor itself are not affected.
  • Only some key formats. The flaw applies when the master key is stored in Tor's own key format. Keys created with GoBalance's setup tool use a format that isn't exposed.
  • Real-world takeovers. Between 5 and 7 October, both .onion addresses of the Dread forum were hijacked and redirected to a rival site. Dread's administrators first blamed operator error, then attributed the takeover to the GoBalance flaw. They said other hidden services may be affected and that their servers were not breached. The Omega market also said it took its addresses offline because of the bug. How many other services were hit is still unclear.

Status of a fix

As of 9 October there was no CVE and no official advisory from the Tor Project or the GoBalance maintainer. Dread said it plans to release a patched build. An independent researcher has published a patch along with a working proof of concept that recovers a master key from one public descriptor, tested only on keys generated for that purpose. Neither is an official release, so review any third-party patch before you trust it.

Why it matters

This is a textbook case of how fragile signature schemes are when they are implemented by hand. Ed25519 is safe by design, but only when the whole expanded key reaches the signing routine. Truncating it quietly breaks the guarantee, and nothing visibly fails until the key is gone. The same kind of bug can appear in any custom wrapper around signing keys, whether that's HSM glue code, key-format converters, or in-house tooling, well beyond the dark web.

What to do

  1. If you ran an affected GoBalance build, treat the key as compromised. A patch can't take back descriptors that were already published. Generate a new onion address and migrate to it.
  2. Announce the new address through a channel users can verify, such as a message signed with a key they already trust, and tell users to stop using the old address.
  3. Users of affected services should change passwords that were used there and on any other site where they were reused. They should accept a new address only when it comes with a signed announcement.
  4. Audit your own signing code. Check that wrappers and converters pass the complete private key (including Ed25519's 64-byte expanded form) to vetted libraries. Prefer standard library APIs over hand-built signing paths.
  5. Add negative tests. Signatures over different messages should never reuse a nonce, and a known-answer test against reference vectors catches truncation early.

Source: original research by Searchlight Cyber, as reported by The Hacker News.

SHARE