Pirate Bay co-founder aims to launch surveillance-proof messaging app Hemlis
thenextweb.com
thenextweb.com
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
(not affiliated, just a very happy user)
[EDIT] He details exactly how it works here: https://www.surespot.me/documents/how_surespot_works.html
[EDIT]: https://www.facebook.com/surespot/posts/614633905213667
26th June: "Just sent first successful surespot encrypted message from iPhone to Android."
1.) It's not open source
2.) They want to charge for certain features that are free in surespot.
(on top of the $100k they're already asking for)
3.) They wont let you run your own serverAlthough, not OS I believe, sadly.
We understand that some folks require open source for their secure messaging, and encourage them to seek out solutions that provide that. We encourage more options overall for secure communications.
Gliph isn't just a secure messaging tool. Our mission is to help individuals transact with their peers in a trusted, efficient and delightful way.
Gliph is the easiest way to send Bitcoin, and the only app in the App Store that officially supports sending Bitcoin P2P.
Secure communication with strong privacy controls is a fundamental requirement to accomplish our goal.
If Surespot had group chat I might consider it. Do any of the privacy-focused messengers support encrypted group chats?
I'm asking because I've made secure alternative to e-mail ResoMail, but I don't see a large pool of users ready to switch to secure comunications.
I'm asking because I've made secure alternative to e-mail ResoMail, but I don't see a large pool of users ready to switch to secure comunications.
For me it's a matter of convenience and network effects. Do I have to enter a passphrase every time I send a message? Do I need yet another client for this proprietary IM network? Does the client implement the features I expect? As for your software, first of all, it's great that you're working on it. These are the questions that come to my mind:
What are the benefits of ResoMail compared to email + PGP? You should explain why it's necessary to break compatibility.
Can I trust it? People who really need cryptography will use software that they know is reliable, e.g. a version of GnuPG that has been audited by an expert. How do I know your implementation is secure? It's not enough to state that it's open source.
You say it's open source, but where is the source code?
Is the traditional email client UX still the best way to go? Is it accepted by users who grew up with Facebook and expect less friction?
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.
The following are the protocols used by WhisperSystems:
https://github.com/WhisperSystems/TextSecure/wiki/Protocol
https://github.com/WhisperSystems/RedPhone/wiki/Encryption-P...
Silent Circle is Phil Zimmerman who is also for real (PGP real).
Trust apps that are developed by heavies with a history of first class crypto work. Be wary when a group of people with limited crypto experience launches a secure communications app especially if the app runs in the browser.
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...
I fail to see the point.
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
[1] https://news.ycombinator.com/item?id=6004510
It is possible to use OpenPGP certs with TLS, although I've never seen this done myself.
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.
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."
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.
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).
Do traffic-analysis-resistant wasteful routing among "servers". Run constant-bandwidth from the server to the client to foil traffic analysis if you really care about that (say, messages delivered only every polling window, and every polling window, a communications of the same size/direction. That seems pretty impractical on mobile, though, so maybe use some kind of push protocol for "you have a new chat request" and then foiling traffic analysis within the chat session (when you're actively using the device). Unfortunately if you can monitor all of the network, an attacker could identify a recipient just by initiating a request and watching for a new chat opening. You could also do things like block off known travel times or other times when someone won't be in contact, correlate with message response times, and at least be able to rule in or out certain suspects (it won't help in fishing expeditions, but if you have 10k people it might be, you could probably identify a person in a few months of passive analysis).
In short, low-latency is the enemy of traffic analysis protection. A true surveillance proof system looks more like anonymous remailers and less like Tor. But, people want realtime.
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.
I'm with the other reply. It's based in XMPP and PGP. Let's see how it goes. His experience is not common.
With this I don't mean he can do crypto with no error. I just mean he has some good ground about privacy and the tubes.
BitMessage!
Is there BitMessage for those? The main site is telling me there is not. Google search returns some forum threads, most of them not relevant.
They are currently trying to find an appropriate stream implementation.
That should be the way it works. You can't send a message to someone unless he's subscribed to you.
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...
It should be open source though. We don't need another cryptocat fiasco.
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.