Viber adds end-to-end encryption | Hacker News Reader

Viber adds end-to-end encryption

techcrunch.com

What really impresses me about Viber is the way they went all out and splurged with an honest to god penultimate "e" before the final "r". Most dot-com companies would have settled for "Vibr", but they went the distance and bought an authentic luxurious vowel, precisely where it was called for, without going overboard and throwing in a sometimes-vowel "y" in place of the "i". Very bold and straightforward spelling, I must say. Color me impressed!

Viber is an Israeli company, don't be so judgmental of their poor startup spelling skills.

No, you misunderstand: I am truly and earnestly impressed by their good spelling, not criticizing any bad grammar. If they'd named it "Vybr," it would have come off like Steve Buscemie holding a skateboard over his shoulder wearing a MUSIC BAND t-shirt, desperately trying to appeal to the youth demographic.

Read that one again with </sarcasm> at the end :)

Or ... people name their products/companies based on their ability to secure a proper domain name, rather than being some hipster startup founder trying to appear edgy. Does Viber seem like a name that would be taken?! Listd.com vs listed.com was one I had to deal with some time ago.

End-to-end (E2E) code needs to be open source and venders that don't agree to an audit should be considered insecure; holds true for What's App, which declined to allow their E2E code to be audited.

Also, message metadata is still being leaked by all of these E2E implementations and needs to be fixed.

Would open sourcing the Whatsapp client hurt Whatsapp in any significant way?

I mean, sure, there could be "Whatsapp clones" (aren't there already?!), but wouldn't Whatsapp still benefit from the phone number user base it has, thus maintaining a certain lock-in on its users from which it already benefits?

Here's the Telegram iOS code by the way: https://github.com/peter-iakovlev/Telegram

> I mean, sure, there could be "Whatsapp clones" (aren't there already?!)

Sounds funny if you consider that Whatsapp itself is just a branded deployment of FOSS XMPP server Ejabberd, with feature of federation taken away. Plus a client app implementation, of course.

That is only possible because Ejabberd doesn't use the AGPL license.

Come on, it would definitely still be possible with AGPL code. What brought people to whatsapp is its ubiquity and the fact that it just works, and what keeps them from going elsewhere is the inevitable network effect.

Nothing in the AGPL prevents either from occurring.

I think you are misunderstanding jeena. If ejabberd were AGPL, then a fork/a instance of it like Whatsapp would be legally obliged to open up their code as well.

No idea whether the assumption is true that Whatsapp is just a branded deployment.

I still don't understand how opening up the codebase would prevent them from being successful.

As the countless messaging apps out there demonstrate, the value of communication apps lies in the network they build. If they provide a decent UX, and successfully bootstrap a network large enough, it wont matter if their code is open.

I don't think that was an argument against that. At least I agree. The situation is only possible because the AGPL is not used for the free component, but Whatsapp should have no problem opening up their code.

And, I've been using Viber longer than I knew WhatsApp existed. Just saying...

Wireshark,xposed + some creativity and you have your own E2E encrypted solution with OOB keys. For any messenger. It is not done, because there is no demand.

Would it be possible to explain the reasoning of the workflow/toolchain you're suggesting?

wireshark to reverse the protocol. xposed to rewrite the classes required on android.

you replace Whatsapp.sendMessage(string,Jonny) with WhatsApps.sendMessage(EncryptString(string,Jonny),Jonny)

And EncryptString taps into your keystore to find jonny's key.

> Also, message metadata is still being leaked by all of these E2E implementations and needs to be fixed.

Ricochet (https://ricochet.im/) solves that problem using Tor hidden services. Desktop only at the moment AFAIK, though.

One great benefit to ricochet is that you can choose to exclude those with whom you are communicating from your COMSEC threat model, due to the lack of (mostly connection) metadata availability.

Sounds interesting.

Appears to have a lot of docs/code, are you able to link to the related code & docs?

Are there any stats posted on the size of the network? (either from Tor or P2P network analysis)

WhatsApp's "E2E" code is from Signal, which is open source.

This zealous belief that all secure cryptography must be open source is something I hear a lot from open source advocates, but not so much from cryptography engineers.

Is the encryption/decryption code in WhatsApp open-source? I haven't been able to find it. My assumption was that they conform to the Signal encryption protocol, which is openly specified, but that the code they use to do so is not open-source.

Yes, it is. It's linked directly from the paper (https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...) that documents their use of the protocol.

It's the exact same code we use in Signal: https://github.com/whispersystems/libsignal-protocol-java

The value is not just the public display of the source code for auditing, but the validation that what you are running was indeed compiled from that code.

This is literally an impossibility. Java apps are typically obfuscated with randomization of symbol names. Each build is unique and not reproducible.

You are better off verifying the actual compiled and distributed apk files than verifying the source.

It's impossible?

https://whispersystems.org/blog/reproducible-android/

Simply open sourcing the code doesn't give that validation.

Not completely but I can certainly look at it, compile, and then side-load it onto my device knowing it's what it said it was.

You keep saying this, but how do we know they are actually using the code from Signal without access to source and reproducible builds? Last time you told me it was easy and legal to reverse engineer the code. I then asked you what tools you use to do that and you ignored the question.

To reverse engineer code? For big projects, I used IDA, like everyone else does. For smaller projects, I used Hopper, or, for architectures that IDA and Hopper didn't support, I'd postprocess binutils output.

For an example of a more sophisticated approach, look at:

https://sourcedna.com/

Remember, in this case, it's especially easy to reverse, because you have the source code; all you're doing is matching the control flow graph to the original source.

Thanks for making this response. Genuinely interested.

[To whomever down voted... I guess I get down voted for not showing gratitude immediately after he posted a reply? This is why I don't post here often. Quite mean people here.]

Do you know if there exist tools that take a binary and a source code file and attempt to automatically compare the control flow graphs?

I imagine I won't ever get to it, but that sounds like an interesting problem to try to work on.

Yes, there are. SourceDNA does a bunch of this.

If you want to look at the Android APK, you can use apktool to get back Java source. Hacked clients like WhatsApp+ even build new derivative products using that output, and spammers do it to get code they can use to inject messages onto the network without having to write their own software.

I think it's great when people further verify WhatsApp's client security, please share your analysis!

Thank you for your tip and contributions to open signal. I appreciate that you want to get encryption into as many hands as possible, even if circumstances may not be ideal.

My primary concern here is a long con. Everything is probably okay now, but after a while, people will stop looking and verifying. With WhatsApp keeping source closed, it makes that period of time shorter, I think. I will try to work your suggestion into my job :) If I'm paid to do it, I can keep doing it indefinitely, even working on tools to automate it.

> which declined to allow their E2E code to be audited.

Could you cite this? The Signal Protocol implementations they're using are both open source and well audited.

That's just an utterly ridiculous proposition.

By that logic the entire application would need to be open source, because nobody would start out by targeting the crypto if they wanted to spy on someone.

Even if I were to accept your logic, what's ridiculous about that?

Open sourcing the crypto code wouldn't be ridiculous, but pointless.

What I find ridiculous though was

>venders that don't agree to an audit should be considered insecure

The same thing applies to every single part of the application, but not equally. No attacker is going to start out by trying to break the crypto, unless it's obviously broken. "Normal" bugs are far more common and often more dangerous (Thing RCE, or in the case of many modern apps: XSS)

> No attacker is going to start out by trying to break the crypto, unless it's obviously broken.

Emphasis mine. I agree with ryanlol here. Why bother with active attacks when you can just steal their private key from a code execution?

Similar to this, but with the priority flipped:

https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...

ryanlol is correct though. If you open source just the end-to-end crypto part, it doesn't mean that the there's no backdoor elsewhere - it could easily leak the keys or whole conversations.

The second problem is - you don't know if that source is what ended up in the binary.

So yeah, unless you can compile the whole thing yourself, it should not be considered secure.

Open source client and reproducible builds. Signal already does that.

It's not a high bar.

That's a completely different from just wanting the e2e crypto source, which is useless by itself.

https://www.bishopfox.com/blog/2016/04/if-you-cant-break-cry...

What to you are steps towards the mass adoption of universal turnkey state-level OPSEC for everyday use? ___

So, my point that the E2E should be open source is that that code should never be the basis for a business model, so to me, it being open source makes sense. As larger system, that's why I'm saying there needs to be an audit.

Also, you mentioned ATP and I agree, which is why to me it is troubling Signal instead of guarding metadata, actively collects it.

Please let me know I have missed anything you'd like me to address. And I really would be interested in your thought on the question above in as much detail as you're able to share. Thanks!

Ideally it would be possible to use third party clients to connect, and so anyone could use a fully open source solution if they wanted.

That's fair!

But you need far more than just the crypto code to create a client, I think open source protocol specs would already achieve this.

And my main complaint was with the claim that open sourcing their crypto code would somehow make a meaningful difference to the security of these applications to the extent where you could consider all applications that haven't done so "insecure".

I don't think I get your complaint

Without open-sourcing the crypto, they could be just doing rot16($message) for all we know. Open-source is a requirement for being considered secure. It doesn't mean they aren't secure if they aren't open-source, but that you shouldn't consider it so, because you don't know if it is or not.

> I don't think I get your complaint

> Without open-sourcing the crypto, they could be just doing rot16($message) for all we know.

There are two things you can do:

1. Watch the outbound traffic and attempt known-plaintext attacks

2. Reverse engineer the app

Neither is particularly difficult. Most Android apps are trivial to break apart using Lobotomy. A large swath of software security folks specialize in binary auditing.

Has anyone done that and produced a fully open source app to connect to whatsapp?

Lots of people.

https://github.com/tgalal/yowsup for example

Looks like WhatsApp isn't so happy about that ...

https://gigaom.com/2015/01/20/whatsapp-cracks-down-on-people...

Do you know if the clients work with the new encryption?

Yes, axolotl is open source. (However I can't comment on how much it's been modified for the official client)

>The enhanced delete feature, meanwhile, has been in the app for a while, but is part of the company’s is a way for users to wipe a conversation not just on their end, but on that of the recipient’s phone. You can think of this as Viber’s answer to ephemeral messaging, but with a more manual approach.

Does anyone else think this is a violation of users' rights? If I've been sent a message, it shouldn't be possible for the server to delete it. I could screenshot everything, or run a tweak that saves everything.

Imagine if Gmail started allowing senders to remove email they've already sent and has been delivered.

Imagine you're on the run from mafia and communicating with your parents via a messenger. You sent your current location and after a few hours mafia people approached your parents and took their phone. Now, if you sent an message that deletes itself, you're sure that unless your parents didn't preserve it intentionally by copying and pasting or taking screenshot, this location isn't revealed to mafia. If your messenger didn't have this feature, your parents would have manually delete the sensitive message — what if they forgot?

This feature is quite useful, even if not 100% proof.

As I said below, if every request had to go through customer service, I might be okay with it.

And doesn't the same logic apply to Gmail? Do you think they should do the same?

I think it's reasonable to allow senders to revoke a sent message, particularly if it was sent just a short period of time ago. The only assurance you would have that this works is if both sender/receiver are on the same system. The question is a little trickier if the receiver has read the message. And, I agree, that after some period of time, particularly after the receiver has read the message, the message should be inviolate on the receivers side.

If it hasn't been delivered to the user's device, fine. Once it's been delivered, it shouldn't be modified.

I suppose I might be OK with individual exceptions to this rule, if some sensitive message was sent, after going through customer service. It certainly shouldn't be a one click to delete.

What do you mean by "user's rights" and by "sent"? Why shouldn't it be possible? If the TOS and app allow and enable it, it can be done.

This sounds no different from, say, Snapchat, except that the deletion is triggered by the sender instead of by a timer.

It's the same thing people complain about wrt unfree software, e.g. Kindle deleting purchased books remotely if they were uploaded by someone without the rights to the book.

The difference with snapshot is that their whole gimmick was the deleting thing. You had no expectation of permanency. But I'm sure many use Viber with the expectation that they'll be able to access old communications; after all, it's on their own device.

Sure, they have the right to do it, in the same way that Gmail could implement the same anti feature, in the same way Amazon had the right to delete books. But that just causes me not to use them, just like I'd stop using Gmail if they did that. (I still use a Kindle, but I've only ever purchased one book, and read it right away. I'm not dependent on them not deleting my books.)

If a service offers a feature, it's within customers' rights to use that feature. If Viber is unilaterally deleting messages, that's an issue (as ephemeral messaging doesn't seem to be their primary intent). But if Alice is able to delete her messages to Bob on Bob's device, and both know this (or should know this, they chose the messaging platform), Bob has not had his rights violated. He's complying with Alice's request (automatically).

The comparison to Amazon is not apt. That was Amazon, not the seller of the book, that chose to delete it (in that case because the seller didn't have a right to sell, though given it was 1984 it was rather amusing/ironic). If, for instance, Amazon's digital platform allowed sellers to remove their content from Amazon's listings AND from "buyers'" devices, then 1) no one should be too surprised when it happens, 2) no one should use that platform.

The comparison to Amazon is about the remotely deleting part, not the why part. I have a problem with anything on my device being deleted without my consent.

You used the word "sent" earlier and the phrase "on my device" now. But it seems the app isn't transferring the message to you, only presenting it -- like a website. (Does the message exist outside the app?)

Not being pedantic for the sake of it, just pointing out the language you are using is from a position of ownership -- you receiving and owning a message sent to you, and it is then being deleted -- while the app seems to be retaining all rights with the sender, who merely uses the app to present a message to you, and can revoke viewing privileges at any time.

Once it can be viewed offline, the sender shouldn't be able to delete it.

I think this is a valuable feature for users of the product. Some users like this feature. If you don't, just use another product.

Not everything needs to be a philosophical debate.

I don't think the feature is well known. What percent of Viber users could tell you that messages can be deleted without their consent?

I think that's irrelevant. It's part of the product, is an intentional feature that has value, and is not even an uncommon feature (exists on Instagram DMs.

> Does anyone else think this is a violation of users' rights?

Not at all, and it's kind of strange to me that you do. It's just... how the app works. Slack lets you do it, for example, and I've used it occasionally. Heck, reddit (and I think HN?) let you delete comments, even if they were previously, uh, transmitted to a reader's browser.

The Gmail example is irrelevant because that's not how email works. If a new company / protocol came about which wanted to try their hand at a different way of sending online letters, that let you delete them later then I'd have no problem with that. I might not use the service, but there's no foul play or anything.

>If a new company / protocol came about which wanted to try their hand at a different way of sending online letters, that let you delete them later then I'd have no problem with that.

I don't think this is a particularly well-advertised feature of Viber.

Neither reddit nor hn are meant to be a means of private comunication. Generally you can't view them offline, and so on. I'm not sure about slack

>that's not how email works

And I think the average user's expectation is that a messaging app will work the same.

By the way, reddit won't let you delete PMs you've sent to another user.

I highly recommend following the updates from Frederic Jacobs on his Twitter. He has already found a number of significant flaws with Viber encryption...

"Wow, Viber disables crypto based on geo-location? Export controls related?" https://twitter.com/FredericJacobs/status/722511416381480961

"Viber’s encryption appears to be a custom C++ implementation. Super reassuring they use MD5 for attachments." pic.twitter.com/wi6lB30KjY

https://twitter.com/FredericJacobs/status/722489499779858432

It sounds like there's not yet any published details on what the crypto Viber's using is. Can we withhold judgement until we get that? I'm fine with closed-source, but not with no technical documentation.

Most people who try to implement cryptographically secure messaging get it badly wrong.

We absolutely do need to get some documentation to judge whether Viber has good crypto.

That being said, we can still judge them positively for at least trying to secure their user's messages end-to-end.

More great news from the world of communication, but yet again I'm wondering how we can trust the encryption to really be end-to-end without access to the code. Are the messages still traveling through Vibers servers? Is there any way to know?

"I'm wondering how we can trust the encryption" You can't. Not unless the company employees security experts, has a significant bug bounty program (with significant rewards), is open to a degree about their securit architecture, and is popular enough for white hats to actively seek out bugs.

This isn't about trusting that the company isn't try to dupe you. It's about trusting that the company can implement security properly, and that enough "good" people will find security flaws before the "bad" guys do.

You're both saying the same thing.

As for the good people vs. bad people argument, it should be noted that the good people have a harder job than the bad people. For the bad people to do their job, they only have to find one exploit, whereas the good people have to find most/all of them to have made the system secure. That's why employing people to work on security matters (whether through a bug bounty program or through direct employment), a company that values security shouldn't rely on unpaid volunteers alone.

How much do you think a WhatsApp passive decryption bug would be worth? They don't seem to have a bug bounty, I wonder how much something would go for on the black market.

Viber has become a shadow of its former self. It regularly crashes all phones in my family, you get message notifications way too late, and it takes up a ton of storage on your phone.

I wouldn't touch Viber with a ten foot pole, even if their entire crypto implementation was open source (which it is not). The company was founded by an ex-military (some sources say ex-Mossad) dude. He is also connected to several spyware applications.

“Talmon served for four years in the Israel Defense Forces and held the position of CIO of the central command. He graduated Cum Laude from the Tel-Aviv University with a degree in Computer Science and Management.”

More here: https://viberphoneapp.wordpress.com/

http://www.moh10ly.com/home/security/viberisaspy

http://www.jpost.com/Business/Business-Features/Japans-Rakut...

https://www.theguardian.com/technology/2013/aug/30/viber-fou...

I always enjoyed using Viber, but I never liked that it featured no encryption. It is an alternative for Skype for me, I could video call from my phone, laptop, tablet, etc and do audio calls. Skype became insecure, it leaks your IP address and it's got terrible synchronization issues, and now chatting is really buggy, messages show up in the wrong place for me, as well as the Linux client for it sucks. Viber has a good all around client for every OS I've used it in (including Linux).

This is fantastic news, as others have said, maybe they should really open source the portions of code that have to deal with E2E encryption so it may be audited.

Skype stopped leaking your IP address earlier this year. It existed before that, but is now the default behavior. http://blogs.skype.com/2016/01/21/to-our-gamers-ip-will-now-...

It says "by default" implying it could still be leaked, their "fix" is a Skype setting that masks your IP until you're in a call with somebody.

So basically now Telegram is the only app not doing it by default?

Add skype and hangouts to your list...

And Facebook Messenger.

"Along with the encryption, there are some other privacy features getting added into the latest version of the app. Hidden chats will give users the ability to essentially “hide” certain conversations from their usage log, accessible only if you know a specified four-digit PIN"

Can anyone with Viber describe what happens when you get a new message from a hidden chat partner? Does a notification show? how does that notification look?

I was forced to uninstall Viber on account of the SPAM I was getting. I have been trying to figure out how the spammers got my viber contact information.

Frederic Jacobs, one of the Signal authors: ”Viber’s encryption appears to be a custom C++ implementation. Super reassuring they use MD5 for attachments.” https://twitter.com/FredericJacobs/status/722489499779858432

Can't we just call it TLS? Every time I read "end-to-end encryption" I'm afraid they just invented some weird security mechanism. Plus it's 3 chars.

It's not TLS.

Ugh. Should we be scared then?

TLS is Transport Layer Security.

When we're talking about End-to-End Encryption, we usually mean:

    * Application Layer Security (between users)
    * Transport Layer Security (between each user and the server)

And here, Security should mean public key authenticated encryption (e.g. crypto_box() from NaCl)

TLS would normally be used between the client and server. Viber may use TLS for that too, though WhatsApp and Signal use Noise pipes for that purpose. The point of end to end encryption is that they're also encrypting the messages so that they can't be read on the server. Don't know what Viber is using, but moxie posted a link to the details about WhatsApp's implementation. https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...

Get news to see other services following in the footsteps of WhatsApp!

Telegram had e2e private chats for over a year before WhatsApp added e2e

The problem with Telegram is that it doesn't default to E2E; using it means to go through that additional step of starting a secret chat which I venture a lot of people won't do unless they're very conscious of it.

Does bad crypto counts? I don't think so.

I keep seeing this accusation get flung around whenever someone mentions telegram but never proof. I remember telegram had a vulnerability once and then it was patched just like any other security software.

You shouldn't throw around accusations without proof.

Here's your proof: http://cs.au.dk/~jakjak/master-thesis.pdf