Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WhatsApp's Signal Protocol integration is now complete

whispersystems.org

Post reply on HN
Print view View original

321–330 of 386 posts

Re: WhatsApp's Signal Protocol integration is now complete

#321

Post by quotemstr »

baby wrote: post #235
rakoo wrote: post #179

Earlier quoted context omitted.

It's easy to shoot yourself in the foot with TLS (see: OpenSSL). Also, TLS has roots in a time where we knew much less in terms of crypto; as time went on and flaws were discovered, SSL/TLS was patched all around, meaning it has become much harder to implement correctly. Noise starts from a clean state with modern knowledge of cryptography and modern cryptography. Much easier to understand and replicate, much harder…

> It's easy to shoot yourself in the foot with TLS I would argue it's easier to shoot yourself in the face trying to re-implement/re-design something like TLS.

The OP's point is that it is like TLS, except with a novelty effect. Personally, I prefer that everyone standardize than use a hundred different crypto protocols, none of which receives adequate scrutiny. TLS1.3, with encrypt-then-MAC and zero-RTT setup, can't get here fast enough.

Re: WhatsApp's Signal Protocol integration is now complete

#322

Post by mike_hearn »

pfg wrote: post #69
mike_hearn wrote: post #14

This is really excellent. A few thoughts: 1) They seem to have replaced TLS/SSL between client and server with "Noise Pipes". Based on a couple of minutes Googling this seems to be a brand new one-man protocol from Trevor Perrin (the same guy who did Axoltl on which Signal is based). At least, I'd never heard of it. I wonder if this is the first inkling of a post-TLS future? http://noiseprotocol.org/noise.html 2) It'…

I keep wondering if package managers (be it Google Play, apt or dnf) are in need of a solution like Certificate Transparency. Like Certificate Transparency, it would not necessarily prevent a backdoor(/certificate) from being pushed to selected users, but it would guarantee detectability, at least after the fact. If the package as a whole is included in the log, it would also allow BinDiff-style reverse engineering o…

It would be interesting but I suspect ultimately futile.

Certificate transparency works because detected problems are actionable: the bad certificates can be revoked and, if necessary, so can the entire CA that was compromised.

There is no way to revoke an app store, as there's only two of them that matter. So if the transparency system revealed subversion .... then what? There'd be a big uproar for a few days, but nobody would know who the target was, or what the bad app was doing, and there'd be no action that could be taken.

Re: WhatsApp's Signal Protocol integration is now complete

#323

Post by mike_hearn »

envy2 wrote: post #104
mike_hearn wrote: post #19

Earlier quoted context omitted.

That last blog post is clearly written by Jan Koum, as it talks about his past in the Soviet Union. But his name doesn't appear anywhere on the blog post and if you didn't know that odd bit of trivia, it'd be completely confusing - who the heck is talking? Some random employee? They need to add the name and job title of the blog posts author to the bottom.

It's now signed "Jan and Brian."

That's great. I wonder if it's because they saw my post or if they realised the issue themselves.

Re: WhatsApp's Signal Protocol integration is now complete

#324

Post by mike_hearn »

visarga wrote: post #304
mike_hearn wrote: post #31

Earlier quoted context omitted.

Define 'reasonable'. Essentially, no. You have to trust that the app is really doing what it claims to be doing. If it were open source, would it be different? Maybe. Signal Messenger is open source and the Android build is reproducible. However, the way you reproduce it is to run a Docker image, so that isn't really meaningful unless you audit the code that's used to build it. And then audit the code of the app itse…

But can we still be sure of our privacy if we combine two or more such semi-secure systems? TOR does such a thing with the Onion Routing protocol by using intermediaries.

No. There is no way to be completely sure of your privacy in any context when using modern computers, it simply isn't a problem that can be solved with technical tricks.

Consider all the work I listed above. Imagine you actually did it. Great. But ... you're using WhatsApp to communicate with someone else. Did they do the same work? No? What if their device received a different binary to yours?

You can't even solve this with clever auditing frameworks because then you're just shifting the trust to whoever writes and distributes the auditing tools.

That's why it's so important to understand that you cannot solve political problems with cryptography. At most, you can reconfigure the set of people you need to trust (hopefully by making it smaller). But if those people can be forced to act by a political entity, then no crypto will save you.

Re: WhatsApp's Signal Protocol integration is now complete

#325

Post by josephlord »

teaneedz wrote: post #302
greenspot wrote: post #22

Great news. I'm just wondering why Facebook/Zuck is doing this. Is he fearing the competition–all the other E2E messengers out there? I'm asking because I could imagine that Whatsapp might get banned in some countries soon (as recently happened in Brazil) and thus, lose market share.

I also wonder how Facebook will monetize WhatsApp with e2e now.

They don't need to. They just need to stop it becoming a full competitor.

Facebook's asset is the social network, your contacts. WhatsApp was a threat because they were getting a social network to match. That could then have been acquired (by Google) or developed a more social platform on top of it. By owning it Facebook can keep WhatsApp limited to a messaging platform only and remove the risk and limit the damage to Facebook itself. Next step moves to encourage WhatsApp users onto Facebook for group messaging type services.

Re: WhatsApp's Signal Protocol integration is now complete

#326

Post by Spakman »

davorb wrote: post #97
mike_hearn wrote: post #14

This is really excellent. A few thoughts: 1) They seem to have replaced TLS/SSL between client and server with "Noise Pipes". Based on a couple of minutes Googling this seems to be a brand new one-man protocol from Trevor Perrin (the same guy who did Axoltl on which Signal is based). At least, I'd never heard of it. I wonder if this is the first inkling of a post-TLS future? http://noiseprotocol.org/noise.html 2) It'…

> What's the next step? Imho one thing that the Signal project suffers from -- and that a lot of open-source projects suffer from -- is poor documentation. They need document their protocol better, to make it easier for third parties to integrate with their system. Signal still lacks a working desktop client (no, the one that you can use if you're running Chrome doesn't count), and I'm sure tons of people would be ea…

I agree about the documentation and a number of other things, but why doesn't the Chromium extension count as a desktop client? You don't need to use Chromium for anything else if you don't want.

Re: WhatsApp's Signal Protocol integration is now complete

#328

Post by Spakman »

nickik wrote: post #282
muppetman wrote: post #249

Earlier quoted context omitted.

It does support federation - for a while there Cyanogenmod ran their own Signal (then called TextSecure) server and built it into the Cyanogenmod source. It supported federation with Signal. But they removed it as the hassle of supporting the server was hard, the code was outdated and everyone agreed if you wanted that level of security, just install Signal yourself.

So, yeah, they had federation. That seemed to be a bit hacky, not proper federation, it was not designed to scale. Maybe Im wrong, I would like to hear somebody that knows more.

I would really, really like to hear more about federation in Signal too. They used to mention that it was planned, but that was a while ago now.

Re: WhatsApp's Signal Protocol integration is now complete

#329

Post by pfg »

mike_hearn wrote: post #322
pfg wrote: post #69

Earlier quoted context omitted.

I keep wondering if package managers (be it Google Play, apt or dnf) are in need of a solution like Certificate Transparency. Like Certificate Transparency, it would not necessarily prevent a backdoor(/certificate) from being pushed to selected users, but it would guarantee detectability, at least after the fact. If the package as a whole is included in the log, it would also allow BinDiff-style reverse engineering o…

It would be interesting but I suspect ultimately futile. Certificate transparency works because detected problems are actionable: the bad certificates can be revoked and, if necessary, so can the entire CA that was compromised. There is no way to revoke an app store, as there's only two of them that matter. So if the transparency system revealed subversion .... then what? There'd be a big uproar for a few days, but n…

I think the actual implications wouldn't be too different in production.

Those are the main scenarios where Binary Transparency might be of use:

1. An application developer's private key gets compromised (either through a breach or an inside job). Binary Transparency would allow the developer to monitor the log server for any unauthorized binaries and, once detected, investigate the source of the attack, rotate keys and possibly blacklist the affected binary (not sure if a mechanism like that exists at the moment, but it would make sense with Binary Transparency).

2. The application developer is coerced into signing a binary including a backdoor. Binary Transparency would guarantee that there's a public record of a modified binary being released. This alone would probably make any adversary think twice about doing this, especially if they want to stay unnoticed. In addition to that, gossip protocols and dedicated auditors could allow users to detect odd releases even if the developers were gagged. This might very well result in the app being effectively revoked because users stop trusting it.

Both scenarios would at the very least allow the backdoor to be reverse-engineered.

Ultimately, I'm afraid you're probably right and the limitations and complexity of this approach probably won't make it viable for a long time. Maybe the thinking will change if we see some high-profile cases where apps are backdoored - that's what got the ball rolling for Certificate Transparency, after all.

Re: WhatsApp's Signal Protocol integration is now complete

#330

Post by somesay »

hollander wrote: post #215
ngrilly wrote: post #174

Excellent! 3 questions: - What if the government forces WhatsApp to write and push a targeted software update in order to compromise the end-to-end encryption (I'm of course thinking of the FBI vs Apple case)? Is there a way for the user to be notified? - Does WhatsApp Auto Backup encrypt messages before sending them to Google Drive or iCloud? - Would it be possible for WhatsApp Web to rely on backend servers storing…

> - Does WhatsApp Auto Backup encrypt messages before sending them to Google Drive or iCloud? So you make a backup and loose the phone. What about the key? Is that gone too? Without it, encrypted backup is useless. How do you backup the key? You and me maybe will manage to do this, but what about grandma and all those people without anybody close who knows about this?

You could backup the key like every other account password, too. Save it in your password manager, print it. Whatever. This isn't really an argument.

When Android backups Wifi passwords, those are encrypted with your Google password that Google has only a hash of. Okay, it's easily interceptable the next time you login and Google has an warrant. But still an option.

Post reply on HN