End-to-end encryption E2EE — केवल endpoints कुंजियाँ रखते हैं
The encryption property where even the server in the middle of the conversation cannot read the message.
एक क्रिप्टोग्राफिक विशेषता जिसमें डेटा प्रेषक के यहाँ एन्क्रिप्ट होता है और केवल इच्छित प्राप्तकर्ता के यहाँ डिक्रिप्ट होता है, और कोई भी मध्यवर्ती पक्ष — जिसमें संदेश रिले करने वाला सर्वर भी शामिल है — कभी भी decryption key नहीं रखता। यह transport encryption (TLS) से अलग है, जिसमें प्राप्त सर्वर का ऑपरेटर TLS layer समाप्त होने के बाद plaintext पढ़ सकता है। इसे Signal protocol, OpenPGP, Matrix Olm/Megolm suite और कुछ अन्य प्रणालियों द्वारा लागू किया जाता है।
एक होस्टिंग प्लेटफ़ॉर्म E2EE को सक्षम कर सकता है, प्रदान नहीं।
End-to-end encryption is a property of a communication system between two endpoints — a chat app, a backup tool, an email client. A hosting platform is not itself an endpoint, so it cannot directly "be" E2EE the way Signal is. What a hosting platform can do is make sure that customer workloads which want E2EE have everything they need to deliver it, and that the platform itself does not surreptitiously become a third endpoint that can read user data.
That is exactly the operational stance we take. Self-host a Matrix homeserver, a Conduwuit/Synapse stack or an XMPP server on a NordBastion VPS and the user-visible cryptography is end-to-end between clients — the VPS only relays ciphertext. Self-host a Restic, Borg or Kopia backup target and the data is encrypted on the client before it ever touches our disks. Self-host a Mumble, Jitsi or SimpleX deployment and we never see the plaintext stream.
The corollary on our own customer-facing services: we use TLS (not E2EE) for the panel and API, because the panel actually has to read your requests to fulfil them. What we substitute for E2EE there is data minimisation — we collect almost nothing, hash what we must store, and retain payment metadata only for accounting. That is the honest answer; it is not the same property as E2EE, and we do not pretend otherwise.
The pages that lean on this term.
The questions people actually ask.
How is E2EE different from HTTPS?
HTTPS uses TLS to encrypt the link between your browser and the server. Once the request reaches the server, the operator of that server sees the plaintext — that is how the server can do its job. End-to-end encryption means the server never sees the plaintext: the message is encrypted on the sender's device for the recipient's key, and only the recipient can decrypt it. HTTPS protects the wire; E2EE protects the content from the host as well.
Is NordBastion itself end-to-end encrypted?
NordBastion is a hosting platform, not a messaging app — the concept does not apply directly to most of what we operate. The customer panel, the API and the marketing site use TLS, not E2EE, because the server has to read your requests to fulfil them. What we do is minimise what the server stores in the clear: passwords are hashed with argon2id, payment details are not retained beyond the period needed for accounting, and the per-customer datastore is structured so that a database breach reveals as little as possible.
What does E2EE mean for customer workloads on a VPS?
It is something you can implement on top of the platform. A chat application you self-host on a NordBastion VPS can perfectly well be end-to-end encrypted — the VPS sees only ciphertext flowing between users' devices. An end-to-end-encrypted backup tool (restic, borg, kopia) encrypts data on the client and pushes ciphertext to S3-compatible storage on a NordBastion node, with the key never leaving the operator's hands.
क्या E2EE की सुरक्षा की औपचारिक सीमाएँ हैं?
Yes. E2EE protects content. It does not, by itself, hide metadata: who is talking to whom, when, how often, from which IP. Most modern E2EE designs (Signal, Matrix) add additional measures — sealed sender, padding, mixnets — to chip away at metadata leakage, but none of them give the absolute privacy property that content gets. A privacy-aware stack combines E2EE for content with Tor or a self-hosted VPN for network-layer metadata.