Live data from Hacker News

WhatsApp's Signal Protocol integration is now complete

whispersystems.org

191–200 of 386 posts

Re: WhatsApp's Signal Protocol integration is now complete

#191
post #131
post #34

Earlier quoted context omitted.

It is killing me that you didn't rename Signal to Axolotl.

Why? "Axolotl" at least has seriously pronunciation issues so I am glad it is not used "user-side".

Because words coming from Nahuatl are cool! (coyotl, mesquitl, tomatl, ahuacatl, etc.) See more from https://en.wikipedia.org/wiki/List_of_English_words_from_ind...

They’re distinctively spelled, don’t collide with existing search terms, often have available domains, etc. Most importantly, they anticipated the web 2.0 trend of ending words with two consonants in a row. ;)

Finally, just look at this guy: https://upload.wikimedia.org/wikipedia/commons/f/f6/AxolotlB...

Re: WhatsApp's Signal Protocol integration is now complete

#192
post #123

Earlier quoted context omitted.

> 12 words seems so much more friendly, at least to English speakers I have a feeling that English speakers are the minority of WhatsApp users. > if you don't speak a common language with your chat partner then the app is useless anyway They do speak a common language, it's usually just not English.

And the language of the clients might not be the same. I might write in English to a German friend, but my whatsapp is localized to Danish and his to Germany. How would whatsapp know what language to present the words in?

It could have a language picker. It's not like you're stuck with just one language; the underlying fingerprint could be converted into any language that has an appropriate dictionary constructed for it, so all you would have to do is ensure both parties have picked the same language and you can then compare the fingerprint easily.

Re: WhatsApp's Signal Protocol integration is now complete

#193
post #15

Earlier quoted context omitted.

> 2) It's a shame to see key words be killed off by internationalisation concerns. 12 words seems so much more friendly, at least to English speakers, than a 50 digit number. In practice I doubt any non-trivial numbers of people will ever compare codes by reading out such a number. I hope further research here can develop better replacements for encoding short binary strings in i18n friendly ways (perhaps with icons…

I feel like there are a lot of security issues with QR code representations, namely that the information are even less transparent than hexadecimal fingerprints, and therefore are not really a fail-safe to MITM attacks.

I'm not sure about this. If they can change what QR code you are seeing they can change the words as well.

Re: WhatsApp's Signal Protocol integration is now complete

#194
post #181
post #96

Earlier quoted context omitted.

> From that perspective, I'm still inclined to trust apple's iMessage a bit more especially after recent events. // edit: got my answer here: https://news.ycombinator.com/item?id=11432629 I'm curious, is that because of what they did in the FBI case, or for technical reasons? IIRC iMessage would allow Apple to add public keys which they (or the FBI/$ADVERSARY) control as a sort-of backdoor as well. I can't say that I…

The unfortunate reality too is that average users will never go to the extra trouble of authenticating keys themselves. I'm also more likely to trust a company like Apple or Google with key management than a "trusted third party" (simply because they're bigger companies, with more valuable brands to protect, and resources to throw at the problem). So, it feels like for the average consumer, a product like iMessage ti…

Manual authentication via QR (or comparing the digits) works on top of the server-side authentication. It does what iMessage does, but you also have the option to actually compare the fingerprints if you are so inclined.

Re: WhatsApp's Signal Protocol integration is now complete

#195

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'…

> It's a shame to see key words be killed off by internationalisation concerns.

I think it's actually a solid decision from WhatsApp since the majority of their users are from non English speaking countries[0].

[0]: http://www.statista.com/statistics/291540/mobile-internet-us...

Re: WhatsApp's Signal Protocol integration is now complete

#196
post #131

Earlier quoted context omitted.

Why? "Axolotl" at least has seriously pronunciation issues so I am glad it is not used "user-side".

Because words coming from Nahuatl are cool! (coyotl, mesquitl, tomatl, ahuacatl, etc.) See more from https://en.wikipedia.org/wiki/List_of_English_words_from_ind... They’re distinctively spelled, don’t collide with existing search terms, often have available domains, etc. Most importantly, they anticipated the web 2.0 trend of ending words with two consonants in a row. ;) Finally, just look at this guy: https://uploa…

Linguistic tangent: the common suffix on those words is interesting. Is it required for Nahuatl nouns, like the Latin -t suffix? I notice that not all the other example words on the linked page-section have it, but a large majority do.

Re: WhatsApp's Signal Protocol integration is now complete

#197
post #92

Earlier quoted context omitted.

You keep saying "source is a must" but you have yet to explain why that is the case.

I can't reply to your other comment for some reason, so I'm replying to this one. >If WhatsApp is so evil that they've backdoored their product Unless they want to go the way of Lavabit, every company is evil when kindly asked to be. (Well, maybe it helps when you have the weight of Apple, but that wasn't even a NSL if we heard about it.) >it is "supervillain monologuing for an hour while the hero escapes"-grade stup…

> I can't reply to your other comment for some reason...

Try clicking on the timestamp for the comment when you have this trouble. A reply box should appear.

Re: WhatsApp's Signal Protocol integration is now complete

#198
post #131

Earlier quoted context omitted.

Why? "Axolotl" at least has seriously pronunciation issues so I am glad it is not used "user-side".

For my part: because "Axolotl" is one of the most widely name-dropped terms in hipster cryptography, and because it's been adopted by other projects, and because it's distinctive, and because they basically own the term. In a stroke, everyone doing secure key ratchets would have been using their product . It's also just a cool name.

Thanks and I agree about that!

Re: WhatsApp's Signal Protocol integration is now complete

#199
post #184
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.

When you say Telegram servers store plaintext "by default", does that imply this is not also true of their "Secret Chat" feature? That mode appears to behave as if it's exchanging keys and doing end-to-end encryption... (I am aware of the Telegram flaws you and others have pointed out).

"Secret Chat" uses Telegram's (flawed) E2E protocol, so the server would only see ciphertext. A "normal" chat is stored in plaintext.

This is also why normal chats work in multi-device environments, but secret chats don't. Unlike iMessage (and I assume Signal - haven't looked at the actual protocol), they don't do anything fancy like making the sender encrypt messages with multiple public keys (one for each device the recipient owns).

Re: WhatsApp's Signal Protocol integration is now complete

#200
post #180

Earlier quoted context omitted.

Don't forget that Telegram uses custom in house encryption and they say "trust us", it's good. Telegram encryption can't be verified.

As long as the clients are open-source and the encryption is end to end, can't it really be verified? Whatever the server, if the client encryption is reliable, data can't be read on the server side.

  if the client encryption is reliable
It's not[1].

[1]: https://eprint.iacr.org/2015/1177.pdf

Post reply on HN