Vault Archive Decryptor
Your .sklo recovery file and master password. Both stay in
this tab — nothing is uploaded and nothing is saved.
The .skar vault archive exported from the iOS app.
Only an archive belonging to the identity above can be opened.
A decryption tool for the .skar vault archive that the SKLO iOS app exports. It is not a messenger: there is no chat, no contacts, no relay connection, and no account. After the page loads it makes no network requests at all — the browser enforces that through a connect-src 'self' content-security policy, not through good intentions.
An archive is ciphertext all the way down and carries no key. Each file inside it is sealed with its own random key, and those keys are wrapped under a vault key derived from your identity: Kupyna-256("SKLO-files-v1" ‖ your ECDH private key). Your private key lives in the .sklo recovery file, sealed with your master password. So: .sklo + password → private key → vault key → the archive opens. Without both, an archive is indistinguishable from noise past its header.
The master password is stretched with Argon2id (64 MiB, 3 passes) into a key-encryption key, which unseals the recovery file. The vault key is derived, the archive is indexed without reading any file bytes, and the encrypted manifest is decrypted to recover names and dates. Individual files are only decrypted when you ask for one — a 2 GB archive costs a few kilobytes of reading until then.
Nothing is written to browser storage: no IndexedDB, no localStorage, no cookies. Keys are held in Uint8Arrays and zeroed on lock, on idle timeout after five minutes, and when the tab goes away.
Every chunk of every file carries a Kalyna-GCM authentication tag whose associated data binds the blob id, the chunk index and the total size. Chunks therefore cannot be reordered, swapped between files, or truncated without the tag failing — a file either decrypts whole or is refused. An archive from a different identity fails at the first key unwrap and is rejected before anything is listed.
What is not covered: the archive's outer framing — the record count and the per-record headers — is not authenticated, and the archive carries no signature saying who exported it or when. Someone who can modify the file can remove whole records without detection. Individual files cannot be forged; a list of files can be shortened.
Your browser is part of your security. Any browser extension with access to web pages can read your private key and your decrypted files directly from memory. Use a clean browser profile with no extensions, or use the iOS app, which is code-signed through the App Store.
First load is trust-on-first-use. The service worker pins the exact sha-384 of every asset, but only after a first successful load. Compare the App fingerprint at the bottom of the page against the value published for the release before entering your master password.
Cryptography. Kupyna-256 (DSTU-7564) hashing, Argon2id → Kupyna key derivation, and Kalyna-256 (DSTU-7624) authenticated encryption — all in WebAssembly compiled from the same C core the iOS app uses. No browser AES, no third-party JavaScript.
Learn more → www.sferasolutions.eu