OSDev.org

The messenger app says in its settings that "conversations are end-to-end encrypted on all devices at the same time".

well, if i start a conversation on my phone, then log in through a laptop, how would the laptop be able to "end-to-end" encrypt and decrypt that conversation? how would this laptop know the key if it's really end-to-end encrypted?

Meet Moxie Marlinspike, the Anarchist Bringing Encryption to All of Us.

His protocol is also used by Facebook messenger. The article comes with a description of the handshake. It's a rehash of the public key / message key scheme that's been with us (at least) since PGP appeared in 1991... (Funny enough that media still makes it sound like some new discovery.)

Public key cryptography is used to exchange a shared session / call / message key, which only the people in possession of the respective secret keys could have access to.

Public key cryptography works by having key pairs. Anything encrypted with one of them can only be decrypted with the corresponding other key. One of them is "public", i.e. available to anyone. The other is (hopefully) "secret".

There are various ways to double-check identity -- web of thrust, fingerprint publication etc. -- and I don't know exactly how the Facebook Messenger works, but that's the general idea of it.

I don't know what magic inside, but when you have private key on terminal A, and magically able to decode message on terminal B, it suggest something going on.
Maybe some security is traded for convenience (like passing key from A to B via server, but that is really scaring even with extra layer of DH between A & B, and I don't think it can pass audit as it subject to MiTM attack by server).

If someone can explain the magic I'll be really happy to learn.

I haven't really understood where the disbelief comes from.

The public / private key is only used to agree on the message / session / call key. That one is shared. (As public / private key algorithms tend to be computationally heavy, while shared-key encryption can easily be done on-the-fly.)

@solar, Yes the private key (ECDH or RSA) is used to initiate session, the message itself will be encrypted with a rolling AES key.

However, to enable multiple terminal to decrypt the same message, you have to transport the root private key from A to B. As getting the private key is the only way to deduce AES key (in theory).

However there is no way you can transport a key without risking MiTM. Maybe the server is trusted in such scenario, its not for militarily anyway, it's for marketing to get a checkbox.

DISCLAIMER: I don't know how FB does things. I'm extrapolating from my own knowledge of security protocols here.

bluemoon wrote:However, to enable multiple terminal to decrypt the same message, you have to transport the root private key from A to B. As getting the private key is the only way to deduce AES key (in theory).

However there is no way you can transport a key without risking MiTM. Maybe the server is trusted in such scenario.

Having the server / user account hold the "secret" key is one way to do it, yes. It's probably what's being done.

The alternative would be to have a secret key on each device, and merely using the active FB login to encode some little "secret". Like, yes, the holder of this secret key is also legitimately logged in to this Facebook account, so please share {shared key} with me so I can participate.

(End-to-end encryption doesn't mean ONE end to ONE end, it just means that the message remains encrypted until received.)

That would only be marginally more secure than having the server hold the secret key, though. After all, you want anybody able to log in to your Facebook account to send / receive messages, as logging in to Facebook should only be possible to you. Nobody else has the password, right?

Right?

(WhatsApp, for example, does allow to authenticate a webbrowser to use web.whatsapp.com -- but only after you authenticated the browser's access with your phone via QR code. And you can always revoke that permission from your phone.)

If that is not enough security for you... there's always PGP / GnuPG. Encode the message with the recipient's public key and send *that* over FB messenger.... or mail... or {whatever}.

Or, even better, use a one-time pad. That one's not crackable; of course you have to rely on some means of sharing the pad and keeping it between the two of you...

It's sad that the whole purpose of end-to-end encryption is prevent server (and gov agency) from seeing what's transferred. And they DO have your password.
The whole thing look more of marketing hype to me now.

In the end, unless you have personally scanned and evaluated the source or personally handed over the one-time pad, you have to trust somebody.

Although I will freely admit that I wouldn't give a rat's backside about the security offered as "built-in" by WhatsApp, Facebook, Skype or the like.

If you want to hide something, use separate security software trusted in its own right (i.e., PGP et al.). Actually, even if you don't have something to hide, you should use them (so the "big 'uns" get drowned in encrypted noise).

Unfortunately, as I have found out myself, in the end we're usually too lazy to really care.

bluemoon wrote:It's sad that the whole purpose of end-to-end encryption is prevent server (and gov agency) from seeing what's transferred. And they DO have your password.
The whole thing look more of marketing hype to me now.

Yes, that was the point I was initially making; that as I see it, there is no difference between facebook "end-to-end encryption" vs simply trusting the server.

mariuszp wrote:

bluemoon wrote:And they DO have your password.

...as I see it, there is no difference between facebook "end-to-end encryption" vs simply trusting the server.

Actually, they should not have your password. They should have a cryptographic hash of your password...

Solar wrote:

mariuszp wrote:

bluemoon wrote:And they DO have your password.

...as I see it, there is no difference between facebook "end-to-end encryption" vs simply trusting the server.

Actually, they should not have your password. They should have a cryptographic hash of your password...

It depends on which hashing is in use. md5 has long since obsoleted.
Most system still use SHA1 which is easily crackable with modern GPU. even with strong SHA256/SHA512, the fact that server itself can bypass any security measure and is free to perform brute force over some dictionaries definitely has advantage and can recover most people password.

By the way, for all intent and purpose I was referring to the hashed password, which is (supposedly) used for key transport.