NoshiTalk

Key exchange

On joining a session, the browser generates an ephemeral X25519 keypair. The public key is exchanged with other participants through the server. Each peer independently derives a shared secret via ECDH — the server only ever sees the public halves.

Message encryption

Messages are encrypted with AES-GCM-256 using the derived shared secret. Each message carries its own random nonce. The server receives and forwards the ciphertext blob; it has no access to the key material needed to decrypt it.

Perfect forward secrecy

Keypairs are ephemeral and session-scoped. When a session ends, the keys are discarded. Compromising the server at any point — past or future — yields only ciphertext with no recoverable key. Prior sessions are not retroactively exposed.

Memory protection

The Go server uses memguard for any transient sensitive material, ensuring that key fragments are not left in heap memory after use. On disconnection, all session data is purged immediately.

The data flow is deliberately minimal:

Browser A (Web Crypto API)
    |
    |  SSE stream (encrypted blobs only)
    |  HTTP POST /send (ciphertext)
    |
Go Server — blind relay, zero logging
    |
    |  SSE stream (same blobs forwarded)
    |
Browser B (Web Crypto API)

No accounts, no persistent identities, no message storage. The server exposes a small set of endpoints:

• POST /join — enter a session
• POST /leave — exit cleanly, triggers server-side purge
• GET /events — SSE stream of incoming blobs
• POST /send — submit an encrypted message
• GET /key-exchange / POST /key-exchange — public key distribution
• GET /health — liveness probe

NoshiTalk is designed to run behind a Tor v3 onion address. When accessed over Tor, the transport layer is handled entirely by the onion routing — no TLS certificate is required on the server side, and neither party reveals their IP address to the other or to the server.

The combination of onion routing (network anonymity) and end-to-end encryption (content confidentiality) means that a passive observer on the network sees only Tor traffic; the relay server sees only ciphertext; and no central party can correlate sender and receiver.

Clearnet deployment with TLS 1.3 is also supported for contexts where Tor is unavailable, but the onion service is the recommended access method for sensitive use.

NoshiTalk uses JavaScript — specifically the Web Crypto API, a native browser primitive built into every modern browser. No external cryptography library is loaded from any CDN or third-party server. JavaScript must be enabled for the application to function: all encryption, decryption, and key generation happen client-side in your browser. The server never executes or sees your JS — it only forwards ciphertext blobs.

Minimum versions with full X25519 support:

• Chrome / Chromium 113+
• Firefox 72+
• Tor Browser (based on Firefox ESR — check version)

For maximum privacy, access via Tor Browser over the onion address.

NoshiTalk is a single Go binary. Build requirements: Go 1.21+.

git clone https://github.com/Virebent-do-ART/Noshitalk
cd Noshitalk
go mod tidy
CGO_ENABLED=0 go build -ldflags="-s -w" -o noshitalk main.go

Run on a dedicated non-privileged system user. The binary reads one environment variable:

NOSHITALK_PORT=8080 ./noshitalk

Place it behind a reverse proxy (nginx, Caddy, Apache) with TLS 1.3, or expose it directly as a Tor hidden service without a proxy. SSE requires that proxy buffering is disabled on the upstream path.