NYXPEER Use invite
SECURITY / IMPLEMENTATION NOTES

Trust less.
Verify more.

Concrete controls. Explicit limits. No “military-grade” marketing.

DOCUMENTSECURITY MODEL UPDATED2026-09-22 STATUSPRE-AUDIT
DEVICE AED25519 SIGNECIES ENCRYPTTLS TRANSPORTRAM QUEUE ≤ 5 MINDEVICE B

Current security posture

NyxPeer protects message content from relay nodes and network observers. Devices create identities, sign application envelopes, encrypt for recipient device keys, and decrypt locally. Nodes route opaque payloads. They cannot read chats, files, contact names, group names, or call signaling.

NyxPeer has not completed an independent cryptographic audit. Current messaging does not yet provide Signal-style forward secrecy or post-compromise security. Those limits matter and remain stated here.

01

Threat model

Designed to resist: passive network interception, curious relay operators, stolen server disks, forged application envelopes, relay replay attempts at application layer, copied app files without original Android Keystore keys, and opportunistic access to a locked app.

Not designed to defeat: an unlocked compromised phone, malicious accessibility services, OS or baseband compromise, a malicious recipient, screenshots or exports, traffic-analysis adversaries, coerced key disclosure, or endpoint malware recording content before encryption or after decryption.

Boundary: end-to-end encryption protects content in transit. Endpoint security still decides whether plaintext stays private.
02

Cryptography

Identity and envelopesEd25519 signatures. Contact cards and application envelopes are signed.
Route ownershiproute = base64url(SHA-256(Ed25519 public key)). Node challenges each connection; device proves route-key possession.
Message encryptionGoogle Tink ECIES using P-256 recipient keys. Payload encrypted before node transport.
TransportTLS WebSocket between app and node. TLS protects routing metadata on local network path; E2EE separately protects payload content.
Local databaseSQLCipher. Random database key wrapped by non-exportable Android Keystore AES-GCM key.
App PINPBKDF2-HMAC-SHA-256, random 128-bit salt, 310,000 iterations, exponential delay after failed attempts.

Signed envelopes bind event type, sender route, event identifier, timestamp, and encrypted content. Receivers reject invalid signatures and duplicate message identifiers.

03

Relay-node design

Nodes receive anonymous route identifiers and already-encrypted payloads. Offline payloads use bounded RAM queues with five-minute expiry. Queue state is not written to disk. Process restart erases it.

Route announcement requires an Ed25519 challenge signature. Rate limits, payload limits, connection limits, queue bounds, and expiry reduce abuse and memory-exhaustion risk.

Presence is opt-in. Nodes expose only current live state for users who enable sharing. No last-seen timestamp or presence-history database exists. Last-seen values displayed by app are observations stored on viewer device.

04

Device and local data

  • Private identity material and database wrapping keys stay behind Android Keystore.
  • Chat history remains in encrypted SQLCipher database.
  • Android backup and device-transfer extraction are disabled.
  • Optional PIN and strong-biometric unlock protect app UI.
  • Secure-screen mode blocks screenshots and recent-app previews.
  • Duress PIN deletes Keystore aliases, encrypted database, identities, preferences, files, and cache; Android then controls uninstall confirmation.

Hardware-backed storage depends on device capabilities. Android Keystore can be software-backed on older or low-end hardware.

05

Voice and video calls

Offer, answer, ICE, and hangup events travel inside signed end-to-end encrypted envelopes. WebRTC media uses DTLS-SRTP. TURN fallback relays encrypted SRTP packets and receives short-lived HMAC credentials only after signed route announcement.

Direct WebRTC can reveal peer IP addresses. TURN hides peer IP only when relay candidates are selected. Tor mode disables calls because real-time media does not inherit tracker SOCKS routing.

06

Background delivery

Firebase Cloud Messaging carries an opaque wake event only. It contains no message content, ciphertext, NyxPeer route, sender, contact, group, or call details. App wakes, fetches ciphertext from node, and decrypts locally.

Google can still observe installation identity, push timing, IP/network metadata, and ordinary FCM device metadata. Tor mode unregisters FCM because Google push traffic does not pass through NyxPeer Orbot routing.

07

Release and update chain

Release APKs are signed with stable Android signing identity. Update metadata includes version, SHA-256 digest, minimum SDK, and expected certificate digest. App verifies downloaded APK hash, package identity, signing certificate, and version before requesting Android installation.

Android remains final installation authority. NyxPeer cannot silently bypass unknown-app permission or package-installer confirmation.

08

Metadata exposure

Encryption does not erase network metadata. Node can observe source IP, connection timing, anonymous source and target routes, payload size, delivery result, queue expiry, and TURN use. TURN can observe endpoint IPs and encrypted media flow timing. FCM sees wake-delivery metadata described above.

Release app avoids logging bodies, keys, contact cards, routes, and encrypted envelope content. No analytics or advertising SDK is included. Infrastructure still needs narrow operational telemetry for rate limits, service health, and abuse response.

09

Known limitations

Not yet implemented
  • Signal Double Ratchet or equivalent forward secrecy and post-compromise security.
  • MLS or another formally reviewed group-key protocol.
  • Production TLS SPKI pinning and signed node-identity manifest.
  • Independent source review, penetration test, and cryptographic audit.

Current ECIES device-key model authenticates endpoints and hides content from nodes. Device-key compromise can affect captured historical ciphertext. Do not treat current release as offering Signal-equivalent compromise recovery.

10

Hardening roadmap

  1. Signed node manifest, offline authority root, rotating node keys, and current/next TLS SPKI pins.
  2. Safety-number verification UI, QR comparison, and blocking identity-change warnings.
  3. Envelope replay windows, bounded replay cache, and stricter protocol fuzz testing.
  4. Double Ratchet-style direct sessions; MLS evaluation for groups.
  5. Device list, device revocation, key rotation, reproducible build work, external audit.

Security-critical validation will fail closed. Node verification, signature checks, TLS validation, and cryptographic algorithms will not become “disable protection” toggles.

Responsible disclosure: [email protected]. Never send private keys, seed phrases, passwords, or live user data.