A Simple Way To Check If Your "Private" Messenger Vendor Is Lying About End-To-End Encryption

TL;DR: Send an encrypted message to some offline user. If the user gets it - that’s a copy, meaning the message was in static state on some server.  

Some things ought not to be laughed at, right?

When the job is done poorly, people may get hurt. If some private messenger comes out being not-so-secure, users get in a very uncomfortable position. 

They trust their money and data, and then one day it all doesn’t matter anymore, because someone decided to stop the task without taking the extra steps to complete it to a high-quality standard, basically achieving something “close enough for government work”.

As They Say, You Can’t Be Half Pregnant

You are either all the way in, or you’re not.

That concerns security first and foremost, because when the solution is not addressing all the potential risks and when it covers only one side of the problem - it’s close, but it gets no cigar.

There’s no need to look very long for telling examples. 

As you may know, messengers, secure or not in their positioning, widely adopted end-to-end encryption and started throwing the term around without even understanding what it means or how it works.

Most messengers supposedly use end-to-end encryption but are still not immune to third party eavesdropping involvement (man-in-the-middle attacks). Most messengers use basic encryption (SSL/TLS protocols) to transfer keys saved on the server instead of generating them with the help of key derivation function (KDF).

KDF rules out encryption key interception.

With this function, keys are generated and never transferred outside your device like in consumer-grade messengers that use external Encryption Key Server.  

There’s nothing worse than waking up from the false sense of security by stepping on the mine you were lucky enough to avoid a couple of times before. 

To save you from that false sense, I will show you an easy method to identify if your messenger vendor is lying about end-to-end encryption. 

“Offline And A No-Show” Method You Can Try Even Now

For this to work, we will need a friend who has the same messenger as you. 

Tell him or her to go offline for a second, then send them a message. If your friend gets a message when reappearing online, then it is a copy. So it was stored online somewhere by a third-party, from which it was retrieved by the recipient. 

It is possible the two of you are not the only ones reading it. Meaning it stops being end-to-end secure.

Of course, for such peer-to-peer to work, both people have to be online, and this causes some friction - catching people online is not easy most of the time. A lot of problems can break out thanks to this detail. 

For example, you could send a message, but the person wouldn’t get it, and there most certainly would be some kind of misunderstanding.

So how did serverless StealthTalk abstain from this peer-to-peer difficulty and resolved the issue safely, without having to store “offline” messages on servers?

How To Deliver Messages Stealth-Style?

Well, your message gets encrypted, then broken up in parts that will be traveling between a random set of nodes in the Secure Dynamic Network Protocol cloud, waiting for the recipient to appear online. 

This way encoded parts of your message are never static, and they can not be tied down to each other thanks to StealthTalk’s decentralized model. The message can only be deciphered by your or your recipient’s device.

And while we are at it, why not try StealthTalk today? The 30-day free trial do not call for any commitments. You can download and install StealthTalk here, in case your friends will ask you for a link:

Stay safe!