

Pirate Bay co-founder aims to launch surveillance-proof messaging app Hemlis - subsystem
http://thenextweb.com/apps/2013/07/10/hemlis/

======
mike-cardwell
This sounds like a worse version of
[https://www.surespot.me/](https://www.surespot.me/)

Surespot is open source (including the server software too), and doesn't
charge you money for "advanced" features like sending images.

And surespot actually exists and is usable today.

Donate your money that way instead:
[https://www.surespot.me/contribute.html](https://www.surespot.me/contribute.html)

(not affiliated, just a very happy user)

[EDIT] He details exactly how it works here:
[https://www.surespot.me/documents/how_surespot_works.html](https://www.surespot.me/documents/how_surespot_works.html)

~~~
lectrick
Or Gliph. Which is far slicker than all of those combined.

Although, not OS I believe, sadly.

[https://gli.ph/](https://gli.ph/)

~~~
bx_
I use Gliph pretty much daily, and have since I first read about it (on HN)
almost a year ago. Great app.

~~~
bredren
that is awesome. thank you.

------
thezilch
Just adding another open-source (Android only, for now) competitor from
WhisperSystems (Moxie Marlinspike), including a secure-voice app:

[https://whispersystems.org/](https://whispersystems.org/)

[https://github.com/WhisperSystems](https://github.com/WhisperSystems)

Moxie is supposedly working on an iOS version. The Android version is fairly
seamless and can still contact users not using the app -- wire insecure. The
local storage is encrypted, regardless of your contact -- again, you run the
risk of wiretapping, if the other end does not share the use of the app.

~~~
mikevm
Ever since the cryptocat fiasco I'm quite wary of trusting these kind of apps,
that seem to be appearing like mushrooms lately. Can anyone with any crypto
know-how comment on the security of WhisperSystems?

~~~
thezilch
I'll let the crypto guys comment, but my understanding is that Moxie is no
pushover in that arena.

The following are the protocols used by WhisperSystems:

[https://github.com/WhisperSystems/TextSecure/wiki/Protocol](https://github.com/WhisperSystems/TextSecure/wiki/Protocol)

[https://github.com/WhisperSystems/RedPhone/wiki/Encryption-P...](https://github.com/WhisperSystems/RedPhone/wiki/Encryption-
Protocols)

------
runn1ng
....why not just run OTR on top of Jabber? It's pretty surveillance proof and
they are applications for iOS/Android that support all of that.

I fail to see the point.

~~~
sigil
> why not just run OTR on top of Jabber?

Indeed, on the face of it hemlis looks like a step backwards. There's a chance
it might not be, though.

The most straightforward way for them to combine PGP + XMPP would be to
encrypt and sign every message with the parties' static PGP keys. If you do
that, you lose both the perfect forward secrecy and repudiability you get with
OTR. [0] Those are important properties.

However, if they're planning to derive ephemeral keys for each conversation,
as suggested by tptacek [1] and others, then things get more interesting.

OTR + Jabber still seems weak to me in two areas:

1\. OTR's solution to the authentication problem is for the two parties to
agree, out-of-band, on a shared secret [2]. I don't think normal users are
going to do a good (secure) job of this. Key introduction through a web of
trust, aka PGP, would make for a better and more secure user experience.

2\. The reliance on a central server brokering messages is a problem. In fact
the authentication in OTR version 1 was so broken that a jabber server plugin
existed for MITM'ing OTR conversations [3]. Also, as another commenter points
out, with a central server an agency might still be able to collect Verizon-
style conversation metadata. I'd rather see something p2p along the lines of
freenet or i2p.

Finally, I'm not sure what their plans are for hemlis, but there's no way I'd
use a closed-source app for secure messaging. And I don't think it solves the
world's problems -- we need to be able to trust this thing. That's the whole
point.

[0] [http://www.cypherpunks.ca/otr/otr-
wpes.pdf](http://www.cypherpunks.ca/otr/otr-wpes.pdf)

[1]
[https://news.ycombinator.com/item?id=6004510](https://news.ycombinator.com/item?id=6004510)

[2]
[http://www.cypherpunks.ca/~iang/pubs/impauth.pdf](http://www.cypherpunks.ca/~iang/pubs/impauth.pdf)

[3] [http://www.ejabberd.im/mod_otr](http://www.ejabberd.im/mod_otr)

~~~
XorNot
If the problem in OTR is we can't rely on users to verify who each other are,
then any solution is going to inherit exactly the same problem because the
only solution to it is external trusted parties.

On top of that, PGP is exactly a step backwards if you're worried about just
observation of metadata because PGP with web-of-trust cryptographically ties
every message you send forever back to the key which sent it. OTR on the other
hand treat the keys as inherently disposable and relies on the only correct
verification protocol which is user knowledge of each other.

You have to choose which problem you find more important: either you can be
very anonymous, or very sure of who you're talking to but never both.

~~~
sigil
> _If the problem in OTR is we can 't rely on users to verify who each other
> are..._

Not what I'm saying here. I think the specific way they've chosen to verify a
new party in OTR -- by agreeing on a shared secret through some other channel
-- is a bad user experience with security implications. Normal people will
choose dumb, guessable secrets. Or send them over insecure channels.

I think the equivalent of an in-person PGP key signing has a better chance of
succeeding. If we're talking about an app, one person's phone could display a
QR code of their pubkey, and the other could scan that in to import it.

As with PGP, once the web of trust has a backbone (composed of hardcore early
adopters like us here on HN), you can skip the in-person step, and trust keys
that enough of your contacts trust.

OTR doesn't have this network effect.

> _The only solution to it is external trusted parties._

Sure. But _who_ those external trusted parties are is the crux of the issue.

Is it a browser maker and a couple companies you don't get to choose? Who are
perhaps cooperating with some government (hey, it's happened)? Or is it people
you actually choose and choose to trust?

> _On top of that, PGP is exactly a step backwards if you 're worried about
> just observation of metadata because PGP with web-of-trust cryptographically
> ties every message you send forever back to the key which sent it._

I mentioned this in the grandparent: with PGP, you could also derive ephemeral
keys for the conversation, as OTR does.

> _You have to choose which problem you find more important: either you can be
> very anonymous, or very sure of who you 're talking to but never both._

Not so. You can both be anonymous from the man-in-the-middle's perspective,
but can also verify each other. Look at how OTR does it. The "Socialist
Millionaire's Protocol."

[http://en.wikipedia.org/wiki/Socialist_millionaire](http://en.wikipedia.org/wiki/Socialist_millionaire)

------
RRRA
This is a terrible thing that they are trying to cash in on a closed,
centralized solution based on proprietary GUI for only iOS / Android. I'm very
disappointed and thought the TPB guys would no better. Sad day... Worst part
is that people will fund them withing 24h!

But I guess just like 1 in 2 Kickstarter project, it's a quick sell so you can
eat, but this brings nothing to the security/privacy table unless they come
clean...

------
troethom
I agree with everyone that this should be open-source, but at least this has
one benefit over the other proprietary solutions out there: This is not just a
secure messenger, but also a beautiful one. If you want to convince - and I do
- those who use Facebook Messenger and iMessage and don't necessarily consider
their privacy, it needs to have a great user experience on top of the
technical foundation. On the other hand, if it gets that and ends up being
open-sourced, it would be a great fit for Aral Balkan's Codename Prometheus:
[http://aralbalkan.com/notes/codename-
prometheus/](http://aralbalkan.com/notes/codename-prometheus/)

------
xnyhps
I wonder how that can be "surveillance-proof". Even with e2e-encryption any
product using central servers can still see who is chatting with whom, who's
in your address book and what IP address your phone is connecting from. That's
exactly the meta-data Verizon got accused of sharing. They might be of The
Pirate Bay-fame and not share this with the NSA voluntarily, but they're not
immune to being hacked or infiltrated.

~~~
mike-cardwell
Orbot (Tor for Android) allows you to host hidden services on your phone. My
ideal IM app would be one which uses Tor to enable peer to peer delivery of
messages over Tor hidden services directly between phones.

This way, not only would the message content be safe from pyring eyes, but
nobody would be able to see who is talking to who or when.

~~~
xnyhps
I totally agree! I've been working on federating XMPP over hidden services
([https://blog.thijsalkema.de/blog/2013/06/11/xmpp-
federation-...](https://blog.thijsalkema.de/blog/2013/06/11/xmpp-federation-
over-tor-hidden-services/)), but I don't give a setup like that any chance to
be possible on iOS.

~~~
xnyhps
The end goal is to package Tor + this + an XMPP server (Prosody) into plugins
for clients. It'd be a federated network running through Tor, but any XMPP-
capable client will be able to use it.

Sure, you need to rely on Tor, but aside from that anybody could set up their
own server easily (no hassle with DNS and SSL certs).

------
m-app
If you want this functionality now:
[http://threema.ch/en/](http://threema.ch/en/)

~~~
autodidakto
Exactly.

You have SMS style messages (text, images, offline support) that are end-to-
end encrypted (verifiably, despite being closed source). iOS and Android;
group chat coming; desktop coming; Interesting feature that aids in
authentication (scan each others' QR code for auth, etc); $2.

While it has more attack surfaces than OTR, it's 10x more convenient: No need
to agree to anything before-hand (most likely insecurely), no need to keep
anything running (offline support via threemas servers which only see metadata
and ciphertext); no setting up jabber services. This is a nonstarter for
unsophisticated users (whom we desperately need to help flood NSA with
ciphertext, and whom I rather chat with in anything but plaintext).

While not as battle tested as GPG, it's trivial to set up -- already got my
tech friend, my non tech mom, my non tech cousin on it. Has forward secrecy. I
still haven't figured out Inline PGP vs S/MIME vs PGP mime. Neither has K9Mail
+ APG apparently. I hope soon to be recommending bitmessage over email/GPG.

I wish, oh how I wish, there were a way that open source projects could charge
$2 bucks and be continually improving their services and solving both the
engineering and usability of crypto products. Now or never folks: The next NSA
scandal might be too late.

------
ripperdoc
This clearly highlights one of the big challenges for mass market surveillance
proof apps - there are too many obscure alternatives (unless one counts
iMessage as one of them). Getting the critical mass of users (similar to what
Whatsapp and Line accomplished) will be a huge challenge.

------
tommis
I seriously think a software like this should most definitely be open source
for it to be trustworthy.

------
ape4
Needs to be an open protocol. Not just a pretty app.

~~~
haakon
Well it's supposed to be using XMPP and PGP, so that's fine. My complaint is
that it needs to be open source. Closed-source crypto is no good.

~~~
nwh
Why not OTR? Not having perfect forward secrecy seems to be a big hit in a
situation like this.

------
lightweb2
No more re-inventing the wheel!

BitMessage!

[https://bitmessage.org/wiki/Main_Page](https://bitmessage.org/wiki/Main_Page)

~~~
Ihmahr
BM has serious problems. Currently everyone receives every (encrypted)
message. This doesn't scale when there are 100.000 messages a day.

They are currently trying to find an appropriate stream implementation.

~~~
lightweb2
I agree, it needs some work. There is no sense in trying to fund yet-another-
encrypted-messaging-application when other designs could use the help. The one
linked here doesn't even say if it will be open source or free or subject to
independent code audits, etc.

------
mrcharles
Strangely enough, trying to click through to heml.is complains about security
certificates in Firefox. Not Chrome though. Anyone else seeing this?

------
joshdance
This is probably a rookie question, but how is this surveillance proof, and
how would it be different from iMessage? The article mentions "Apple recently
publicly stated that its iMessage service is encrypted end-to-end". Isn't
something that is encrypted end-to-end surveillance proof?

~~~
sigil
First off, iMessage isn't open source, and Apple hasn't published details of
the protocol either, so we don't know if their statements on the security of
iMessage are actually true.

Even without knowing all the details, there are some concerning things we can
observe about iMessage:

[http://blog.cryptographyengineering.com/2013/06/can-apple-
re...](http://blog.cryptographyengineering.com/2013/06/can-apple-read-your-
imessages.html?m=1)

~~~
joshdance
Makes sense. Thanks. Surespot is open sourced, is there any indication that
Hemlis is or will be?

~~~
mtgx
They haven't decided yet, and it's not their priority (so it might never
become open source).

------
mtgx
CyanogenMod and Moxie are working on something similar, I believe - end to end
encryption with PGP, but it may work with more than just one chat app:

[https://plus.google.com/+CyanogenMod/posts/23vfN2qdZTu](https://plus.google.com/+CyanogenMod/posts/23vfN2qdZTu)

[https://plus.google.com/+CyanogenMod/posts/jnZSBV96wxU](https://plus.google.com/+CyanogenMod/posts/jnZSBV96wxU)

------
mylorse
Why is this any different than Gnutella or I2P chat clients?

~~~
themrdarknezz
Because they have realised that it will be worthless if it can't get any
marketshare.

------
lectrick
This project wouldn't need $100,000.

------
mtgx
I wish Google would just do something like this themselves with Hangouts.

I don't even think they aren't doing this because they plan to offer ads
related to Hangouts chats or whatever. I think it has more to do with the
"features" of Hangouts, such as saving your logs - forever. Think of it like
how Facebook wants to keep all the data forever so they can do something like
the Timeline.

I get there can be some benefits if the chats run through their servers and
everything is stored, but I'm not sure they are that huge, especially now,
when all governments are seeking direct access, or to scoop up everything from
all users. I think that's why Google's priority in the future should be end to
end encryption for users, for most of their services.

I also hate that because governments are abusing their powers, we are forced
to regress on convenience and make the services "worse" so we can be more
secure. But who knows, maybe this is for the best, and the Internet is meant
to evolve into something a lot more locked down and secure.

------
Kiro
I will never use this.

