Encrypted on your device.Verified on your device.

01

Sign-in and decryption are separate

Signing in lets the service identify your account and enforce access permissions. Unlocking an encrypted drive happens locally, using an encryption passphrase, a recovery key or a supported encryption passkey. The account login alone does not supply the secret needed to decrypt the drive.

02

How your keys are created and unlocked

Account setup generates a random 256-bit root key and an ECDSA P-256 signing key pair on the device. The root key and private signing key are kept in an encrypted account bundle. The server receives encrypted copies of that bundle and the public verification key.

The encryption passphrase is normalized with Unicode NFKC and processed by Argon2id with a random 16-byte salt, 64 MiB of memory, 3 iterations and parallelism 4. The resulting 256-bit key protects the account bundle with AES-GCM. These parameters slow password guessing; a strong, unique passphrase still matters.

A separately generated random 256-bit recovery key protects another copy of the same bundle. Changing the passphrase rewraps the bundle; it does not re-encrypt every stored file. On supported authenticators, WebAuthn PRF supplies material for a separate passkey unlock envelope. A passkey used only for account sign-in is not automatically an encryption passkey.

Rewrapping does not revoke an old key bundle that someone has already copied and can unlock. Removing an encryption passkey stops future retrieval of its wrapper, but cannot erase keys already obtained by an unlocked client.

Keep the recovery key somewhere safe outside the drive. Losing every usable unlock method and every unlocked device can make the encrypted data unrecoverable. Resetting an account login does not recreate the encryption keys.

03

File encryption and the role of Google Tink

Each new file revision gets a fresh random 256-bit content key. Files are encrypted in authenticated segments, so clients can upload large files and read a requested range without first decrypting the entire file. Each segment is checked before its plaintext is released.

InfiniDrive implements the wire format compatible with Google Tink’s RAW AES256_GCM_HKDF_1MB Streaming AEAD profile. HKDF-SHA-256 derives a per-stream AES key from the content key and a fresh salt. Segment nonces combine a random prefix, the segment index and a final-segment flag. The format authenticates segment position and completion.

Compatibility with Google Tink is verified through bidirectional encryption and decryption tests.

04

Metadata, signatures and version checks

File names and content metadata are encrypted separately from file bytes. Content keys are wrapped in authenticated encryption envelopes. Context binds protected data to its account, node, revision and purpose, reducing the risk of accepting a valid encrypted object in the wrong place.

ECDSA P-256 signatures with SHA-256 protect manifests and account operations. Clients check signatures, object identities and revision context before exposing content. History checks compare server responses with locally remembered checkpoints to detect rollback or conflicting history relative to what that device has already observed.

A new device needs an initial trusted state. Local checkpoints are not a global key-transparency service, and signatures alone cannot guarantee that a server presents the same history to every device.

05

Photos, previews and shared links

Supported clients generate image and video previews locally. A preview has its own random revision key and is encrypted before upload. Its encrypted, signed metadata binds it to the source file revision. Preview delivery stores and serves encrypted bytes; the client verifies and decrypts the image.

An encrypted public link carries its decryption secret in the URL fragment, after the # character. Browsers do not include that fragment in the HTTP request to the server. The recipient’s browser uses the secret locally to unlock the shared content.

The link also contains a separate access capability, which the client sends to the service to authorize retrieval, and a digest that pins the signed share record. The encrypted grant contains keys for the selected file revisions, rather than the account root key. A shared link refers to a read-only snapshot of those revisions.

Anyone with the complete link can use its secret, so treat the link like access to the file. Revoking a link can stop future service access, but cannot erase a copy that a recipient has already downloaded or decrypted.

06

Where keys and readable files live

Native clients can remember unlocked account keys using operating-system protection: Keychain on Apple platforms, secure storage backed by Android Keystore, and per-user DPAPI on Windows. The app needs usable keys while it is decrypting; operating-system storage does not make a compromised, unlocked device safe.

Locking the drive and signing out restrict further use of its keys. Readable files already downloaded through Finder, Explorer, an export or another app can remain on disk. Local files, operating-system thumbnail caches, backups and other apps have their own protection and retention rules.