blue_ghost

Bluetooth Low Energy provides short‑range, low‑power, infrastructure‑free communication. Wi‑Fi introduces unnecessary metadata exposure (SSID/BSSID scanning), larger attack surfaces, and potential interaction with malicious access points. BLE eliminates all of those vectors.

Any Android device running blue_ghost within Bluetooth range. No accounts, phone numbers, SIM cards, or internet connection are required on either device.

Typical BLE range is 5–30 meters depending on:

• Device hardware and antenna quality
• Obstacles (walls, vehicles, terrain)
• RF congestion in the environment

blue_ghost intentionally does not boost TX power to avoid increasing the detection radius.

They get nothing useful. Every payload is encrypted with AES-256-GCM and protected by the Double Ratchet. An RF capture reveals:

• No plaintext content
• No sender or receiver identity
• No message count or timing patterns
• No metadata of any kind

No messages or cryptographic material is ever written to disk. Everything lives in memory only. When a session ends — whether you close the app or trigger it manually — the Seal Ceremony runs and wipes all of it: root key, chain keys, message keys, ratchet state, and message history. A small amount of non-sensitive preference data (peer display names, avatar seeds, UI settings) is stored locally in SharedPreferences and contains no message content or secrets.

On Android 12 and above, it doesn't — blue_ghost uses the neverForLocation flag on the BLUETOOTH_SCAN permission, so location is never requested on modern devices.

On Android 11 and below, Google's OS requires location permission as a prerequisite for any BLE scanning. blue_ghost requests it on those versions to function, but GPS is never accessed and no location data is collected or stored.

When two devices connect, they perform an ephemeral ECDH (P-256) key exchange — both sides generate fresh temporary keypairs, exchange public keys over BLE, and compute a shared secret locally. The shared secret is never transmitted. HKDF-SHA256 then derives the initial ratchet keys from the shared secret. Since the keypairs are generated fresh per session, no prior session material is ever reused.

The Safety Number is a human-readable fingerprint derived from both users' long-term identity public keys. If both users read their Safety Numbers aloud and they match, the session is cryptographically authentic — no MITM is present. This is the same verification approach used by Signal.

No. This is intentional — persistent storage of message history creates attack surfaces. The design assumes that conversations should not outlive the session.

Anyone who needs secure, offline, device‑to‑device communication — and anyone who simply prefers privacy done right.

🛰️ Field Teams & On‑Site Operators

• Disaster‑response volunteers coordinating in collapsed infrastructure
• Environmental researchers in forests, deserts, or remote terrain
• Film crews on closed sets where phones must stay offline
• Warehouse and logistics teams who need quiet, local coordination

🕵️ Security‑Minded Professionals

• Security researchers testing devices in Faraday environments
• Pen‑test teams coordinating inside restricted facilities
• Red‑teamers who need a comms layer that cannot leak

📡 Network‑Denied Environments

• Underground facilities, remote villages, airplane cabins
• Mountain passes, national parks, cruise ships

🎭 Creators, Artists & Event Organizers

• Stage crews during live performances
• DJs and lighting techs at crowded venues
• Photographers directing assistants across a set

🏙️ Everyday Urban Users

• Meeting someone at a bar without giving your number
• Messaging a neighbor in your building
• Coordinating with friends at a crowded festival

🧩 People Who Want Conversations That Don't Live Forever

• Temporary coordination and one‑time exchanges
• Sensitive personal discussions
• Conversations that shouldn't be stored, synced, or backed up