Participants and devices
A recipient, modified client or malware on a signed-in device can copy readable content and available keys. No interface lock or verification bot can make an untrusted endpoint safe.
Security
Encryption, without the shortcuts.
Your password signs you in. Message keys unlock conversations. Those are different jobs. Here is how VaultSec separates them, what the server still sees and what we are still checking.
This describes the implemented message path. It is not an independent audit certificate, a promise of total anonymity or a guarantee for calls, bots and every future feature.
Not one key for everything. ↓What you share should stay with the people you choose.
Family photos, personal plans and confidential work all find their way into chats. End-to-end encryption protects the message content on its way to the receiving devices: the service delivers encrypted data without needing the readable conversation. That reduces how much private content you have to entrust to a provider.
Personal life, business and public responsibility.
Business owners, companies and independent professionals need discretion around negotiations, client matters and internal plans. Politicians and people working in public life also have legitimate reasons for confidential conversations. The same principle applies to everyone: privacy should not depend on a job title. VaultSec aims to support that need; suitability for particularly sensitive work must be assessed against its documented beta limitations and the risks involved.
Choose security you can understand: where keys live, who can read content and what happens when a device is lost. Encryption is an important part of that protection. Device verification, updates and careful handling of saved copies remain necessary; encrypted content does not mean invisible connection metadata.
From your device to theirs.
MESSAGE ENCRYPTION
01 / YOUR DEVICE
“See you soon!”
Encrypt locallyMessage keys are used here.02 / SERVER
Encrypted content
Cannot read the messageNo usable message key.03 / RECEIVING DEVICE
Encrypted content
Read with the matching keyDecryption happens on the device.The message becomes ciphertext before leaving your device.
The important difference: the server never gets the readable message. Even access to stored encrypted message content is not enough to read it without the matching keys. This protects content — it does not make compromised devices safe or erase copies saved by recipients.
Illustration of encrypted messages, not a live transmission. Delivery metadata such as room membership and timing remains visible to the service. Keys are exchanged in encrypted form; device trust matters. Calls use a separate media-encryption path. Details and limits →
Not one key for everything.
| Credential or key | Where it belongs | What it does — and does not do |
|---|---|---|
| Account password | Entered by you; checked by the account service over TLS. | Authenticates your login. It is not the room key. Password checks are not end-to-end encrypted messages: the login service processes your password. |
| Device identity keys | Private parts on the device; public parts are shared. | Identify a Matrix device and help establish encrypted key exchange. A public device key cannot by itself decrypt the conversation. |
| Message-session keys | Created and used by participant devices; exchanged in encrypted form. | Decrypt messages belonging to an encryption session. This is not one permanent master key for an entire community. |
| Attachment keys | Generated on upload; decryption information travels inside the encrypted message. | Protect file contents before server storage. Recipients can still save readable copies; encryption is not malware scanning. |
| Local storage key | Used by the device crypto store. Remembered session data uses Windows-protected storage. | Protects local key storage. The remembered session does not contain your account password. Malware running as you can still compromise a signed-in device. |
| Legacy download code | Used during the invitation-only phase; no longer required for the open Desktop beta. | Was used to authorise a download. It is not a message key and cannot decrypt chats or recover missing history. |
From your device to theirs.
1. Encrypt on the sending device
The client checks that room encryption is active before sending content. The Matrix crypto implementation encrypts the message locally.
2. Deliver encrypted data
The server stores or forwards ciphertext and delivery metadata. It can also carry encrypted key-exchange messages; that does not give it usable private keys.
3. Decrypt on a receiving device
A participant device with the matching session key can read the content. Without that key, receiving the encrypted event is not enough.
A login is not device verification.
Verification compares cryptographic identities, for example using matching emoji or numbers. Compare both screens through a trusted channel and reject mismatches. A device name, avatar or successful login is not proof of a trustworthy device.
Key distribution also depends on the client and its trust settings. An encrypted room does not automatically mean that every receiving device has been manually verified.
What if you lose a device?
Revoke a lost device from one you still control. Revocation cannot erase keys, screenshots or files already copied elsewhere. If no accessible device holds the needed keys and no usable encrypted backup exists, the account password cannot recreate them.
Which technical data is still needed.
You choose what you share.
No email address or real name is required to register. Choose a username and password in the app. Public profiles, community names and information you send to other people remain your choice.
Message bodies and encrypted files are protected by the message keys. Account and device identifiers, room names, membership, timing and traffic sizes can still be processed for delivery or operation. Do not put secrets in community or channel names.
The current Desktop delivery path replaces source IP addresses with short-lived pseudonymous identifiers before they reach the message server. Registration abuse checks also use temporary keyed identifiers instead of keeping raw IP addresses. This reduces retained connection data; it is not total anonymity. Your internet provider and the hosting services in front of VaultSec can still process connection IPs. Older backups or provider logs may retain historical data.
Planned for a future update: an optional proxy setting. Not available in the current release. A proxy alone does not guarantee anonymity; supported connections will be documented when it is released.
Where this protection ends.
Calls use a separate media path
Voice, video and screen sharing are already encrypted in the beta using WebRTC DTLS-SRTP, with traffic forced through a TURN relay. Group-call control data is also exchanged through encrypted Matrix events. Device verification remains optional; encrypted transport alone does not authenticate an unverified participant device. Cross-network audio and screen-sharing tests remain open.
Bots and integrations
A bot is a participant or service with specific permissions. If it receives readable content, it becomes a trusted recipient. A CAPTCHA can slow automation; it cannot prove every user is human.
Signed updates are a separate check
An update signature checks approval by the signing-key holder, not freedom from bugs. SHA-256 checks file consistency, not the trustworthiness of a compromised website.
Next privacy improvements.
Planned for upcoming updates, not released capabilities. The exact scope will be published after implementation and testing.
Review key rotation and deletion together
Matrix already provides session rotation. We plan to test and document VaultSec’s rotation behaviour, review shorter session lifetimes and improve cleanup of local caches and decrypted attachments. A new key per message alone would not guarantee deletion of existing copies.
Emergency lock and local cleanup
Planned: lock the app immediately, revoke sessions when reachable, and offer a separate, clearly confirmed cleanup of local VaultSec data and keys. Optional removal of identified VaultSec downloads and related browser entries needs separate review and consent; never a blanket wipe of unrelated files or browsing history.
Encrypted backups: removing access instead of every copy
We plan to assess cryptographic erasure for data managed by VaultSec. With correctly encrypted data, permanently removing every usable decryption key can make even a retained encrypted backup unreadable. This requires a verified key lifecycle that also covers key copies, recovery keys and other recovery paths. It is not a released capability or a guarantee that existing backups already meet these requirements.
Not a promise of “no traces”: operating-system records, SSD storage, backups and copies outside the app cannot be guaranteed to disappear. Uninstalling the app and cleaning its data are separate actions. Removing keys can make your own history permanently unreadable.
06 September 2026
What this explanation is based on.
VaultSec uses the Matrix SDK and its Rust crypto implementation, with Megolm encrypted-room events and encrypted attachments. Local tests cover encryption gates, storage protection and negative device-verification cases. They do not replace an independent audit or authenticated tests of every deployed component.
Independent security audit: not claimed. Old-history recovery and real-world media tests: still open.
Report security issues without sending passwords, private keys or message contents.
Support →Private does not mean a free pass for illegal use.
Use your community freely within the law. Illegal activity is prohibited. When substantiated violations become known, VaultSec may restrict, suspend or delete the affected accounts and communities.
Reports or otherwise available evidence can make a violation known. This does not require general access to encrypted private conversations. Moderation does not create a backdoor or erase copies already held by recipients.
For a report, contact support with the issue category first. Do not send passwords, room keys or unnecessary private content.
Support →