ZEQAT Documentation

01 Overview

ZEQAT is a privacy-first communication platform built around three core ideas: no personal identifiers, silent deniable authentication, and user-controlled destruction of data. This document explains how each layer actually works — the cryptography, the login flows, the wipe semantics, and the boundaries of what ZEQAT can and cannot protect you from.

Join the ZEQAT Community

Help us keep privacy tools transparent, auditable, and in the hands of the people who need them.

Download APK

ZEQAT

ZEQAT

01 Architecture

ZEQAT runs on a hardened PHP + MySQL core with a browser-side cryptography layer. There is no framework, no build step for the site itself, and no third-party identity provider. The only external service used at login time is OneSignal for push notifications.

• Server: PHP 8+ with PDO and ATTR_EMULATE_PREPARES = false — every query is a real server-side prepared statement
• Database: MySQL / InnoDB. Passwords and PINs are stored as bcrypt hashes via password_hash()
• Client crypto: X25519 key exchange + AES-GCM for message encryption (see e2ee.js). Keys are generated in the browser and never transmitted.
• Vault crypto: AES-256-CBC via OpenSSL for file encryption (see Section 10)
• Push notifications: OneSignal (device tokens only — no message content)
• Frontend: Vanilla JavaScript + CSS. font-awesome, Orbitron, and qrcodejs / jsQR are loaded from CDNs.

02 ZQID & Identity

Your ZQID is a 7-digit number that identifies you on ZEQAT. Your ZQ-Username is a handle you choose. Together they replace phone numbers, email addresses, and real names entirely.

• ZQID: System-generated 7-digit number — used in account recovery
• ZQ-Username: Chosen by you. 3–50 chars, a-zA-Z0-9_- only
• No phone number. Never requested, never stored
• No email. Never requested, never stored
• No real name. The registration form has no name field

03 Authentication

ZEQAT supports three distinct sign-in methods. All three converge on the same hardened session once you're in, but they take different paths to get there.

• Password login — username + password. If you already have an active session elsewhere, your existing device gets an approval prompt: accept or deny.
• PIN login — only on trusted devices. One 6-digit pad. Two possible PINs (see Section 4).
• QR handoff — scan a QR from an already-signed-in phone to move your session to a new device.

Brute-force is throttled at multiple layers: per-IP, per-username, per-PIN attempt, and per-reset-flow. Failed attempts also trigger a sliding CAPTCHA on the password form after 2 failures from the same IP.

04 Silent Dual-PIN

This is ZEQAT's signature feature. On a trusted device, the login screen presents a single 6-digit pad. You can enter either of two different PINs:

• Regular PIN — signs you in normally. Nothing else happens.
• Destruction PIN — signs you in and triggers any armed destruction actions before the dashboard loads.

The UI never reveals which PIN was typed. The dot animation, the spinner, the redirect — every visible cue is identical in both cases. Someone looking over your shoulder cannot tell which path you took.

• Both PINs are bcrypt-hashed with password_hash() — neither is ever stored in plaintext
• Rate limited: 5 wrong attempts per user / 15 attempts per IP per 15 minutes. Too many failures revoke the trusted device entirely.
• Device-bound: PIN login only works from a device already listed in your trusted devices table. A stolen PIN is useless without the device.

05 Armed Destruction

Destruction in ZEQAT is opt-in, pre-armed, one-shot, and irreversible. In the Security panel you can arm any combination of four actions. On your next destruction-PIN login, every armed action fires before your dashboard loads, then auto-disarms.

• Message Delete — deletes every direct message where you are sender OR receiver (both directions). Does not touch group or room messages.
• Group Cleanup — for each group you are in: if you own it, the entire group is deleted for all members; if you're a member, you leave and your messages are removed.
• Room Cleanup — same semantics as Group Cleanup, applied to rooms.
• Storage Delete — deletes every file in your storage. Diamond subscription required.

• Arming requires the destruction PIN. Disarming requires nothing — you can always turn an arm off from the Security page without needing the PIN.
• Auto-disarm: after a wipe runs, every armed flag is set back to 0. A second destruction login does nothing until you re-arm.
• Logged: every wipe is recorded in zeqat_destruction_log with scope, count, IP, and user agent.

06 Messaging & Calls

Messages are encrypted with X25519 + AES-GCM before they leave your device. Your private key is generated in your browser and never sent anywhere. The server stores ciphertext it cannot decrypt.

• E2EE: Message bodies encrypted client-side. Ciphertext only on the server.
• Key management: Public key published to keys.php. Private key held in local storage on your device.
• Voice & video calls: Supported. Caller/receiver IDs and timing metadata are visible to the server; call content is not relayed through us.
• Auto-delete: Optional 1-day or 10-day auto-delete of read messages (Settings).
• Room chat: Group and room messages are stored under a shared group_id and subject to the same destruction rules as above.

07 QR Login Handoff

On a new device, ZEQAT shows a QR code. Scanning it from a phone that is already signed in transfers your session to the new device and simultaneously signs the old one out.

• Generate: The new device requests a QR token (64-hex-char, valid for 90 seconds)
• Scan: The signed-in phone opens the QR scanner and reads the token
• Confirm: The phone shows a "Transfer login?" prompt. Confirming sends the approval.
• Transfer: On approval, the new device gets a session. The old phone is signed out.

08 Trusted Devices

Trusted devices are what make PIN login work. When you first sign in with a password on a new device, you can mark it as trusted by setting a PIN. That device then receives a trusted token (30-day cookie) that lets it skip the password prompt on subsequent logins.

• Two separate cookies: zeqat_device_token (fingerprint) and zeqat_trusted_token (login trust). They serve different purposes.
• Deduplication: Setting a PIN multiple times from the same device reuses the existing row instead of creating duplicates.
• Revocation: You can revoke any trusted device from the Security panel. Revoking clears the token cookie on the current device only if it matches.
• Device Lock (optional): You can additionally bind your account to a single device fingerprint. When enabled, login is rejected from any other device — even with the correct password.

09 Account Locking

There are three distinct "lock" concepts in ZEQAT. They are easy to confuse, so this section defines each one.

• Brute-force lock (automatic): After 5 wrong password attempts, the account is locked for 5 minutes. Enforced server-side.
• Manual lock (30 min): You can lock your own account from Settings. Useful if you're about to be separated from your device. While locked, no login will succeed until the timer expires.
• Device Lock (optional): A persistent setting that binds login to a single device fingerprint. Different from the two above — this is a state, not a timer.

10 Lock & Unlock Files

ZEQAT has a dedicated two-folder system for encrypted files: Lock (encrypt & download) and Unlock (decrypt & restore). Anything you Lock can only be opened again through Unlock with the exact password you chose. The original file never leaves your device unencrypted — you get an encrypted .zip you can store anywhere.

• Format: ZQENCv2 container — magic header + IV + encrypted payload
• Encryption: AES-256-CBC via OpenSSL with a key derived from your password
• Filename recovery: Original name is embedded inside the encrypted payload, restored on decrypt
• Backwards compatible: Older ZQENCv1 and magic-less files still decrypt
• Auto-delete: Both the encrypted upload and decrypted temp file are removed after 1 day
• Manual delete: You can delete any file from either folder at any time
• Storage counting: Every locked or uploaded file counts against your plan's storage, visible live in the folder header

11 Groups & Rooms

Groups and Rooms are multi-user spaces. Groups are general-purpose; Rooms are a Diamond-tier feature. Both support chat, file sharing, and calls, and both are subject to the same destruction rules described in Section 5.

• Membership: Every member has an is_active flag. Leaving sets it to 0 without deleting the row.
• Ownership: Each group or room has an owner. Owners can delete the entire space; members can only leave it.
• Destruction semantics: Owner-delete wipes all messages, members, and the group/room record. Member-leave wipes only that member's messages.
• Encryption: Message bodies are encrypted the same way as DMs — X25519 + AES-GCM.

12 Account Recovery

If you forget your password, ZEQAT can reset it — but only if you can prove you are the account owner. There is no email reset link and no support ticket that bypasses this.

• Step 1: Enter your username or ZQ-Username
• Step 2: Enter your 7-digit ZQID
• Step 3: Enter your 24-word recovery phrase exactly as you saved it
• Step 4: Choose a new password. You are signed in automatically.

• Rate limited: Step 1 is 5 attempts / 15 min per IP. Steps 2 and 3 are 5 attempts / 15 min per user. Step 4 is 3 submissions / 15 min per IP.
• Session timeout: The whole reset flow expires 15 minutes after Step 1.
• No enumeration: Step 1 returns a generic error whether the username exists or not.
• Post-reset cleanup: All trusted devices are revoked, and the account lock (if any) is cleared.

13 Privacy Model

ZEQAT follows a data minimization principle: we collect only what is required for the service to function, and we never sell or share it.

• What we store: ZQ-Username, ZQID, bcrypt password hash, bcrypt PIN hashes, avatar (optional), encrypted message bodies, encrypted file blobs, device fingerprints, session tokens
• What we never store: phone number, email, real name, location, contacts, plaintext message content, plaintext files
• What we never sell: anything. There is no advertising, no analytics, no profiling.
• What we cannot read: E2EE message bodies, Lock folder contents, your private key
• What we CAN see: message metadata (sender, receiver, time, size), device fingerprints, IP addresses, connection patterns — because the server has to route traffic

14 Security Model

ZEQAT is defended by multiple independent layers. Compromising any single layer does not compromise the account.

• Encryption layer: X25519 + AES-GCM for messages. AES-256-CBC for the file vault. bcrypt for every password and PIN.
• Authentication layer: Password + optional PIN + optional device binding + optional destruction PIN. Multiple independent secrets.
• Database layer: Server-side prepared statements (ATTR_EMULATE_PREPARES = false). No dynamic SQL concatenation.
• Network layer: Cloudflare in front. Strict Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin.
• Session layer: HttpOnly + Secure + SameSite=Lax cookies. Session ID regenerated on login. CSRF token on every state-changing request.

15 Threat Model

What ZEQAT defends against, and what it does not.

• Defends against: Server breach (messages are ciphertext), password database leak (bcrypt), stolen PIN (device binding required), network eavesdropping (TLS + E2EE), brute-force login (multi-layer rate limits), session hijacking (HttpOnly + SameSite + rotate on login), CSRF (per-session token), SQL injection (prepared statements)
• Does not defend against: A compromised endpoint (malware on your device sees plaintext before encryption), a coerced password disclosure (this is exactly what the destruction PIN is for), traffic analysis (metadata is visible), a malicious or compromised server admin, someone who already has your 24-word phrase
• Silent dual-PIN is a coercion mitigation, not a coercion proof. If you are compelled to unlock your phone by someone who knows ZEQAT has destruction PINs, they can demand you use the "real" PIN. The feature relies on your attacker not knowing it exists.

16 Data Handling

A plain-language summary of what happens to your data at each stage.

• At rest: Passwords and PINs are bcrypt hashes. Message bodies are AES-GCM ciphertext. File vault blobs are AES-256-CBC ciphertext. Everything else (usernames, IDs, timestamps) is plain.
• In transit: TLS terminated by Cloudflare. ZEQAT's origin is behind Cloudflare.
• Retention: Data lives as long as your account does. Delete your account and the corresponding rows and files are removed.
• Deletion: Settings → Account → Delete Account performs a hard delete of your user row, your files, and your avatar.
• Backups: We cannot guarantee that backups made before deletion are purged. Deletion removes data from the live system.

17 Known Limitations

ZEQAT is actively developed. These are the current limits we're aware of and working on.

• iOS: Beta coming. Android is stable.
• Group video calls: Not yet supported. 1:1 audio and video work.
• Multi-device key sync: Not yet implemented. Each device has its own private key.
• PC login: Requires a mobile device for the QR handoff. There is no PC-only path.
• ZQID: Cannot be changed, including on Diamond.
• File size limits: Vary by plan.
• Message metadata: Sender, receiver, timestamp, and size are visible to the server. Only the body is encrypted.

18 Security Reporting

If you discover a vulnerability, report it privately. We do not pursue researchers who follow responsible disclosure.

• Email: security@zeqat.com
• Response time: Within 48 hours
• Confidentiality: All reports handled privately
• Recognition: With your consent, we credit reporters in the changelog

19 Changelog

Track the latest updates to ZEQAT and its security model.