Why I think Heml.is is snákaolía

Heml.is is a new instant message client promise that is “beautiful & secure” that seems to have cashed in on the current NSA scare, by lifting on the good (bad?) name of one of the Pirate Bay founders. Apparently, people have committed $150 USD for this in two days.


Clearly people believe hemlis will offer something that the 62 apps in the Google Play store, and over a 1000 apps in the Apple App Store don’t offer…..

What do they promise? Let’s first go through their claims in their video:

“no one can spy on you, not even us”
“only your friend can read what you write”
“based on end to end encryption”

“We are building Heml.is on top of proven technologies, such as XMPP with PGP”

Great. So full trustworthy end to end encryption. Which means you can do this over ANY insecure transport mechanism. I could post those encrypted IMs on my blog – only the intended recipient would be able to decrypt it. Very secure. But it raises another question:

“We are building Heml.is on top of proven technologies, such as XMPP with PGP”

Great. So full trustworthy end to end encryption. Which means you can do this over ANY insecure transport mechanism. I could post those encrypted IMs on my blog – only the intended recipient would be able to decrypt it. Very secure. But it raises another question:

“build as secure and as fast as possible a service”

Why do we need the hemlis XMPP infrastructure? As far as I can determine, the only reason for that infrastructure is to give the hemlis people an excuse for annual revenue. Why not let Facebook and Google pay to maintain that XMPP infrastructure? While I might not trust Google as an entity, I sure as hell trust Adam Langley’s TLS protocol choices that he can steer Google into using. So, what’s the hemlis excuse for running their own service:

“We will however charge a small fee (via an in-app purchase) to unlock certain features. Exactly which features is to be determined at a later time. We do this to fund the continuing development and infrastructure.”

“The way to make the system secure is that we can control the infrastructure. Distributing to other servers makes it impossible to give any guarantees about the security. ”

As the Islandic Penn & Teller would say (after talking to their lawyer) is: kjaftæði!

Didn’t they just say end to end encryption was going to be used? Who cares about the security of the transport if the message is securely end-to-end encrypted! Didn’t the hemlis people just claim the NSA and GHCQ could vacuum up a copy of my PGP encrypted chat message and they wouldn’t be able to decrypt it? If the end-to-end encryption works, there is no need to require a secure (hemlis run) XMPP network service network.

Centralizing is the wrong thing to do. By running their own hemlis XMPP service, they are actually making it easier for the NSA and GCHQ to get access to our (encrypted) IM data. And additionally, they are making it trivial for governments to just mandate a block of the hemlis XMPP network service. I can guarantee you that China will never even be able to see this network provided it actually launches.

Much better would be to allow people to completely decentralize the whole IM business by letting them running their own XMPP servers. XMPP is made to allow full decentralization. You can find my XMPP identity simply by looking for it based on my email address, paul@nohats.ca. Your IM client will be able to find the XMPP servers of the (very very Small) IM network run by “nohats.ca” via the SRV DNS records published in DNS.

“usually, security means complexity”

Finally a quote I can agree with. However, I’m already cringing and waiting for the padlock to appear. Security is not a binary toggle, so yes, representing a security state to an enduser who is not an engineer is a hard problem. There is a reason security is complex and OTR is one of the few protocols and implementations that has a very strong focus on usability. The developers tried to keep it as simple as possible, but everything about security cannot be reduced to a fucking padlock!

Promising a simple beautiful secure GUI is like promising world peace. It’s not the idea that’s impossible – it’s the implementation of that idea that is impossible.

(If you wonder why I hate padlocks so much just search for “otr padlock” to see the number of people suggesting to use padlocks in the OTR gui. Or search how Moxie basically killed the browser padlock by using sslstrip with a fav.icon).

PGP Key exchange

If it is not to facilitate the very securely encrypted PGP messages, then the only other thing left to protect is the exchange and verification of PGP public keys. Of course for that we have PGP key servers – although the PGP key servers suck. Knowing where to get PGP keys is not enough. For example, the key for assange@wikileaks.tld is (most likely) not a real key used by Assange. Someone dropped a key there in the hope that someone would use it to encrypt something for Assange. (Interestingly, since the “tld” domain does not exist, one has to mail it to one of Assange’s real email addresses, and I only know of a few parties outside of Assange that are guaranteed to get a copy of such an email. But what if hemlis solved this already through superb engineering skills? Well, then they have another problem: they won’t accept untraceable anonymous accounts.

Why not use OTR? Well, according to hemlis:

“Even though we love OTR it’s not really feasible to use in a mobile environment. The problem is that OTR needs both parties to be online for a session to start, but a normal phone would not always be online. It would not work at all for offline messages neither.”


Let’s ignore the fact that 99.99% of phones are always on and always connected to the network, making this statement completely bogus to begin with. Let’s say Aðalbjör wants to send Björn an OTR message. If Björn is offline, then Aðalbjör cannot initialise an OTR session to establish a secure channel over which they can talk securely. Aðalbjör will have to queue up her message to Björn until he becomes available. How is this different from Björn’s client receiving the securely transmitted message while Björn is asleep and not reading it? The only difference is where the message was queued up. Aðalbjör and Björn actually never need to both be online at the same time to start or continue to use OTR. As the hemlis people themselves admit on the FAQ, the XMPP protocol allows for storing messages to offline people, and those messages include the OTR handshake messages to establish a secure connection! Remember, OTR is an inline encryption
protocol. It works fine with XMPP offline messages.

Will it be open source?

“We have all intentions of opening up the source as much as possible for scrutiny and help! What we really want people to understand however, is that Open Source in itself does not guarantee any privacy or safety. It sure helps with transparency, but technology by itself is not enough. The fundamental benefits of Heml.is will be the app together with our infrastructure, which is what really makes the system interesting and secure.”

Mæli kjaftæði! This is where the snake oil really burns bright! While I have no doubt that
the opportunity for hemlis to make money is “interesting”, when you start saying that your application cannot be fully open source because it would be a security risk, you’ve committed the gravest mistake in cryptography – security by obscurity. Hemlis is going to be blackbox security. They should have called it Clipper Hemlis!

Why is Heml.is different from WhatsApp, MessageMe, iMessage etc?

“Our focus is your privacy so we are building everything from software to company structure to protect that.”

If the security of the hemlis IM network depends on the company structure of three guys standing up to the billion dollar a year military industrial complex combined with the billion dollars a year entertainment industry, you better have a plan B. I’m not comfortable with a distance of three waterboarding sessions, six kneecaps or one extremely expensive lawyer.

Not to mention that IM network that hemlis needs to run. They say it needs an annual revenue to keep running. Just ask wikileaks how easy it is to keep donations or payments going when Mastercard, VISA and PayPal ban you.

Finally, this last FAQ from their site is also very intriguing:

“How will the codes, pre-register usernames and “My name in the app” work? Prior to the release of Heml.is all backers will get an email with their codes and instructions on how to proceed. “

Unfortunately, they are not giving out any details about “hemlis IM network user identities”. Probably because they have no fucking clue how to deal with it. Can I register “NSAgov”? wikileaks@nohats.ca”? “EdSnoden”? helpdesk@heml.is?

They said they were using PGP, so I expect some kind of web of trust leverage with @heml.is identities or something. I have no idea how they would scale that so I can easily and securely find out what hemlis identity Assange has. The PGP keyservers are a disaster. It’s a battle field of spam, malicious fake identities, bogus signatures, keys where the private key was lost forever, and probably a bunch of compromised keys too. And despite all of that, it still failed to scale, provide a unified interface to easily obtain and verify keys. PGP keyservers should be taken down – they are a security risk at best. What is hemlis going to do different? Require a confirmation email? We’ve seen how well that works with the various Certificate Agencies.


While I’m happy to be proven wrong, the inevitable conclusion for now is that an hysteric mob of people gave three guys $150K for complete vapourware. I’m not sure who is more happy – those guys or the NSA. Next time you find yourself with a strong desire to sponsor the Alliance in the Crypto Wars, consider donating to those people who are actually working on these problems. Give some money to the IETF, or one of the crypto opensource projects. Just don’t buy more snákaolía please.

For those who wish to send me hate mail after reading this, please concentrate all your anger and hate and torpedo my OPENPGPKEY and OTRFP drafts that I submitted to the IETF instead. These two drafts are aimed at using DNSSEC to make Email and Instant Messages scale against passive (and some active) attackers and will assist and making encryption (and authentication) the default mode of the internet for our personal and private content.

What’s left for Hemlis? A imagined beautiful interface based on a few photoshop screenshots and a logo.


Leave a Reply

Your email address will not be published. Required fields are marked *