Protection and verification
Security
How InTouch protects communications, what has been confirmed in the implementation, and where each protection ends.
Reviewed · English reference text
What “confirmed” means here
These details were checked against the local InTouch product source and security documentation. Source review confirms that a mechanism exists in the reviewed implementation. Its availability and effectiveness in your installation depend on the app version, build features, configuration and operation. This is not an independent audit or a verification of a live deployment.
Implemented in the cryptographic core
End-to-end encrypted content
The core implements AES-256-GCM authenticated encryption, a Double Ratchet and a hybrid X3DH handshake. Protected messages are encrypted at participant endpoints. The relay handles ciphertext and public verification material; it does not need plaintext or participant decryption keys to deliver protected content.
Authentication tags are verified before the receive ratchet state is committed. Rejected ciphertext does not advance the receive chain. Forward secrecy and recovery after a compromise depend on correct key erasure, fresh exchanges and secure endpoints; they do not erase plaintext already stored or copied.
Implemented · algorithm versions matter
Classical and post-quantum cryptography
Identity material includes Ed25519 and CRYSTALS-Dilithium5 signatures, with X25519 and CRYSTALS-Kyber1024 key exchange material. Hybrid session and asymmetric ratchet operations combine classical and post-quantum secrets using HKDF-SHA-512.
The reviewed dependencies select the CRYSTALS round-3 Kyber1024 and Dilithium5 implementations. These are distinct from the final FIPS ML-KEM and ML-DSA standards, even where internal comments use the newer names. This page makes no claim of FIPS validation, certification or compatibility. Published primitives do not by themselves establish that their composition or implementation has been independently audited.
Implemented in the core and transparency client
Key transparency and identity verification
Key transparency uses Merkle-tree inclusion and consistency proofs and signed tree heads. The client checks that a presented history extends its pinned history. Safety numbers give participants a separate way to compare identities through a trusted channel.
A signed tree head alone does not prove an honest history: the relay holds its signing key. Consistency checks protect against a rewritten history relative to a pinned root; comparison between independent observers is needed to expose separate, internally consistent views. Verification depends on clients and auditors actually performing these checks.
Implemented · requires the relevant MLS features
Space membership and group keys
Group encryption uses OpenMLS and RFC 9420. The InTouch hybrid extension binds a post-quantum signing identity to the member’s MLS leaf key and contributes a hybrid shared secret through an external pre-shared key. Participants maintain separate MLS key stores.
The strict hybrid checks are controlled by the mls_hybrid_strict build feature, which is not enabled by the core’s default feature set. Confirm the features in your deployed build before relying on hybrid group protection. Removing a member and advancing group keys protects future content under the updated state; it cannot revoke copies or keys already obtained.
Implemented · padding depends on sender configuration
Sealed sender and traffic metadata
Sealed-sender encryption protects the inner payload and reduces sender information exposed in the delivery envelope. The core accepts both unpadded and length-padded wire formats. The metadata_padding feature controls whether senders emit padded messages.
Metadata is reduced, not eliminated. Delivery still involves recipient routing, network connections, timing and traffic volume. Unpadded messages expose more size information, and padding does not remove all correlation risks. End-to-end encryption is not a promise of anonymity or an absence of personal data processing.
Implemented in the cryptographic core
Encrypted backups and recovery
Backup protection derives encryption material through Argon2id and HKDF and uses AES-GCM. Recovery validates the envelope’s key-derivation parameters against bounds to resist excessive resource consumption and weakened work factors.
Recovery still depends on the correct recovery secret and the available backup. Keep credentials and recovery material secure and test your recovery process. Neither encrypted backup support nor the relay’s inability to decrypt content guarantees that lost keys or deleted content can be recovered.
Implemented · require signature version 2 in production
Signed requests and replay protection
Authenticated request signing uses Ed25519, timestamps and nonces. Version 2 binds the signing identity, HTTP method, path and query, and a SHA-256 digest of the body. Nonces are recorded after successful signature verification and scoped to the account.
The relay supports legacy version 1 during migration. Deployments must require version 2 to obtain method and target binding; supporting version 2 is insufficient if legacy requests remain accepted. Identity-provider integration and access-control services also require the appropriate deployment configuration.
Implemented checks · production settings require verification
Deployment safeguards
The API contains startup checks for explicit allowed browser origins, outbound destinations, contact-discovery secret material, identity-provider configuration and key-transparency signing material in staging and production. Its security model includes integration with self-hosted identity and relationship-based authorisation services.
These controls depend on the selected features, environment and running configuration. Operators remain responsible for HTTPS, infrastructure access, secret management, updates, monitoring and backups. A repository configuration check does not demonstrate that a particular hosted or self-hosted installation is correctly configured.
Server implementation confirmed · release availability unverified
Private contact discovery
The current API source contains an OPRF implementation using ristretto255 through the voprf library. The oprf feature is enabled by default, and the configuration rejects non-development builds without it. This provides server-side implementation evidence for blinded contact discovery.
Client integration, release availability and the configuration of a live deployment have not been established by this review. Earlier website copy describes the feature as unshipped. Do not assume that a contact-discovery feature in a particular app uses this protection until its version and end-to-end behaviour are verified.
Agent tooling and audit recording implemented
Agents and connected AI providers
Agents are identifiable participants whose access depends on membership and permissions. The API’s MCP tool-call path includes audit-event recording and argument redaction. An authorised agent can read the information made available to its endpoint.
Review permissions and audit configuration for your deployment. Redaction is a control, not a guarantee that all sensitive information is removed. If an agent sends content to an external model or tool, that provider may process the plaintext under its own terms. Use appropriate approval controls for consequential actions; encryption does not make AI output accurate or safe.
Core source restriction confirmed · independent audit unverified
Memory safety and verification
The Rust intouch-core crate forbids unsafe code within that crate. The repository includes tests for ratchet behaviour, group encryption and hybrid membership, and its security policy documents threat assumptions and protocol invariants.
The restriction does not establish that every dependency or foreign-function interface is free of unsafe code. Test presence is not evidence that every test passed for the deployed build. No completed independent audit, penetration-test report, certification or production security assessment was verified for this page.
Part of the security model
The limits of these protections
Encryption cannot protect content from an authorised recipient, an unlocked or compromised endpoint, stolen usable credentials, a malicious integration or an agent with excessive permissions. Identity verification does not prove a participant’s honesty or authority.
Keep devices and applications updated, verify important identities through another trusted channel, restrict membership and agent access, preserve recovery material, and review your deployment’s settings. Organisations determine their own retention and regulatory obligations. Security mechanisms alone do not establish compliance with a law or industry framework.
Report a security concern
Contact hello@elementary.mu and identify your message as a security report. Include the affected version, a description and safe reproduction steps. Do not send passwords, private keys, recovery secrets or other people’s private communications. Request a secure channel before sharing sensitive evidence.