I’m not going to do full protocol analysis for proprietary products with bad documentation. Here are some immediate thoughts based on content on their web page.

“We implemented most recent achievements and cutting-edge technologies in information technology security to develop cryptographic protection mechanisms for our instant messenger.”

Cutting edge is hardly the word when messags are signed with ECDSA: it lacks deniability.

“The level of encryption and its performance meets the most stringent banking standards.”

Marketing (Stef #6: uses marketing-terminology like “cyber”, “military-grade”)

“Your private or business information is totally safe and confidential when using our chat messenger”

Misleading marketing. Implicates lack of threat model.

“In case the user does not trust the cryptographic service provider”

I think this is supposed to say IM server, not cryptographic service provider; it’s the assumption user can trust the cryptographic services provided by Safeum.

“P2P mode which eliminates the technical possibility of interception”

It absolutely doesn’t. It only bypasses Safeum servers so they can not intercept messages.

“Digital signature is another reliable way of data protection during transfer.”

Digital signature is the old way. They take away the improtant aspect of deniability. This should be fixed by changing to MACs.

“Account and chat hacking  as well as spoofing are totally eliminated.”

There is no correlation and saying user can not be hacked is snake oil.

“Hybrid encryption scheme”

Marketing. Key exchange algorithms for symmetric ciphers are as old as Internet.

“This hybrid scheme allows to “take the best” out of each system”

“The round wheels make the car go much faster compared to using square shape tires!”

“SafeUM cryptography experts implemented complex algorithmic optimization”

Sounds like the crypto library used isn’t the standard anymore.

“Our servers have no hard drives.”

Quite frankly, the users don’t care about the server configuration. They want

  1. Functional end-to-end encryption to protect messages from Safeum and all other third parties.
  2. A way to register and use the service anonymously through Tor to hide metadata.

“Third parties can only access these data after going through a complicated legal and bureaucratic procedure.”

Or they can remotely exploit the server.

“We do not have private keys. They are generated on the basis of the pass-phrase that the user must remember.”

User is a bad entropy source; services provided by OS should be used. User passphrase should only protect message logs at rest.

“You can simultaneously use up to three accounts online”

Is same key generated for every device when user enters the same password?

“What do you think about the disable chat history saving feature?”

This is normal setting users are going to want.

“Screenshot protection?”

Yet another snake oil feature. There is no sender based control outside idiocracy.

“Sign up without mobile number using only login and password. This will keep your location secret.”

There’s no Tor/VPN/proxy used and users correlate account name with their banking information. This is an outrageous lie.

“Security is at the core of everything, even in the free version!”

Yet there is paid option for “enhanced encryption”. Boo.

“We do not ask you to take our word! You can check the reliability of SafeUM secure messenger if you wish.”

Great. Where’s the source code? Does your licence allow me to compile a client from the source, or do I need to download the binary and take your word?


“Direct dynamic AES* key generation scheme”

If you’re generating new key per message, say so.

“It will take several decades and all the computing power of the globe to decrypt each of your messages.”

Crypto is not broken, it is bypassed / undermined. The figures are way below real numbers: It would take millions of years, not decades to decrypt a single message.

“Besides reliable encryption SafeUM also guarantees sender authenticity and data integrity by implementing digital signature mechanism.”

Nothing is said about fingerprint verification.

“AES block cipher with CBC mode used”

There are faster alternatives that are harder to implement incorrectly.

“PRNG generates a pseudo-random sequence of numbers”

The correct term is CSPRNG and it’s not generally advertised as a technology.

TLS v2.0 (SSL v3.0) is used as en encryption transport layer for WebSockets

There is no TLS 2.0. If it’s actually SSLv3 — they should immediately get rid of it:

“For data transfer and storage, the AES encryption is applied (256 bits key in CTR mode of operation).”

But, they just said it was CBC mode. Okay. CTR it is.


Would you pay for service that offers less features, less security, less privacy, less anonymity than a gratis alternative, such as Signal? Either the marketing hasn’t consulted the tech department, or the tech department has no real expertise in crypto. Avoid.

Current state of TLS

Qualy’s SSL test is an extremely useful tool when evaluating security of a specific web domain, but it doesn’t provide statistics. Those that do, don’t provide a database from which to parse information on TLS configurations. GCHQ has program called FLYING PIG that follows trends of TLS. We need an open source version of that.

I found a great tool to scan domains with: CipherScan.
Huge applause to Julien Vehent et. al. for their effort.

I wrote a quick script ( that converts Alexa’s top 1M domains csv file to simple list while preserving order. It also removes any duplicates and paths that have made it to the original list. I then wrote another script ( that makes sure there are N instances of CipherScan analysing different domain at a time. These aren’t my finest Python but they get the job done.

Here’s the compressed file of everything you need to start analysing web-domains: files.tar.gz (SHA256 67dee99416c055f80abfccdecb11ad1acdb22ed05fb570f3fea85e2672113061)

Here are the top 1M domains analysed (I hereby place the dump into the public domain). dump.tar.gz (SHA256 e4889418993a3d34d7e362d4cec024437aa62d8c47347f7c7ca45b06419a5f0f)

Now for the analysis; Good ones first. Here are the domains that support best cipher-suites:
1. ECDHE_RSA_CHACHA20_POLY1305 (20 685)
2. ECDHE_ECDSA_AES256_GCM_SHA384 (32 375)
3. ECDHE_RSA_AES256_GCM_SHA384 (327 758)
ECDHE_ECDSA_AES128_GCM_SHA256 (32 380)
5. ECDHE_RSA_AES128_GCM_SHA256 (328 439)

Being on this list isn’t enough. Just because cutting edge crypto is supported, doesn’t mean client and server actually use it. Not all clients support latest cipher suites, so servers want to retain backwards compatibility to ensure users can connect to the web page. This causes problems, as MITM can perform a TLS downgrade attack:

Alice to MITM:  I know AES, RC4 (~broken), RC2 (broken).
MITM to server: I know RC4 and RC2.
Server to MITM: The strongest common cipher is RC4, use that.
MITM to Alice:  The strongest common cipher is RC4, use that.

Server makes the final choice based on client’s proposals, and the client will either accept, or drop the handshake.

Users can configure their browser not to accept insecure ciphers, but not everyone has the skills to do that. The only way to pressure developers to update their code and users to update their clients is to stop supporting old crypto. Just as we need to know which companies send passwords to users over unencrypted email, we need to know which companies leave all their customers vulnerable, so that a minority of users with their “Netscape browsers” wouldn’t get upset, when they need to update. Based on Alexa’s top ~1M domains, I created a set of lists of those that support a weak configuration.

No encryption:
Not available (420 042)
Not working (164 388)

Weak key exchange:
RSA-512 (34 168)
RSA-1024 (4 587)
DHE-512 (26 854)
DHE-1024 (233 043)

Weak symmetric ciphers:
RC2 (34 866)
RC4 (292 561)
DES (61 692)
3DES (499 522)

Weak MAC:
SHA1 (567 302)
MD5 (212 612)

Weak protocol:
SSL2 (35 243)
SSL3 (678 079)
TLS1 (565 269)
TLS1.1 (976 863)

Weak Certificate:
RSA-1024 signature (46)
DSS signature (14)
SHA1 fingerprint (175 942)
MD5 fingerprint (4 689)


Secure: Send and receive secure messages, documents, pictures, videos and audio files.

Anonymous: Your conversations can not be tracked, intercepted or monitored. Your Wickr ID is anonymous to us and anyone outside your Wickr network.

No Metadata: Wickr removes all records, geotags, and identifying information from your messages and metadata

Shredder: Irreversibly remove all deleted messages, images and video content from your device.

Configurable timer: Set the expiration time on all your mesaging content.

Sounds promising. Yet we can’t confirm any of those. Wickr is proprietary software. Why? There are successful products such as TextSecure that are free and open source. They are doing great. Thus, there is no economical incentive not to make Wickr GPL licenced, let alone open source. Having to trust the company is the problem and Wickr should be disregarded at this point by anyone who values their privacy. Audits of source code by independent companies are excellent. Here they do not matter. It’s like RSA saying “don’t worry. BSAFE was audited by the NSA.”

After the source code is released, and the licence allows users to compile their own clients from it (preferrably Wickr should come with a script that produces a reproducible build), we can reliably analyze their claims. What worries me is, some of them are either false, or not up-to-date:


Wickr uses ECDH521 key exchange + AES256 for symmetric encryption. Despite forward secrecy, there is no ratcheting or self-healing property. Long term MITM can be established at any point with single key-exfiltration attack against either end point.

Fingerprint verification

Fingerprint verification is hidden behind a tap on the user avatar. Anyone who doesn’t know better won’t be using the feature. Since the lock icon is the same color as all symbols, there’s no way to immediately figure out that the security is not at adaquate level.
Fingerprint verification can be done through the MITM using video. This is actually a decent method if recipient is known (and assuming HSA morphing technology hasn’t reached this point yet). The issue is in usability. After receiving the video, it must be viewed by holding the camera icon pressed. If user accidentally presses the accept button right below the camera icon, the client assumes key verification was valid and assigns green key-icon for user: “verified”.

2The sender will have to either record a new video, or resort to less private options:

The fingerprint can also be sent via inherently insecure SMS and unencrypted email. Even the suggestion of using these channels reaks unprofessionality from Wickr team. There is no way for users to display fingerprints on screen of their devices, thus there is no high-assurance way to verify fingerprints on the spot.

The explanation on importance of fingerprint is bad:fingerprintFingerprints are not “optional”. They are the only thing that prevents MITM attacks against user. In a sense, they’re not lying when they say it provides added level of security. They just fail to mention there is zero security without verification.

“That friends are who they say they are”.

Providing this level of misinformation is scary. It will lead to confusions where people will do alternative challenge-responses through the MITM:

“What movie did we watch yesterday?”.


“-Okay it must be you.”

This section should have carefully explained, that it ensures that end-to-end encryption is done between Alice’s and Bob’s devices and not Alice and HSA, and Bob and HSA.

Illusion of sender based control:

sbcThis is pure security through idocracy. The next picture taken with external camera explains:


I found many reasons to use TextSecure over Wickr. I found zero reasons to use Wickr over TextSecure; Vote with your feet.

PS. Wickr, check your hiring priorities: