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

161–170 of 386 posts

Re: WhatsApp's Signal Protocol integration is now complete

#161

Post by mahyarm »

baby wrote: post #142
moxie wrote: post #20

Earlier quoted context omitted.

> They seem to have replaced TLS/SSL between client and server with "Noise Pipes". WhatsApp was already using a custom protocol instead of TLS. We worked with them to transition over to Noise Pipes, which has some advantages over what they were doing before. Also, we've renamed Axolotl to Signal Protocol: https://whispersystems.org/blog/signal-inside-and-out/

What's the incentive of not using TLS?

About 6 round trips, which gives you about a 30s latency on EDGE networks. Doing a key exchange once, retaining it and then doing future communications with just 1 round trip is significantly faster.

Re: WhatsApp's Signal Protocol integration is now complete

#162

Post by free2rhyme214 »

sidcool wrote: post #146
moxie wrote: post #140

Earlier quoted context omitted.

By default, Telegram stores a plaintext copy of every message you've ever sent or received on their servers. WhatsApp does end to end encryption using the Signal Protocol by default, and doesn't store anything server side.

Cool. So FB/WhatsApp can't even decrypt messages themselves?

He never said that ;)

Re: WhatsApp's Signal Protocol integration is now complete

#163

Post by kodablah »

elasticdog wrote: post #68
martindevans wrote: post #29

Earlier quoted context omitted.

> It's a shame to see key words be killed off by internationalisation concerns [....] I hope further research here can develop better replacements for encoding short binary strings in i18n friendly ways I rather like the urbit way of encoding numbers. I can't remember the exact details but it's something like: There are 256 unique three letter words (all nonsense, but deliberately picked to be possible to pronounce).…

Still western-focused, but Oren Tirosh's mnemonic encoding [1] project is pretty close as well. [1] http://web.archive.org/web/20090918202746/http://tothink.com...

Similarly, proquint.

Re: WhatsApp's Signal Protocol integration is now complete

#164

Post by tveita »

tptacek wrote: post #87
pilif wrote: post #59

What the article fails to mention: 1) I would assume Facebook still gets unencrypted access to my address book for use with their shadow profiles 2) We have zero control over what key the client encrypts the messages for. Is it only the other peer's phone? Or is it for the peer's phone plus Facebook for analysis of the messages? Especially 2) is of some concern to me (against 1 I can't protect myself anyways because…

I think this is a reasonable analysis. I would refine it this way (examples are only for illustrative purposes): Tier 1 secure messengers: all possible tradeoffs in favor of security made; use for worst-case adversaries: - Signal/TextSecure - Pond - PGP† - OTR Tier 2 secure messengers: serious secure messaging protocols that make some tradeoffs in favor of adoption and usability; use for normal messages of low sensit…

I would place Signal in the same tier as WhatsApp here (Tier 2). They both upload your contacts to an intermediate server that gives you their public key, which you can optionally verify afterwards.

This means a malicious server could both store away your contacts and try to MITM you, risking detection if you do verify your fingerprint with the other party.

A messenger that really did "all possible tradeoffs in favor of security" would force you to verify the recipient, either in person or via a web of trust. I think not doing that is a perfectly acceptable tradeoff to protect 1 billion users from passive mass surveillance.

These are all UI issues though, the Signal protocol seems solid, and I'll be glad to see it used everywhere. Hopefully we will get clients that you could recommend to a journalist or lawyer and have confidence that they will be able to use it for secure authenticated communication.

Re: WhatsApp's Signal Protocol integration is now complete

#165

Post by jamesdwilson »

zanny wrote: post #135
jamesdwilson wrote: post #44

Earlier quoted context omitted.

no proof without open source

Matrix uses the Signal protocol for encryption as well, if you want a fully free implementation of the same tech. https://matrix.org/git/olm/

thanks! could i use it to connect to WhatsApp?

Re: WhatsApp's Signal Protocol integration is now complete

#167

Post by jd20 »

baby wrote: post #142
moxie wrote: post #20

Earlier quoted context omitted.

> They seem to have replaced TLS/SSL between client and server with "Noise Pipes". WhatsApp was already using a custom protocol instead of TLS. We worked with them to transition over to Noise Pipes, which has some advantages over what they were doing before. Also, we've renamed Axolotl to Signal Protocol: https://whispersystems.org/blog/signal-inside-and-out/

What's the incentive of not using TLS?

I'm curious about this too. Short of some rigid technical requirement, it's hard to imagine why you'd want to reinvent the wheel or forgo a protocl which is so widely available and studied. (Although I've not read the Noise whitepaper though, I'm sure it must have some benefits compared to TLS.)

Re: WhatsApp's Signal Protocol integration is now complete

#168

Post by tptacek »

tveita wrote: post #164
tptacek wrote: post #87

Earlier quoted context omitted.

I think this is a reasonable analysis. I would refine it this way (examples are only for illustrative purposes): Tier 1 secure messengers: all possible tradeoffs in favor of security made; use for worst-case adversaries: - Signal/TextSecure - Pond - PGP† - OTR Tier 2 secure messengers: serious secure messaging protocols that make some tradeoffs in favor of adoption and usability; use for normal messages of low sensit…

I would place Signal in the same tier as WhatsApp here (Tier 2). They both upload your contacts to an intermediate server that gives you their public key, which you can optionally verify afterwards. This means a malicious server could both store away your contacts and try to MITM you, risking detection if you do verify your fingerprint with the other party. A messenger that really did "all possible tradeoffs in favor…

That's something that's at least somewhat true of OTR and PGP too, in their normal use, and in all three cases if you're serious about OPSEC you can completely mitigate the problem. So in my evaluation, Signal's a tier 1 option, and WhatsApp is tier 2.

Reasonable people can disagree, of course.

I hope it's obvious that, since OTR is in tier 1, these tiers aren't an analysis of how much I like different messengers. :)

Re: WhatsApp's Signal Protocol integration is now complete

#169

Post by Johnny_Brahms »

erichocean wrote: post #138

Signal's stuff is all GPL'd (AFAIK). Does this mean that WhatsApp's clients (and whatever else would apply) are also released under the GPL?

I doubt it. The protocol is well defined, and a single developer could probably copy in in a reasonable amount of time. I guess that is what whatsapp did.

Re: WhatsApp's Signal Protocol integration is now complete

#170

Post by pa7ch »

ianmiers wrote: post #128
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'm hoping they deploy some from of key transparency. E.g. CONIKS or CONAME, the version Yahoo and Google are working on for e2e that already has a productionish grade sever and client[0]. Either that or give the community a practical reason why it can't be used as is, and then we can start working on alternatives. [0] https://github.com/yahoo/conam

I think he already made a strong point why CONIKS style transparency isn't all that great for end-users. See this mailing list thread that includes the author of CONIKS talking about it with moxie before CONIKS was published:

https://moderncrypto.org/mail-archive/messaging/2014/000226....

https://moderncrypto.org/mail-archive/messaging/2014/000234....

Basically, users change their identity key in practice so often that a 3rd-party can't be the source of truth on whether a MITM has happened. Only the user can audit that and most users are not equipped to do so. So, towards the goal of universal e2e messaging its not clear that key transparency is a real win over the simplicity of trust-on-first-use.

Post reply on HN