Security & Cryptography Glossary

Sino creates and keeps your keys on your own devices (Android and Windows). Your cloud only ever receives encrypted data, and the keys that open it are never given to Sino or to your cloud provider. Neither can view, index or decrypt your files.

Each file gets its own random 256-bit key and is split into 1 MiB chunks (1,048,576 B). Each chunk is encrypted with AES-256-GCM, with its own counter nonce (BaseIV[0..7] || ChunkIdx) and a 16-byte authentication tag, so any chunk can be decrypted and checked on its own, and reordering or changing a chunk is detected.

Sino encrypts its local database as a whole (SQLCipher 4 format: AES-256 with an HMAC-SHA512 per page), and encrypts sensitive fields again with probabilistic AES-256-GCM (key label SINO/V1/DB-FIELD-ENC). The real and decoy vaults each have their own database file.

Your master password and your 24-word recovery phrase are stretched with RFC 9106 Argon2id (64 MiB of memory, 3 iterations, 4 lanes), which makes every guess slow and expensive for GPU clusters and custom hardware. The result is split into a stored verifier and a key-encryption key that exists only in memory.

Lets Sino find exact values (such as checksums and file locations) without storing them in plain text. Values are encrypted probabilistically with AES-256-GCM, and lookups use deterministic HMAC-SHA256 blind indexes (SINO/V1/DB-FIELD-INDEX). Everything runs on your device; nothing about a search is sent to a cloud.

Sino uses RFC 5869 HKDF with SHA-512, with a distinct label for each purpose (for example SINO/V1/PASSWORD-KEK, SINO/V1/RECOVERY-KEK, SINO/V1/DEVICE-ENVELOPE, SINO/V1/DB-FIELD-ENC), so a key made for one job can never be used for another.

NIST FIPS 203 ML-KEM-768 key encapsulation, chosen to defeat 'Harvest Now, Decrypt Later' attacks. Each enrolled device has its own LatticeGate key pair (1,184 B public key), whose seed never leaves it; a wrong-password alert is sealed to each of your other devices' keys (1,088 B ciphertext each), so only they can read it. The device list holds no copy of the vault key.

Sino keeps its device secrets in the phone's or PC's security chip: the Android Keystore (StrongBox or TEE) and the Windows TPM 2.0, with DPAPI as fallback. Keys held there cannot be exported. Your vault key is released only by your password or your biometric, lives in memory only while Sino is unlocked, and is wiped on lock.

Sino for Windows seals every stored secret on its own with the PC's TPM 2.0, or with DPAPI (bound to the Windows account) when the TPM cannot seal. A value that is edited, or copied to another PC or account, does not open, so copying Sino's files to another machine gives an attacker nothing.

On Android, your vault key is also wrapped by a Keystore key (StrongBox or TEE) that needs a strong biometric for every use; enrolling a new fingerprint or face invalidates it. On Windows, Windows Hello releases it through a passkey. Your master password always works as a fallback.

Sino generates a random 256-bit Root Master Key for your vault. It is stored only in wrapped (encrypted) form: by your password (via Argon2id), by your biometric key, and by your recovery phrase in the encrypted backup in your clouds. It is decrypted only in memory while the vault is unlocked.

A modern public-key standard that replaces typed passwords with your fingerprint, face or PIN. Sino uses passkeys with the PRF extension to unlock Windows Hello, and as recovery passkeys that bring back your recovery phrase on a new device without typing it.

Sino can keep each folder on one or several clouds (Google Drive, MEGA, S3, Azure), and always copies the vault's security files to every connected cloud. A local file is deleted to free up space only once every cloud chosen for its folder holds a verified copy, and missing copies are found and re-uploaded.

Layout [MAGIC(4B)][VERSION(1B=0x02)][IV(12B)][CIPHERTEXT][SHA256(32B)], used for folder file lists, snapshots, settings and the recovery backup. AES-256-GCM protects the contents; the trailing SHA-256 tells storage damage apart from a wrong key or tampering.

Sino signs in to MEGA with MEGA's own client-side login: your MEGA password is stretched on your device (PBKDF2-HMAC-SHA512) and never sent over the network. Two-factor codes are supported, and Strict 2FA mode never stores the code seed.

Every cloud name is a salted HMAC-SHA256 hash that only your devices can compute: 32 hex characters for folders and files, 16 for the vault's namespaces and for each folder's encrypted file list (.batch). The real names live only inside those encrypted file lists, so cloud hosts see no file names, no folder names and no folder tree.

Encrypted files upload in parts sized for each cloud: 8 MiB by default, in Google Drive's 256 KiB steps and at least S3's 5 MiB, and larger for a file that would otherwise need more parts than S3 (10,000) or Azure (50,000) allow. Each cloud takes the parts at its own pace, several at once where it allows. Sino records each finished part and its size, so an interrupted upload resumes from the last one.

There is no Sino server. Every device with your vault (Android or Windows) has its own ML-KEM key pair and its own entry in the signed device list, and devices stay in step only through the encrypted files in your own clouds.

From any unlocked device, revoke a lost one: it moves to the signed list's revoked entries, and the next time it checks (on Android at every unlock and every hour, retrying when offline; on Windows every 15 minutes while Sino runs; on both right after a wrong password), it wipes itself, even while locked. No file is re-encrypted. Revocation cannot take back what that device already decrypted, so also change your passwords.

Eliminates cleartext temp-file caching on flash drives or SSD storage. VolatileStream uses custom in-memory streaming providers and decryptRange() chunked range decryption to decode only requested audio, video, or PDF byte frames directly to the display pipeline. Managed memory buffers are zeroized upon stream closure.

Files you add or move into Sino are stored encrypted in its private storage, out of reach of your gallery, file manager and other apps, in folders you make. Each folder is kept on this device only, or backed up to the clouds you pick using the same encrypted files, with nothing re-encrypted. Files kept on this device only are lost if the device is lost.

Under physical coercion or forced disclosure, entering your secondary duress PIN or passphrase unlocks a completely separate, device-bound PhantomVault decoy database. The decoy presents plausible deniability with fake records while keeping the primary vault isolated, encrypted, and completely concealed.

Emergency wipe of this device only: Sino locks and clears its keys from memory, deletes the keys in the security chip first (so anything left can never be decrypted), then deletes its databases, settings and app data, and closes. Your cloud backups are not touched; deleting them is the separate Wipe Cloud.

24 words from the BIP-39 word list. Stretched with Argon2id, they open rmk_backup.bin, the encrypted copy of your Root Master Key kept in your clouds. The phrase is never stored or uploaded, and no Sino server is involved. With a downloaded copy of your vault, the open-source Sino Open SDK can recover it offline.

Screenshot Protection blocks screenshots and screen recording (Android FLAG_SECURE). Stealth Mode disguises Sino as a calculator: on Android its icon and name change; on Windows it runs as a working calculator that reveals Sino only after your secret code.

Sino's security contact uses PGP key ID 741269C3 (fingerprint 7B52 729E E9A9 1445 D9BE 1F46 AEEE B140 7412 69C3). Use it to verify signed security messages from us and to encrypt vulnerability reports to support@sinosecure.app.

Signs your vault's device list. Every device pins the signing key and the newest version it has seen, so a forged, tampered or replayed list is refused, even by a future quantum computer. Revocations in a verified list are what trigger InstantSever.

The Sino Control Hub is a server a company runs itself, on its own machine or in its own cloud, to enroll, configure and audit its people's work vaults. It signs policy and commands, collects audit events for the company's SIEM and hands out short-lived storage access. It holds public keys only, so it cannot open a vault, a file or a file name, and files never pass through it. Sino runs no hub and never sees one.

A vault enrolled with a company's Control Hub, from a link the company sends. Only a new, empty vault can enroll, and the app shows the company's name and what it can do before you agree. The company's policy applies, a quorum of its admins can recover the vault, and the decoy vault and legacy handover are off. A personal vault that never enrolled stays yours alone.

Made in the Sino app when a company sets up its hub, and kept by its admins, never by the hub. Each kit is a Shamir share of the company's root and recovery keys: 2 of 3 by default. Together, a quorum recovers a managed vault or a shared folder whose owners left, and signs the hub's certificate. One kit alone opens nothing. A kit can be saved with a passphrase or printed as QR codes.

A remote wipe, unenroll, cloud wipe, vault recovery, new approvers and any policy that lowers privacy need the passkeys of enough approvers. Each device checks those signatures itself, so even a breached hub cannot do it alone. A cooling-off delay (6 hours by default), always on when one approval is enough, gives any admin time to cancel.

While Sino is open on Windows, the PC keeps one signed, streamed call open to the company's hub, for up to 3 minutes at a time, and the hub says the moment a command waits. The command itself arrives signed in the next check-in. Other devices get commands at their next check-in, every 15 minutes to once a day. There is no push while the app is closed.