Member Avatar for Ghost0s

Someone explain(detailed) how the E2EE works please i googled for it but i didnt find something intresting or rich of informations :p

  • 2 Contributors
  • 4 Replies
  • 237 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by Ghost0s

Dani AI

Generated

Building on 's clear primer, the following fills the practical gaps most beginners hit when asking "how does E2EE work?" The short story is: E2EE solves key distribution and message confidentiality, but real systems add a few extra layers to make that secure and usable in the wild.

Key agreement and forward secrecy. Modern schemes use key‑agreement (for example Diffie‑Hellman and its elliptic‑curve variants) so both endpoints derive the same session key without sending it directly. Ephemeral keys (short‑lived keys) give forward secrecy: if a long‑term key is later compromised, past conversations remain unreadable. Asynchronous messaging systems layer a “double‑ratchet” so keys rotate per session and per message, limiting damage if a device is breached.

Trust and verification models. There isn’t just one way to trust a key: public‑key infrastructures (CAs), trust‑on‑first‑use (SSH style), and web‑of‑trust all exist. Practical verification methods are comparing short key fingerprints over an independent channel, scanning a QR code in person, or checking an app’s device list after an out‑of‑band confirmation. Certificate pinning and transparency systems reduce man‑in‑the‑middle risks for some uses.

What E2EE does not solve (and common caveats). E2EE protects content, not necessarily metadata (who talked to whom, timestamps, message sizes). It also fails if an endpoint is compromised or if backups store plaintext/server‑side keys. For real safety use audited libraries and well‑reviewed protocols, enable device verification, keep software updated, and verify fingerprints when a contact’s key changes. For debugging undecryptable messages: suspect a changed device key, corrupted message, clock skew, or mismatched app versions — re‑verify the peer’s fingerprint before accepting new keys.

This expands the basics asked by and ties back to ’s overview by showing the building blocks used in deployed E2EE systems.

Recommended Answers

All 4 Replies

Member Avatar for Hiroshe

What do you want to know about it? If you want to know how to use it, look into learning how to use openssl.

Member Avatar for Ghost0s

i wanna know how it works !

Edited by Ghost0s because: correcting
Member Avatar for Hiroshe

Well, it's a somewhat broad topic that can range from implementation details to mathematical proofs in number theory. How about I give you an overview, and then you can ask for the details that interest you?

One thing I will warn you: Do not implement your own cryptographic software or algorithms for production use! You'll regret it, unless your working with a team of mathematitions and computer scientists who understand how to prevent side channel attacks, and are willing to regurously inspect the code.

First I'll assume that you know how a symmetric cypher kind-of works. You give it plaintext and a password, and out pops the cyphertext. Then the other person can combine the password and the cyphertext to give back the plaintext. A little commic about AES can be found here.

End-to-end encryption is exactly what it sounds like; it's when one person encrypts a message, and it is not decrypted until it reaches it's destination (no matter the actual medium used).

A simple form would be that Alice and Bob pick a secret password, and all messages are encrypted before Alice sends a message and after Bob recieves it. An attacker Eve would not be able to see what Alice and Bob are talking about, even if she can see the cyphertext because she is still missing the password.

There is a small problem with this system. What if Alice and Bob haven't actually met in person to share a password (and all they have is an unsecure connection that is being tapped by Eve)? If Alice and Bob were to share the password over a public channel where Eve is listening in, then Eve will be able to decrypt the messages with the password!

That's where asymetric encryption come's in. There are various ways to do this, but one of the more famous examples would be RSA. The basic idea is that Alice generates a private and public key (and Bob does the same). Then then openly share their public keys (even if Eve see's the public keys). If Alice wanted to send a message to Bob, she would use Bob's public key to encrypt the message. The trick is that only Bob's private key can decrypt the message. Thus Eve (she has two public keys) does not have enough information to decrypt messages going either way.

(aside: RSA would generally be used to find a shared key, then AES would be used for the rest of the message. The reason is that it's hard to calculate RSA for large messages)

This is great... Except this system introduces a new flaw. Eve can pretend to be Alice and send a message using Bob's private key. Bob has no way of knowing that the message actually came from Alice (and Eve can set up a trap like "leave the goods in the forrest at midnight").

That's where signing comes in. In RSA, encryption and decryption are inverses of each other. So, Alice can compute a secure hash of the message and "decrypts" it using her private key, and send that with the message. Then Bob "encrypts" the hash with Alices public key giving the original hash and compairs it with the hash of the message sent. If the hash's match, then the person who sent the message must be Alice.

This is a lot better... Except there is still a problem. What if Eve is able to swap messages out with her own? Then when Alice and Bob trade public keys, she switches them with her public keys. Now when Alice think's she's talking to Bob she's really talking to Eve. And when Bob think's he's talking to Alice, he's really talking to Eve. This is called a "man-in-the-middle" attack (or MiTM).

This is where certificate authorities come in. When Alice and Bob install their operating system (which came on a physical disk that was not tampered with), the operating system comes with a list of public keys for some certificate authorities. Thus when Alice and Bob generate their keys, the submit the public keys to a certificate authority. If Alice want's to confirm that Bob's public key is not a forgery, she computes the hash of Bob's public key, and asks the certificate authority if it's legitimate. Eve is unable to make a forged public key, and is unable to MiTM the CA since the public keys were predefined on the operating system.

This is why when you send information to a website, you should be sure that the certificate is valid, and all information is being transferred through that connection (generally you can see it by clicking on the left of the address bar).

Member Avatar for Ghost0s

thanks man this is Gooood ^^

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.