Ndevar logoNdevar

Security

Designed so we can't spy on you
even if we wanted to

Every security property is a technical consequence — not a promise, not a policy, not a terms-of-service commitment. The system is designed so the claims are enforced by mathematics, not by trust.

Principles

Four properties. All technical.

End-to-end encryption

Messages are encrypted on your device before they leave. Nobody — not Ndevar, not your internet provider, not the relay — can decrypt them. Only the intended recipient can.

Stealth addressing

Your identity is never exposed in transit. Each message uses a one-time token derived from your public key — the relay cannot link messages to identities.

Device-native identity

Your identity is an Ed25519 keypair generated on your device. It never leaves your device. No server stores it. No company controls it.

Zero message storage

Messages are never written to disk on any server. The relay holds an encrypted envelope only long enough to deliver it, then discards it. There's nothing to subpoena.

What Ndevar's relay can and cannot see

The relay routes messages to the right device — which means it knows which device should receive each message. It also sees connection metadata: IP address, connection frequency, and push notification tokens.

What it cannot see: message content (end-to-end encrypted), who sent each message (sealed sender), or who read each message (sealed receipt).

Users who want zero relay visibility can use Bluetooth-only mode, which sends no data to any Ndevar server.

Known limitations

What we don't claim to do

We believe in being honest about what the system can and cannot protect against.

No forward secrecy

Accepted tradeoff

Key compromise reveals past messages. We've accepted this tradeoff to enable offline messaging and key recovery. Future protocol versions may address this.

Frame metadata visible on Bluetooth

Low impact

Nearby devices can observe Bluetooth advertisement frames — not content, but the fact that Ndevar is running. This is a property of Bluetooth, not a cryptographic weakness.

Group messages use shared key

Expected behaviour

Group encryption uses a shared group key rather than pairwise keys. This means a compromised group member can read group messages.

No identity verification UI

Low impact

There's no in-app mechanism to verify that a shortAddress belongs to the person you think it does. Key verification via out-of-band channels (in person, QR code) is supported but not enforced.

For the technically curious

Everything below is for security researchers, developers, and anyone who wants to verify our claims rather than take them on trust. The algorithms we use are open standards — nothing here is secret.

Cryptography stack

The cryptography stack

X25519 ECDH
Key agreement — per-message ephemeral keypair
HKDF-SHA256
Key derivation — separate keys for encryption and stealth token
AES-256-GCM
Payload encryption — authenticated encryption, tamper-evident
Ed25519
Message signing — unsigned messages rejected at door
BIP39
Recovery key — account holders only, never transmitted

Stealth addressing

The relay never reads your messages

Without stealth addressing
  • Sender identity visible in every message
  • Recipient identity visible in every message
  • Server knows exactly who talks to whom
  • Contact graphs are readable by the operator
With Ndevar stealth addressing
  • Sender address zeroed in every envelope
  • One-time token per message — never reused
  • Relay sees only encrypted envelope payloads
  • Message content and sender identity invisible to relay

HKDF token derivation — how it works

1
You generate a one-time X25519 keypair for each message
2
You derive a shared secret using the recipient's public key and your ephemeral private key
3
You run HKDF-SHA256 on the shared secret to derive the delivery token
4
Only the recipient — with their private key — can derive the same token and claim the message

Identity

Identity & key storage

AddressID

Permanent

Your permanent device identity. An Ed25519 keypair generated locally, never transmitted. Never appears in relay logs.

ShortAddress

Permanent

The human-readable 8-character representation of your AddressID. Used in QR codes and contact sharing.

Transport ID

~15 min

An ephemeral identity used for Bluetooth transport only. Rotates approximately every 15 minutes. Never linked to your AddressID in transit.

Security you can actually verify.

The security properties described here are technical constraints, not policies.