Encrypted message architecture
Messages are protected using a modern session and message encryption model built around Ed25519, X25519, AES-256-GCM, and HKDF-SHA256.
Security and Privacy
Privacy is part of the architecture.
Across the ELM ecosystem, security and privacy are not treated as surface-level claims. They are built into communication, media handling, trust architecture, server-side protection, and the wider technical structure behind the platform.
Overview
Security and privacy by design.
ELM is designed as a secure communication environment for people, systems, AI, and connected infrastructure. That means privacy is not limited to one feature or one screen. It affects how identity is handled, how sessions are established, how messages and media are protected, how data is stored, and how platform trust is structured over time.
ELM reflects that directly through encrypted communication, encrypted voice, encrypted media support, encrypted server-side data handling, and additional user controls such as chat locking and more granular control over notifications and visibility.
Two-step protection, already on
Protected from the start—without another setting to remember.
ELM's own two-step sign-in protection is enabled by default. When a new device needs confirmation, ELM first checks that another compatible, signed-in device has been active recently. An old device record or forgotten installation is not enough to trigger the approval step.
The result is practical account protection with less setup: ELM uses a device you are actively using to help confirm a new one, while avoiding dependence on stale installations.
Encryption
Modern cryptography across identity, sessions, and messages.
ELM is designed with a modern cryptographic model for identity, session setup, and protected private-message transport.
The current architecture includes:
Identity key: Ed25519
Prekeys and session setup: X25519
Message encryption: AES-256-GCM
Key derivation: HKDF-SHA256
In practical terms, this means the platform uses modern 256-bit elliptic-curve cryptography for identity and session establishment, authenticated 256-bit symmetric encryption for protected message payloads, and standard secure key derivation for session material.
End-to-end encryption, shown simply
Readable to the people in the conversation—not the route between them.
In a private ELM conversation, the sender's device establishes a verified session and encrypts the message before it is sent. ELM's European relay infrastructure moves the encrypted payload to the recipient; the recipient's device decrypts it. Tap each stage for the technical detail.
E2EE applies to supported private communication surfaces. Public posts and content intentionally shared to an audience are governed by that audience setting; they are not described as private end-to-end encrypted chats.
Media protection
Messages are not the only thing protected.
Media handling is also part of the wider privacy model. ELM supports encrypted media handling and encrypted server-side storage, helping extend protection beyond plain text messages alone.
That matters because communication privacy is not only about the message body. Images, files, and other media can reveal just as much — sometimes more — if they are not handled carefully.
Server-side protection
Data stored with stronger protection.
Data protection inside the ELM ecosystem is not treated as a client-only story. Data stored on the server side is also handled with encryption and structured protection in mind.
This includes encrypted handling of messaging-related data and encrypted server-side storage for protected platform data where applicable. The goal is to reduce unnecessary exposure of communication content and related information inside the wider system.
Privacy in practice
What privacy means here.
Privacy in ELM is intended to mean more than simply adding the word “secure” to a product page. In practice, it means designing the system so that communication, media, and access patterns are handled with stronger protection and more deliberate boundaries.
That includes encrypted transport, stronger handling of stored data, controlled product separation between social and messaging layers, user controls such as chat locking and quiet controls, and a wider trust architecture intended to reduce exposure rather than normalise it.
Security features
Encrypted voice
Voice is part of the protected communication model and is built into ELM as part of the wider encrypted communication environment.
Encrypted media support
Media handling is included as part of the wider privacy architecture rather than being treated as a separate weak point.
Encrypted server-side data
Stored platform data is handled with stronger server-side protection in mind, not as plain exposed application data by default.
Chat locking
Users can lock chats for stronger personal privacy, adding a practical user-side protection layer.
Two-step sign-in by default
New-device approval is on from the beginning and relies on another compatible, recently active signed-in device, so stronger account protection does not depend on remembering to enable it later.
Trust architecture
Security is not only technical encryption. It also includes how trust, access, visibility, and platform boundaries are designed across the wider ecosystem.
Logging
What is logged.
Like most serious platforms, ELM may keep operational and security-related logs needed to maintain service stability, diagnose issues, detect abuse, and protect the wider environment.
Depending on the system layer involved, this can include things such as:
Service and error logs for diagnosing platform issues
Security and access events used to detect abuse, failures, or unusual behaviour
Server and infrastructure logs needed for uptime, routing, and operational monitoring
Limited technical metadata required for delivery, performance, and protection
These logs exist to support security, stability, debugging, and service operation. They are not intended to act as a direct record of a person’s private identity.
Retention
How logs are handled.
Log handling can vary depending on the system layer involved and the operational purpose behind it. Service, security, and infrastructure logs may be kept for different periods depending on what is required for platform stability, issue diagnosis, abuse prevention, and service protection.
These logs are primarily used for operational, technical, and security purposes. They are not intended to function as a direct profile of a user’s personal identity.
In practice, logging is focused on keeping the platform running safely, identifying faults, detecting abuse, and supporting infrastructure integrity rather than building a behavioural or personal surveillance record.
What this is not
Not a platform built around harvesting user behaviour.
ELM is not intended to operate like a surveillance-led product where user behaviour is the primary asset. Security logging and operational logging exist to keep the platform functioning, detect abuse, and protect the environment — not to turn normal communication into a monetised monitoring layer.
How it fits
Part of the wider ELM environment.
Security and privacy are part of the wider ELM architecture, not just one messaging screen. They support messaging, voice, media, business use, creator interactions, spaces, and the wider communication environment behind ELM HQ.
That is also why the infrastructure layer matters. Security is not only a feature of the visible app. It is a property of the wider platform design.
Privacy should be part of the system itself, not added later as a slogan.