Security Overview

Security Overview

Photosphere is built around the principle that your media should be private by default, readable only by you, on hardware you control, with keys you hold. This document describes the overall security model, known limitations, and how to protect yourself against attacks that bypass the cryptography entirely.

For technical details of the encryption implementation, see Encryption.

Security Model

Photosphere's security rests on three independent layers:

1. Encryption: all files are encrypted client-side using RSA-4096 + AES-256-CBC before they leave your device. Cloud and NAS storage providers never see unencrypted content. The encryption key never leaves your devices.
2. Integrity: the Merkle tree provides a cryptographic record of every file in the database. Any modification, deletion, or substitution of any file, encrypted or not, is immediately detectable.
3. Access control: storage credentials (who can read and write the storage location) and the encryption key are kept separate. An attacker who obtains your S3 credentials can read encrypted blobs but cannot decrypt them without the private key. An attacker who steals your private key cannot access the storage without the credentials.

These layers are independent: breaking one does not automatically break the others.

What Photosphere Protects Against

• Unauthorised access to cloud or NAS storage: files are encrypted before upload. A storage provider, a data breach at the provider, or an attacker who obtains your storage credentials sees only ciphertext.
• Brute-force attacks on the encryption: the AES-256 key space is ~10⁷⁷. Even with the world's fastest computers, exhausting it would take longer than the age of the universe by many orders of magnitude.
• File tampering and corruption: the Merkle tree detects any unexpected change to any file, whether caused by an attacker, storage error, or bit rot. For encrypted databases, the Merkle tree is itself encrypted: an attacker with only storage credentials cannot forge a replacement Merkle tree without the RSA private key, so tampering cannot be silently hidden.
• Duplicate content detection by an attacker: per-file random AES keys and IVs mean identical files produce completely different ciphertext in storage.
• Replay attacks: substituting an old version of a file is detected by the Merkle tree.
• Key compromise affecting multiple databases: each database has its own unique RSA key pair. Compromising one database's key has no effect on any other.

Known Limitations

• Quantum computing: RSA-4096 would be broken by a sufficiently powerful quantum computer running Shor's algorithm. AES-256 is more resistant (Grover's algorithm reduces it to ~128-bit effective security). An adversary who records your encrypted storage today and gains access to quantum computing in future decades could potentially decrypt it. This is a known limitation of all current RSA-based systems, not specific to Photosphere. Post-quantum encryption algorithms are a candidate for a future key type.
• Metadata leakage: file content is encrypted, but file sizes, file count, and filesystem timestamps are visible to anyone with storage access. An attacker cannot read your photos, but can infer roughly how many you have and when they were added.
• Private key compromise: if the device keychain is compromised, by malware, a vulnerable OS, physical access to an unlocked device, or social engineering, all files protected by that key become decryptable. There is no recovery path if the private key is lost or stolen; keep it backed up and keep your devices secure.
• No end-to-end authentication of encrypted files: AES-CBC does not authenticate ciphertext. A bit-flip attack on a stored file produces garbage plaintext rather than a clear error. The Merkle tree catches this, but it is a separate mechanism rather than a property of the encryption itself.
• Merkle tree integrity on unencrypted databases: the Merkle tree prevents undetected tampering only when the database is encrypted. On an unencrypted database, an attacker with write access to storage can modify files and regenerate a matching Merkle tree, hiding the changes entirely. Encryption is recommended for any database stored on untrusted storage.

Social Engineering

The strongest encryption cannot protect against an attacker who tricks you into handing over your keys. Social engineering attacks bypass cryptography entirely by targeting people rather than algorithms.

Photosphere's design reduces this attack surface:

• No account, no login: there is no Photosphere website to log into and no central account credentials to phish. An attacker cannot create a fake Photosphere login page, because there is no login.
• Photosphere never holds your keys: your private key and cloud storage credentials are stored on your own devices. No Photosphere support representative can ever acquire them them because Photosphere has never had them.
• Credential sharing requires physical proximity: the LAN share mechanism works only on the same local network and requires a pairing code displayed on the receiving device's screen. Photosphere will never ask you to enter a code shown to you remotely, or to share credentials over the internet.

What you can do:

• Never share your private key: your RSA private key should never leave your devices. Anyone who has it can decrypt your entire database. No legitimate process, including Photosphere support, will ever ask for it.
• Only enter pairing codes on devices you physically control: when sharing credentials via LAN, only enter the pairing code on a device in your hand. If someone remote asks you to enter a code they have provided, refuse.
• Use a strong device passcode: the device keychain is protected by your device's lock screen. A weak or absent passcode means anyone with physical access to an unlocked device can access your keys.
• Keep your devices and OS updated: the security of the device keychain depends on OS-level security. Staying updated ensures known vulnerabilities are patched.
• Back up your private key: store it in a password manager or another secure location. If you lose the key, the database cannot be decrypted. There is no recovery path.