A plain-English explanation of the cryptography behind Asterias — how your messages stay private, how your funds stay safe, and why no single party can read your conversations or take your money.
The short version: your keys never leave your device. Messages are encrypted before they reach our servers. Funds go into escrow that we cannot unilaterally access.
When you open Asterias for the first time, the app generates a cryptographic keypair directly on your device. Your identity is the public key — not an email address, not a username, not a phone number.
Your User ID (visible in Settings) is a short hash of that public key. Share it with someone and they can add you as a contact. Nobody at Asterias registered you, and nobody can reset or revoke your identity.
Backup matters: if you lose your device without a backup, there is no recovery. Settings → Backup Key is the only copy that exists.
Asterias uses the same protocol as Signal — with quantum resistance layered on top.
Before the first message, both devices perform a key agreement using PQXDH (Post-Quantum Extended Diffie-Hellman) — a hybrid of classical X25519 and post-quantum Kyber768. Both sides independently compute a shared secret. It is never transmitted, so an eavesdropper who intercepts the handshake cannot derive it.
Every message derives its own unique key using the Double Ratchet algorithm. Each key is discarded after use. If an attacker ever compromised one key, they could not decrypt any other messages — past or future. This property is called forward secrecy.
Our relay routes encrypted ciphertext between devices. It sees who is communicating with whom and when, but never the content. The relay has no decryption keys.
Classical algorithms like X25519 and RSA are breakable by a quantum computer running Shor's algorithm. While no such machine exists today, adversaries can intercept encrypted traffic now and decrypt it later — the "harvest now, decrypt later" threat.
Asterias defends against this by layering Kyber768 (standardized as ML-KEM by NIST in 2024) on top of classical X25519. An attacker must break both simultaneously. Kyber is based on lattice problems, which have no known quantum algorithm.
Your Monero spend key and view key are derived from your identity keypair — one backup covers everything. Asterias never holds your funds.
All bets are denominated internally in piconero (1 XMR = 10¹² piconero) to avoid rounding errors. Your view key — which can see incoming transactions but cannot spend — is shared with our Light Wallet Server for balance scanning. Your spend key never leaves your device.
You bet directly against another person. Asterias is never the counterparty and cannot manipulate outcomes.
The oracle watches real-world event outcomes and publishes Ed25519-signed attestations. Its public key is fixed and public — anyone can verify its signatures independently.
The oracle can only trigger a settlement when three conditions are met: a valid signed result, the winner's co-signature, and confirmed escrow funds. It cannot fabricate results, move funds without a winner signature, or block a mutual refund between the two parties.
What we can see: metadata (who communicates with whom and when), public bet amounts and outcomes, your view key for balance scanning.
What we cannot see: message content (encrypted end-to-end), your spend key (never transmitted), your real-world identity (never collected).
Monero adds a further layer — on-chain, all transaction amounts and addresses are private by default. Your XMR activity is not publicly visible on the blockchain.
| Algorithm | Standard | Purpose |
|---|---|---|
Kyber768 ML-KEM | NIST FIPS 203 | Post-quantum key encapsulation |
Dilithium3 ML-DSA | NIST FIPS 204 | Post-quantum digital signatures |
| X25519 | RFC 7748 | Classical DH in PQXDH hybrid |
| Ed25519 | RFC 8032 | Identity signing, oracle attestations |
| AES-256-CBC | NIST FIPS 197 | Message encryption (Double Ratchet) |
| HMAC-SHA256 | RFC 2104 | Message authentication |
| HKDF-SHA256 | RFC 5869 | Key derivation |
| Keccak-256 | SHA-3 | Monero address derivation |
| TLS 1.3 | RFC 8446 | Transport encryption to servers |