Help — Best Practices
Keys, storage, and dangers.
How to use FGSP without creating avoidable risks. Read this before you store anything you can't afford to lose.
Your keys are everything
Your Shape Key and Coordinate are the only path to your data. No one else holds them. No one else can reconstruct them. Treat them with the same care you'd give a physical key to something irreplaceable — because that's exactly what they are.
How to store your keys
Write them down physically and store offline
A piece of paper in a secure location — a safe, a safe deposit box, or another physically protected place. Not in a notes app. Not in your email. Not in a password manager synced to the cloud. Physical paper cannot be remotely exfiltrated.
Store in at least two separate locations
One copy is not enough. A house fire, a theft, a natural disaster — any single-location failure should not mean permanent data loss. Two separate secure locations is the minimum for anything important.
Consider a trusted person as a second holder
A lawyer, a family member, a trusted colleague. Someone who can produce your keys if you can't. This can be combined with the deadman system — they receive an encrypted release packet, and you give them the Shape Key separately, in advance.
Memorize them if the stakes are high enough
For people operating in truly hostile environments — border crossings, hostile custody situations — the safest key storage is your memory. FGSP keys are designed to be memorizable. Test yourself regularly so they don't fade.
What not to do
Don't store keys in a cloud password manager
1Password, Bitwarden, LastPass — all of these sync to servers that can be subpoenaed, breached, or compelled. If your keys live in a cloud password manager, the structural-inability defense is weakened. Use an air-gapped password manager or physical storage.
Don't save keys in plaintext on a connected device
A text file, a notes app, an email draft — anything on a device connected to the internet is accessible to malware, cloud sync, and forensic recovery tools. If the device is seized, plaintext keys are trivially recoverable.
Don't use FGSP for data you access from a compromised device
FGSP protects data at rest and in transit. It does not protect your session. If your device has malware, keyloggers, or remote access tools, an attacker sees your plaintext at the moment you access your files. Clean device hygiene is your responsibility.
Don't rely on a single Drive A with no key backup
Drive A is a convenience tool, not a key backup. If your Drive A is your only path to your storage and it's lost or destroyed, and you don't have your keys written down anywhere, access is gone permanently.
Real risks to understand
Coercion is outside the architecture
If someone forces you to hand over your keys — under legal order, physical threat, or other coercion — the data is accessible. FGSP's structural-inability defense protects the operator from being compelled. It does not protect you from being compelled. Plan for this scenario if it's relevant to your threat model. Deadman release, multiple holding parties, and memorization-only keys are all tools for managing coercion risk.
Endpoint compromise defeats everything
FGSP is designed for a clean, trusted device. If your device is compromised at the time you access your storage, the attacker reads your plaintext directly — regardless of how strong the storage protocol is. Use FGSP from clean devices. Consider Tails OS or another amnesic system for the highest-stakes access.
Tor has its own threat model
FGSP routes through Tor v3 hidden services. Tor protects against most network-level adversaries, but nation-state level traffic analysis, compromised relays, and timing correlation attacks are real (if difficult) attacks. For the vast majority of use cases, Tor provides sufficient protection. For adversaries with nation-state resources targeting you specifically, additional operational security measures beyond FGSP are warranted.
Drive A best practices
Keep Drive A separate from your device
Don't leave Drive A plugged in when you're not using FGSP. A seized device with Drive A still inserted is a different threat profile than a seized device with no Drive A present.
Consider burn-on-use for single-operation access
If you're uploading from a location you'll never return to, or if the Drive A might be confiscated after use, configure it to burn its token on first successful use. It becomes a receipt — functional once, inert after.
Regenerate Drive A periodically
Drive A bundles have a token TTL. Regenerate from the Navigator dashboard when prompted — or proactively on a schedule. Old tokens that have expired cannot be refreshed without your keys.