SendMeSafe
Registrieren
Security & Engineering

Security you can verify.

A security-first platform with layered protection: TLS 1.3 in transit, encrypted storage at rest, and optional end-to-end encryption for Connect and Messenger. Learn how the mechanisms work, what we protect, and where the trust boundaries are.

Get started freeTechnical documentation
TLS 1.3
Encrypted at rest
Optional E2E
bcrypt hashing
EU hosting
Audit trail

Threat Model Simulator

Pick a product surface and an attacker. See what is visible and why.

What can the attacker see?
Readable content: No
Can tamper: No
Link/participants visible: Yes
Scenario
Typical: public WiFi, corporate proxy, compromised router. TLS is the relevant layer here.
In short
For share links, the decryption key can live in the URL fragment (#). Browsers do not send fragments to servers. A server-only attacker does not get the key. Whoever has the full link (including fragment) can decrypt.
Content (payload)
Ciphertext
Metadata
Visible
Key material
Server-side

Security Matrix

A single overview: which security layers apply to which product area. Expand a row to see the concrete mechanisms.

Select a row
TLS
At rest
E2E
Optional
Password
Optional
Expiry/limits
Optional
Audit
Optional
  • Optional password protection is stored hashed (bcrypt).
  • Expiry dates and download limits reduce long-lived risk.
  • Optional: decryption key can live in the URL fragment (#) and is not sent to the server.
Feature pageEncryption docs
TLS
At rest
E2E
Optional
Password
Optional
Expiry/limits
Optional
Audit
Optional
TLS
At rest
E2E
Optional
Password
Optional
Expiry/limits
Optional
Audit
Optional
TLS
At rest
E2E
Optional
Password
Optional
Expiry/limits
Optional
Audit
TLS
At rest
E2E
Optional
Password
Optional
Expiry/limits
Audit
Optional
TLS
At rest
E2E
Optional
Password
Expiry/limits
Audit
Optional

End-to-end encryption simulation (TLS vs E2E)

Compare TLS-only and end-to-end encryption (E2E). See what the server can process and what stays encrypted.

Your message
Alice pub
...
Bob pub
...
Shared secret (derived)
...
Shared secrets match: ...E2E means: plaintext never reaches the server. The server transports ciphertext only.
This simulation uses real primitives: X25519 (ECDH) + NaCl Secretbox (XSalsa20-Poly1305). The UI is simplified.
Attacker perspective
Even if the server is compromised, it cannot decrypt E2E payloads without endpoint keys.
What the server sees
Nonce
...
Ciphertext
...
Without the private key, decryption is not possible.
What the recipient sees
Decrypted
...
Click "Next step" or start the simulation to see decryption.

How encryption works (quick course)

A short, practical explainer. Light on math, clear on trust boundaries.

Trust boundaries
Key exchange (ECDH)
Two parties derive the same shared secret.
Explainer
Key points
  • Each user has a key pair (public + private).
  • Shared secret is derived from private+public (X25519).
  • Server can transport ciphertext without being able to decrypt.
Pseudo-code
shared = X25519(sender_private, recipient_public)
ciphertext = secretbox(message, nonce, shared)
recipient derives same shared secret to decrypt
This is the basis for Messenger E2E: X25519 + Secretbox (XSalsa20-Poly1305).

Further details

Explore the technical documentation and related feature pages.

Encryption details
Crypto primitives, E2E, key handling, storage model.
Learn more
GDPR & compliance
Data processing, retention, and EU hosting context.
Learn more
Audit trail
Visibility into downloads and security-relevant actions.
Learn more
Share Links
Passwords, expiries, limits, and share-key patterns.
Learn more