Security & Cryptographic Architecture
Sino encrypts everything on your own device, keeps the keys with you, and treats every cloud as untrusted storage. Below is a plain-language summary first, then the full technical detail: hardware-protected keys (IronCore), post-quantum protection (QuantumShield with LatticeGate) and the exact algorithms we use.
Security in Plain Words
Locked before it leaves
Every file is encrypted on your phone or PC, with its own key, before it is uploaded. Your clouds store data they cannot read.
Names stay hidden
File and folder names are replaced by scrambled codes in the cloud. The real names live only in encrypted lists that your devices can open.
Only you hold the keys
Your vault opens with your password, your fingerprint, face or Windows Hello, or your 24-word recovery phrase. We have no copy and no back door.
A lost device can wipe itself
Revoke a lost phone or PC from another device, and it erases Sino the next time it connects, even while locked. The Panic action wipes the device you are holding.
Ready for quantum computers
Data recorded today stays safe later: AES-256 for your files, and the new NIST post-quantum standards for the keys your devices share.
Checkable by anyone
Our cloud format is published, and the open-source Sino Open SDK can verify and recover a vault without our app.
What Sino Cannot Protect You From
No security tool protects against everything. These are the limits worth knowing before you rely on Sino.
Spyware already on your device
If malware is running on your phone or PC while Sino is unlocked, it can see what you see. Keep your device updated and install apps only from sources you trust.
Your 24 words in the wrong hands
Anyone with your recovery phrase and access to one of your cloud accounts can restore your vault. Keep the words offline and private.
Losing every way back
If you lose your 24 words, your recovery passkey and every device that can unlock your vault, nobody can open it, including us. There is no back door.
Files after they leave Sino
A file you export, share, or restore to your gallery or another folder is an ordinary, unencrypted file again.
A lost device that never reconnects
Revoking a device makes it wipe itself the next time it connects. It cannot take back files that device already opened or copied. Until it connects, its vault is still locked by your password and biometrics.
Being forced to unlock
The decoy vault gives you a believable vault to open instead, but it cannot promise that a determined person will not suspect there is another one.
A weak master password
Sino makes guessing slow (Argon2id, and lockouts after failed attempts), but a short or common password can still be guessed. Use a long one, and unlock with your fingerprint, face or Windows Hello day to day.
Losing your cloud account
Someone who gets into your cloud account cannot read your files, but can delete them, and a provider can close an account. Turn on two-step verification for your cloud accounts, and keep copies on more than one cloud.
What your cloud can still see
That you use Sino, roughly how much you store and how large your files are, when you upload, and the name of each device in Sino's device list (such as your phone's model or your PC's name). Never your files' contents or their file and folder names.
Sino has also not had an independent security audit yet: see audit status.
Cryptographic Standards & Protocols
AegisStream AES-256-GCM
Every file has its own random 256-bit key and is encrypted in 1 MiB authenticated chunks, each with a 128-bit GCM tag and a 32-bit counter nonce. Reordering, cutting or changing any chunk is detected. Uploads go in resumable 8 MiB parts.
BlindSight Indexing + SQLCipher
The local database is encrypted as a whole (SQLCipher 4 format: AES-256 with an HMAC-SHA512 per page), one for the real vault and one for the decoy. Sensitive fields are encrypted again with AES-256-GCM, and searched through HMAC-SHA256 blind indexes.
Memory-Hard Argon2id & IronSeed
Your master password and your 24-word IronSeed are stretched with Argon2id (RFC 9106: 64 MiB, 3 iterations, 4 lanes). HKDF then splits the result into a stored verifier and a key-encryption key used only in memory, so the stored verifier cannot open anything.
IronCore Biometric Bridge
For quick daily unlocks, the vault key is also wrapped by a key that needs your presence: on Android, a Keystore key (StrongBox or TEE) that requires a strong biometric for every use; on Windows, a Windows Hello passkey (WebAuthn PRF).
Version 2 Binary Containers
Folder file lists, snapshots, settings and the recovery backup are sealed in Version 2 containers ([SINO][0x02][IV][CIPHERTEXT][SHA256]). AES-256-GCM protects them; the trailing SHA-256 tells storage damage apart from tampering.
OmniMirror Multi-Cloud Copies
Keeps copies on Google Drive, MEGA and S3-compatible storage. File lists from every cloud are merged so that an old copy served by one provider cannot undo deletions, and snapshots carry versions that a device never lets go backwards.
QuantumShield Suite (PQC v1)
Each device's copy of the vault key is sealed with ML-KEM-768 (NIST FIPS 203), and the device list is signed with ML-DSA-65 (NIST FIPS 204), under the suite identifier SINO-VAULT-V1-AES256GCM-HKDFSHA512-MLKEM768-MLDSA65. Sino's own implementations are tested against the NIST ACVP vectors.
QuantumShield & Signed Device Revocation
Each device pins the list's signing key and newest version, so a forged or replayed list is refused. A revoked device wipes itself (Terminus Protocol) the next time it checks, locked or not; cloud data stays intact. This is a kill switch, not a lock-out: it cannot take back what that device already decrypted.
Device Enrolment Without Re-encryption
When a device unlocks your vault, it adds its public keys to the signed device list. No file is re-encrypted or re-uploaded, whatever the size of your vault.
Hardware Root of Trust & Anti-Tampering
Sino anchors root cryptographic keys inside dedicated physical hardware security modules across all supported operating systems.
Android StrongBox & TEE (IronCore)
Root Master Keys are protected by Android Keystore (TEE / StrongBox) or master password (Argon2id), while post-quantum ML-KEM seeds remain securely on-device.
Windows TPM 2.0 & DPAPI (IronCore)
Desktop secrets are sealed with the TPM 2.0, or with DPAPI when the TPM cannot seal. Each stored value is sealed on its own and bound to its name, so an edited value, or one copied to another PC or Windows account, does not open.
LatticeGate Biometric Passkeys
FIDO2/WebAuthn with the PRF extension enables seamless hardware passkey enrollment, restoring your recovery phrase on compatible devices without typing.
VolatileStream Memory Hygiene
Minimizes plaintext disk persistence by streaming media strictly through volatile RAM buffers. Sensitive byte arrays (DEKs, master keys, decrypted chunks) are wrapped in try-finally blocks and immediately zeroized via in-memory zeroization upon stream termination.
Threat Model & Native Mitigations
| Threat Actor / Vector | Attack Scenario | Sino Native Cryptographic Mitigation |
|---|---|---|
| Physical Coercion / Compelled Unlock | Forced entry or disclosure of master password under duress. | PhantomVault: A decoy password opens a separate decoy vault with its own key, database file, cloud namespace and Local Vault store. Both databases exist on every install, and nothing in the cloud labels a vault as a decoy. |
| Sudden Device Seizure / Theft | Device snatched while active and unlocked. | The Terminus Protocol: Deterministic emergency wipe: locks and clears in-memory keys, deletes hardware-backed keys so ciphertext cannot be decrypted, purges local databases and app data, and exits. Cloud backups remain untouched. |
| Hostile Cloud Storage Breach | Cloud provider compromised, inspected, or compelled by third parties. | Cloud Path Obfuscation via Obscura Tree & OmniMirror: AES-256-GCM encrypted files and file lists, salted HMAC-SHA256 names (32-char folders and files, 16-char namespaces and metadata batches) and copies on several clouds. No plaintext file name or folder structure reaches the cloud. A provider can still delete or withhold data, which mirroring covers. |
| Workstation Configuration Hijacking | Attacker copies desktop boot files to another computer. | IronCore Per-Value Sealing: Every secret is sealed by the TPM or by DPAPI (with entropy from the Machine GUID and the Windows account SID). Copied to another PC or account, the values do not open. |
| Volatile RAM Extraction / Forensics | Root malware or cold-boot attack attempts to dump process memory. | VolatileStream RAM Streaming & Hygiene: Plaintext buffers and ephemeral keys are streamed exclusively in volatile memory and wiped with zero-fill routines in finally blocks to minimize cleartext memory persistence. |
| Harvest Now, Decrypt Later (HNDL) | Adversaries intercept and record encrypted cloud traffic today, waiting to deploy quantum computers running Shor's algorithm. | QuantumShield & LatticeGate Architecture: Vault key establishment utilizes lattice-based ML-KEM-768 (NIST FIPS 203) and manifests are signed with ML-DSA-65 (NIST FIPS 204). File payloads retain AES-256-GCM via AegisStream (maintaining 128-bit quantum security against Grover's algorithm). |
| Lost or Stolen Node in Fleet | Companion laptop or phone is lost, stolen, or compromised. | Signed Device List Revocation: Revokes the node on the ML-DSA-65 signed device list; the revoked device automatically executes a local Terminus Protocol wipe when it connects online. |
Defense Boundaries & Operational Assumptions
Defensible security requires clear distinction between threats mitigated by software architecture and operational assumptions requiring host endpoint hygiene.
- • Untrusted Cloud Breaches: Compromise of remote storage targets (Google Drive, MEGA, S3) yields only AES-256-GCM ciphertext chunks and hashed folder names.
- • Network Interception & MITM: Eavesdropping on synchronization traffic exposes no plaintext payloads or cleartext directory hierarchies.
- • Physical Theft of Locked Devices: While Sino is locked, the vault key is not in memory; it is released only by your password or your biometric. Device secrets stay sealed by StrongBox/TEE or the TPM.
- • Harvest Now, Decrypt Later (HNDL): LatticeGate ML-KEM-768 key encapsulation mitigates future quantum decryption of archived ciphertext.
- • Active Host Kernel Compromise: Kernel rootkits or memory scrapers running on an unlocked host during active use can access in-memory plaintext.
- • Managed Runtime Memory Persistence: Garbage collection cycles and OS page swapping in managed runtimes may temporarily retain copies outside explicitly zeroized buffers.
- • Deterministic File Equality: Cleartext files with identical checksums produce deterministic cloud blob names under the same path salt.
- • Coercion Without Duress Entry: Disclosing primary credentials without activating the PhantomVault duress PIN allows legitimate vault decryption.
Cryptographic Standards & Parameter Matrix
| Subsystem / Function | Algorithm / Standard | Technical Specification |
|---|---|---|
| Media Chunk Encryption | AegisStream (AES-256-GCM) | 1MB Plain Chunks (1,048,576 B) + 16B GCM Tag = 1,048,592 B Encrypted Packets |
| Resumable Upload | AegisStream Multipart | 8 MiB parts (Drive 256 KiB alignment, above the S3 minimum); resumes from the last finished part |
| In-Memory Media Pipeline | VolatileStream Engine | Zero flash cache, chunked range playback (decryptRange), instant fillZero() wipe |
| Multi-Cloud Storage Array | OmniMirror Cloud Copies | Per-folder cloud choice across Google Drive, MEGA and S3; union-merged file lists; health checks and repair |
| Database Storage Encryption | BlindSight Indexing + SQLCipher | SQLCipher 4 pages (AES-256-CBC + HMAC-SHA512) + AES-256-GCM fields + HMAC-SHA256 blind index |
| Master Password & Keystone Derivation | Argon2id (RFC 9106) & IronSeed | Time = 3, Memory = 65,536 KiB (64 MiB), Parallelism = 4, 32-byte output; 24 words from the BIP-39 list |
| Domain Key Derivation | HKDF-SHA-512 (RFC 5869) | Labelled per purpose: SINO/V1/PASSWORD-KEK, SINO/V1/RECOVERY-KEK, SINO/V1/DEVICE-ALERT, SINO/V1/DB-FIELD-ENC, … |
| System Artifact Containers | Sino Binary Container v2 | [SINO][0x02][IV][CIPHERTEXT][SHA256] whole-stream integrity check |
| Cloud Path Obfuscation | Obscura Tree (Salted HMAC) | 32-char folder paths, 32-char file blobs, 16-char .batch metadata batches |
| Hardware Key Anchoring | IronCore Silicon Enclave | StrongBox / TEE / TPM 2.0 non-exportable device keys; vault key released only by password or biometric |
| Secret Sealing Architecture | Individual Hardware Secret Binding | TPM 2.0 with DPAPI fallback; each stored value sealed individually and bound to its name |
| Forensic Sanitization & Self-Destruct | The Terminus Protocol | In-memory key zeroing → hardware key destruction → local database & preference purge |
| Post-Quantum Key Encapsulation | LatticeGate (ML-KEM-768) | 1,184B Public Key, 1,088B Ciphertext, 32B Shared Secret (NIST FIPS 203; 64-byte seed never leaves the device) |
| Post-Quantum Digital Signatures | QuantumShield (ML-DSA-65) | 1,952B Public Key, 3,309B Manifest Signature (NIST FIPS 204; pure-Kotlin implementation tested against NIST ACVP vectors) |
| Cryptographic Suite Identifier | QuantumShield Suite Binding | SINO-VAULT-V1-AES256GCM-HKDFSHA512-MLKEM768-MLDSA65 bound in the device list and its entries |
| Device Keys & Alerts | LatticeGate device entry (v2) | Public ML-KEM-768 + ML-DSA-65 keys per node, no vault-key copy; opt-in wrong-password alerts sealed per device and signed |
| Signed Device Revocation | QuantumShield Device Revocation | Signed device list pinned by each device; a revoked device wipes itself on its next check (Android: every unlock and every 6 h, retried when offline; Windows: every 15 min while running) |
| Distributed Node Mesh | Sino OrbitMesh Topology | No central server: each device has its own ML-KEM key pair and syncs only through your clouds |
| Coercion & Duress Safe | PhantomVault Safe | Separate salt, device-bound root key, database, cloud namespace and Local Vault store |
| Device Enrolment | Zero Re-encryption | A device adds its public keys on unlock and re-signs the list; 0 bytes of files re-encrypted |
Audit Status
Not yet independently auditedSino has not yet had an independent security audit, and its cryptography is not FIPS 140 validated. If an audit is carried out, its report will be published on this page. Until then, here is what anyone can check:
- Standard building blocksSino uses published, widely reviewed algorithms (AES-256-GCM, Argon2id, HKDF-SHA-512, ML-KEM-768, ML-DSA-65) from established libraries such as Bouncy Castle, Google Tink and SQLCipher, listed in the Acknowledgements.
- An open-source second opinionThe MIT-licensed Sino Open SDK reads, checks and decrypts a vault on its own, so you can confirm your files are stored as described and recover them without our app.
- The full designThe Security Whitepaper and the architecture map describe every key, file format and check in detail.
Report a Security Problem
Found a weakness in the Sino apps, their cloud format, the Sino Open SDK or this website? Please tell us privately first, so we can fix it before anyone can misuse it.
- 1Tell us privately
Email support@sinosecure.app, ideally encrypted with our PGP key (fingerprint 7B52 729E E9A9 1445 D9BE 1F46 AEEE B140 7412 69C3), or use GitHub's private vulnerability reporting on the Sino Open SDK.
- 2Tell us what you found
Which app and version (Android or Windows), the SDK or the website; what you did; what happened; and what an attacker could gain. Steps to reproduce it help most.
- 3Give us time to fix it
Please do not publish details until a fix is available. We will confirm we received your report, keep you updated, and credit you in the changelog if you would like.
While you test, please
- use only your own devices, vaults and cloud accounts;
- never access, change or delete anyone else's data;
- avoid anything that could disrupt other people's use of Sino or its website.
What We Most Want to Hear About
Vault Key Compromise
Unauthenticated remote key extraction or cipher bypass.
Metadata Leakage
Bypassing Obscura Tree cloud directory salt obfuscation or container integrity.
Decoy Vault Bypass
Local privilege escalation or PhantomVault duress handshake detection.
Discovered a Security Vulnerability?
Send PGP-encrypted reports to support@sinosecure.app Fingerprint: 7B52 729E E9A9 1445 D9BE 1F46 AEEE B140 7412 69C3
Open Source Cryptographic Core
Sino is a premium application, but the format it stores in your clouds is published, and the open-source Sino Open SDK implements it independently (MIT license). Anyone can use it to verify a vault's device list and files, or to recover a vault offline without our app.
Want to audit our implementation details?
You can download our complete security whitepaper or inspect our system architecture map.