GhostWire Is In Early Access — Here's the Vendor Checklist It Forced Us to Write

Every SME sends something over ordinary chat and email that would hurt if it leaked — a client list, a pricing sheet, a funding term sheet, a compliance disclosure. Most of the tools carrying that traffic are built so the vendor could read it if they chose to, if they were compromised, or if they were served a warrant. We've just put our own alternative, GhostWire, into early access — and writing about it honestly forced us to answer a harder question than "is it secure?": what would we need to prove before any SME owner should trust a vendor's security claims, including ours?

Why this matters even if you never touch GhostWire

You don't need to be evaluating our product for this to be useful. Every vendor pitching you "secure", "encrypted" or "private" messaging is making a claim you probably can't verify from the sales page. The questions further down are the ones we had to be able to answer about our own system before we let a single outside organisation near it. Ask them of anyone else too.

What "early access" actually means — no marketing gloss

For GhostWire, early access is not a beta badge. It's a specific, limited arrangement:

• Participating organisations run GhostWire in their own environment, using keys they generate and control themselves — we never hold them.
• We give no guarantee on uptime, latency or throughput at this stage.
• Every piece of feedback is logged and fed into the development backlog.
• The protocol, data formats and API endpoints can still change as we learn what breaks in real use.

In other words: functional enough to relay real messages, still young enough that we won't dress it up as finished.

How it's actually built

Three design choices carry the real weight:

• Zero-knowledge store-and-forward — relay nodes never see plaintext. Messages are encrypted with a session key derived from sender and recipient long-term keys; the relay only ever forwards encrypted blobs.
• HMAC-signed delivery — each message carries an HMAC that only the sender and intended recipient can compute, so the recipient can verify authenticity without the relay ever holding that key.
• Org-owned keys — all asymmetric keys are generated and stored inside the participating organisation's own infrastructure. We never store or transmit private keys.

The cryptography underneath is X25519 for key exchange, AES-256-GCM for payload encryption, and HMAC-SHA-256 for integrity — standard, constant-time-library implementations that our engineering team has reviewed internally. If a relay node is compromised, an attacker gets ciphertext and HMAC tags that are useless without the session keys. There is no central point that can decrypt or forge a message.

What we are deliberately not claiming

This is the part most vendors skip, and it's exactly where you should be most suspicious of anyone who doesn't skip it. We will not tell you GhostWire is immune to all network-level attacks, that it guarantees sub-millisecond latency under any load, that it has already prevented some number of breaches, or that the protocol is formally verified. We haven't run the third-party audits, formal verification or large-scale load testing that would justify any of that claim — so we're not making it, even though it would read better on a sales page.

The six questions to ask any "secure comms" vendor — including us

This is the checklist we hold ourselves to. Use it on your current provider today:

• What's the threat model, and does it match the risk you're actually worried about?
• Can you see the source code, or get a binary-reproducibility audit, and are the crypto libraries reputable and current?
• Who actually controls the keys? If the vendor holds any private key material, your confidentiality depends on their security, not yours.
• Is there any independent review — third-party penetration tests, cryptographic assessments, formal verification?
• How are patches delivered, and can you verify their integrity before you apply them?
• What guarantees, if any, exist for availability, latency or message ordering — and what happens when they're not met?

If a vendor can't answer most of these in plain language, that's your answer.

Where this leaves you

Our hardening process while we're in this phase includes nightly automated static analysis and fuzzing, monthly internal penetration tests against the network stack and key-handling logic, and a review of every configuration change with the organisations already running it. None of that makes GhostWire finished. It makes it honestly described — which is the standard we're asking you to hold every vendor to, starting with your current one.

One thing to do next

If you want to see how a zero-knowledge design actually behaves under real use rather than on a spec sheet, get in touch about joining the GhostWire early-access cohort via our products page — a short scoping call is all it takes to find out if it's a fit.