Local Vault

Use the device-local encrypted vault

The recorded storage implementation is a local encrypted vault, not a distributed storage network. It uses AES-256-GCM with an Android Keystore key and a versioned envelope. The key is bound to the installation's device environment. The website should therefore describe local file protection and deliberate export, not rented storage capacity, decentralized backup or earnings from disk space.

Understand the file lifecycle

The user selects a file, the app reads it under a byte limit, encrypts it and publishes the object atomically. The candidate's allowance includes an eight-million-byte per-object bound; do not show an example implying a gigabyte object is accepted by that path. Device storage readings describe the phone's disk. They are not a cloud quota, a contribution reservation or a customer payment balance.

An object receives a validated random identifier before becoming a file path. Temporary output is written, fsynced and renamed to publish a completed object. Startup cleanup removes abandoned temporary files. These details matter because a crash during encryption should not make a partially written object appear complete. A UI success message should follow successful durable publication.

Read the envelope correctly

The versioned EOV2 header is bound as additional authenticated data. Lengths are checked before allocations, and corrupted or unsupported envelopes should fail clearly. Authenticated encryption protects integrity of the encrypted content under the key. It does not establish where an object was replicated or how long another machine stored it. Legacy compatibility should be tested against actual legacy samples rather than assumed from a file extension.

A file import size limit must be enforced during reading, not only against metadata that can be inaccurate or unavailable. The same principle applies to receipt import and AI attachment handling. Large, malicious or streaming inputs should not consume unbounded memory before the app decides they are too large. The user should see a specific size or decoding refusal rather than an unexplained crash.

Export with deliberate consent

A decrypted export is plaintext. The app should say so before sharing it. The recipient application may store, sync or upload that file under its own policy. EdgeORE cannot guarantee privacy after handing plaintext to another app. A public demo should use a non-sensitive sample rather than a real personal document that later needs to be removed from screenshots.

Device-bound keys mean a new phone cannot automatically decrypt old ciphertext. Uninstalling can destroy access to encrypted data. Backup and recovery are separate product designs requiring their own threat model and user consent. Do not describe the existing vault as recoverable decentralized backup. Before any destructive test, preserve the input in an appropriate safe location and document the reset.

Qualify the vault path

On an identified Android runtime, import a small known file, encrypt it, reopen the app, decrypt/export it and compare the output hash with the original. Test a corrupted envelope, an over-limit import and an interrupted write. Preserve Keystore behavior and errors as environment-specific evidence. Unit tests and a storage page rendering are not equivalent to this sequence. The ledger keeps the device vault unqualified until actual runtime artifacts support it.

---

Wiki home · Qualification updates · Sources and credits