https://github.com/thatSFguy/reticulum-mobile-app/compare/android-v1.2.24...android-v1.2.25/

Off-grid encrypted messaging for Android & iOS — over LoRa radio or the open internet, with no servers, no accounts, and no app-store lock-in. Native Android & iOS client for the Reticulum mesh network, built in Kotlin Multiplatform. A real native app — foreground service for persistent background connections, system notifications on incoming LXMF — replacing the browser-based webclient. No external dependencies. No accounts, no API keys, no central server, no analytics, no Google Play Services, no Firebase. Identity generated on-device, all crypto runs locally, persistence is Room (SQLite). The only outbound traffic is whatever transport you attach (BLE / Bluetooth Classic to your own RNode, or TCP to an rnsd you pick — including 127.0.0.1 for offline LAN testing). The Nodes tab embeds OpenStreetMap tiles when at least one observed destination carries lat/lon — that's the only HTTP fetch in the app. Security model & known limitations A full audit landed 2026-05-13 (see todo.md § "Security audit follow-ups" for the line-by-line findings). Zero CRITICAL issues. Every HIGH-priority finding is shipped on Android as of v1.1.27 — auto-backup carve-out, lockscreen-notification privacy, passphrase-strength gate on .rmid export, and Android Keystore-wrapping of the identity private keys. The MEDIUM and LOW findings are also closed except for one explicitly-tracked iOS follow-up (Secure-Enclave-backed identity vault) which is on-disk-format-compatible with the Android implementation and will land in a subsequent release. This section spells out what's protected, what's not, and the one outstanding iOS hardening item so users can factor it into their own threat model. Wire / over-the-air - LXMF message bodies are end-to-end encrypted between sender and recipient identities using Reticulum's Token construction (X25519 ECDH + HKDF-SHA256 + AES-256-CBC + HMAC-SHA256, encrypt-then-MAC, HMAC verified before decrypt). Transport-node operators, RNode firmware, BLE eavesdroppers within range, and TCP middleboxes cannot read message contents. - Reticulum Link sessions use per-session ephemeral keys + LRPROOF Ed25519 signature verification before activation; per-packet PROOFs verify Ed25519 against the responder's long-term key (spec §6.5.1). Inbound LXMF signatures are verified against the sender's announced identity using the dual-msgpack-variant tolerance from §5.6. - Metadata is NOT encrypted. Destination hashes, announces, hop counts, and traffic timing are visible to any attached transport node and to anyone within radio range. The TCP transport section in Settings now spells this out explicitly before the user picks a node. The mesh is gossip-based by design; operators of a transport node you attach to can observe your destination hash, every announce you emit, and when you're online. - Inbound LXMF whose signature can't be verified yet (sender's announce hasn't arrived) is shown with an amber "Unverified sender" bubble and re-verified retroactively once the announce lands. If you prefer to drop unverified messages entirely, toggle "Drop unverified messages" in Settings → Privacy & security. At rest (on the phone) - Identity private keys (X25519 + Ed25519 + ratchet) on Android (v1.1.27+) are wrapped at rest with an Android Keystore-backed AES-256-GCM key — the database holds sealed ciphertext, not the raw bytes. See the dedicated Identity key protection at rest subsection below for what this does and doesn't protect against. On iOS the keys are still stored without per-app encryption (Secure Enclave vault is the next-session follow-up). - Android Auto Backup is disabled (android:allowBackup="false"). The identity DB does NOT flow through adb backup, Google Drive auto-backup, or seamless transfer to a new device. If you want a backup, use Settings → Export Identity, which produces a passphrase-encrypted .rmid file via PBKDF2-HMAC-SHA256 (600k iterations) + AES-256-CBC + HMAC. Export passphrases are gated by a strength meter — ≥12 chars with mixed character classes, or ≥20 chars of any kind. The crypto is solid, but anyone who has the .rmid file and the passphrase becomes you on the mesh forever, so pick accordingly. - iOS file protection is currently the SQLDelight default (NSFileProtectionCompleteUntilFirstUserAuthentication); a future tightening pass will move the DB to NSFileProtectionComplete. On Android, file-based encryption (FBE) under the device PIN/biometric protects the DB on a locked device. - Notifications hide message previews on the lockscreen by default (setVisibility(VISIBILITY_PRIVATE) + setPublicVersion); only "New message" / "Unverified message" surfaces until the device is unlocked. Identity key protection at rest Android (v1.1.27+): the three identity private keys (X25519 encryption, Ed25519 signing, ratchet) are wrapped with an Android Keystore-backed AES-256-GCM key. The wrapping key sits in the device's TEE (or StrongBox where available — Pixel 3+, recent Galaxy flagships, etc.) and cannot be cloned to another device. setUnlockedDeviceRequired(true) (API 28+) means a locked phone in a forensic kit can't decrypt the rows. The DB still holds the sealed BLOBs in app-private storage; an attacker who pulls the DB file off a stolen unlocked-or-rooted device gets ciphertext, not key bytes. What remains exposed: - Active malware on an unlocked or rooted device: can call the Keystore as the app's UID while the device is unlocked. Mitigated but not eliminated — the wrapping key is still in the TEE, so a clone-to-another-device attack fails, but in-process exfiltration via root + an active malicious process is still possible. - Biometric enrollment changes / Keystore reset / device wipe: invalidate the wrapping key. The app surfaces a clear error on next launch ("identity unrecoverable from this vault — re-import a .rmid backup or accept a new identity") rather than silently regenerating. iOS (current): uses a pass-through PlaintextIdentityVault. The SQLDelight default file-protection class (NSFileProtectionCompleteUntilFirstUserAuthentication) provides at-rest encryption with the device passcode, but no per-app key isolation. The Secure Enclave-backed iOS vault is the next-session follow-up; the wire format is identical so existing rows migrate cleanly when iOS gains its real vault. Impact if keys do leak is catastrophic and permanent: an attacker with your identity private keys can forge announces and LXMF messages indistinguishable from yours, and can decrypt every prior opportunistic-mode message you received. RNS identities don't rotate automatically. Recommendations: - Use a strong device PIN/passphrase + biometric. The Android Keystore key is bound to device-unlocked state, so this is your primary protection. - Don't run the app on rooted/jailbroken devices unless you understand and accept the in-process malware risk. - Keep .rmid exports in a password manager or encrypted vault, not in plaintext cloud storage. - iOS users with a targeted-threat model should wait for the Secure-Enclave follow-up before relying on this app for sensitive comms. Track progress in todo.md under "Security audit follow-ups → iOS vault". License GNU Affero General Public License v3.0