Device-backed identity
Hashi creates dedicated authentication and encryption key material through Android Keystore so private key material is not handled as ordinary plaintext app data.
SECURITY
Layered security from device identity to backend admission.
This page summarizes public-facing security properties. It intentionally omits internal endpoints, infrastructure addresses, operational thresholds and secret-bearing configuration.
E2EE V2 for messages and media keys
Hashi's V2 envelope uses RSA-3072 identity keys, RSA-OAEP key wrapping and AES-256-GCM authenticated encryption with metadata binding.
Contact identity change detection
Trusted contact identity baselines are stored locally. A later key change is not silently accepted as the same identity and can require explicit user approval.
Authenticated encrypted media chunks
Fresh media uses per-file AES keys and authenticated chunk encryption so progressive transfer can preserve confidentiality and integrity chunk by chunk.
Encrypted local stores
Chat history/topics, identity seed, tasks, message-filter configuration, contact cache, call logs and other sensitive stores use Keystore-backed AES-GCM protection in the Android client.
Short-lived authenticated sessions
Protected API access is established through signed device challenges and short-lived authenticated sessions rather than a permanently embedded account password.
Backend abuse and capacity protection
The production backend applies per-account/device controls, aggregate-source limits and serialized realtime-capacity admission so abusive account creation cannot simply multiply available backend capacity.
Production relay infrastructure
WebRTC can use production coturn relay infrastructure with short-lived server-issued credentials when direct connectivity requires a relay.