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/
Axolotl is cool in a techy/underground sort of way (if your into that) but completely misses the boat on being 1) Easy to spell, 2) easy to pronounce, 3) easy to understand.
Mainstream users would just say "wtf" and move on to whatsapp/telegram/facebook messenger.
"Axolotl" at least has seriously pronunciation issues so I am glad it is not used "user-side".
It's also just a cool name.
In fact, axolotls only metamorphose into salamanders if triggered by the external environment. If you don't stimulate them in the right way, they stay axolotls. For a long time they were thought of as two different types of creature completely.
There's a story of one of the very early researchers looking at his vivarium one day and discovering that it was now full of salamanders rather than the axolotls he was expecting. I would love to have heard the conversation...
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...
Edit: yes, it's a suffix (for Classical Nahuatl): "Non-possessed nouns take a suffix called the absolutive. This suffix takes the form -tl after vowels (ā-tl, "water") and -tli after consonants [...]" ([2]).
0: https://en.wikipedia.org/wiki/Nahuatl#Phonology
1:https://en.wikipedia.org/wiki/Voiceless_alveolar_lateral_aff...
I don't understand what you're thinking of here? Here are some Latin nouns, all in nominative case:
nauta (first declension)
puer (second)
gladius (second)
malum (second)
lex (third)
limen (third)
tempus (third)
virtus (third)
civitas (third)
cornu (fourth)
manus (fourth)
res (fifth)
> Most importantly, they anticipated the web 2.0 trend of ending words with two consonants in a row. ;)
But those words (coyote, mesquite, tomato, and avocado, unless I seriously miss my guess) all end in a vowel.
Because they were adopted by Spanish speakers. English products using these names could either adopt the Spanish form, or as the GP suggest follow the 2.0 trend and recover the original form, publishing their webpage in the East Timor .tl domain.
"Signal" in IT usually means UNIX inter-process communication.
Noise starts from a clean state with modern knowledge of cryptography and modern cryptography. Much easier to understand and replicate, much harder to shoot yourself in the foot with.
TLS brings modularity and evolutivity, much needed in a protocol the scale of HTTP. In Whatsapp's case, Whatsapp controls both the server and the client; it is much easier to transition between versions because all bricks are under control. When you don't need what TLS brings anymore it makes sense to discard it.
As another example: Tarsnap (https://www.tarsnap.com/) uses spiped (https://www.tarsnap.com/spiped.html), a very simple yet powerful mechanism to build an encrypted channel. Its protocol and proof fit in ~100 lines (https://github.com/Tarsnap/spiped/blob/master/README). When you don't need all the jazz provided by TLS (and when you're lucky enough to be able to pre-share keys, which helps a lot) then a simple protocol is good.
You're right that it's not a good idea for generalists to pick up Noise and go to town with it. Noise isn't misuse-proof.
Nor is SSL. Couldn't an opinionated SSL library (supporting exactly one protocol version, one cipher only, etc) provide the same simplicity of use while remaining interoperable and reusing an already-validated protocol?
It's not the choice I would have made, but I am not as good as Moxie or Trevor.
The idea is more or less what you want, hardcode some known-good configuration for servers that can't or won't be upgraded every other month.
I would argue it's easier to shoot yourself in the face trying to re-implement/re-design something like TLS.
Maybe not all of WhatsApp's platforms support the latest TLS improvements though, thus it's easier to roll their own?
As an aside, what's with Nietzsche? He seems to crop up in your screenshots quite frequently.
(just a guess)
https://twitter.com/JZdziarski/status/717399098563891200
Is that true? Are the messages decrypted server-side for iOS users?
And for anyone else that hates visiting these social networks, Moxie's reply was, "I'm sure, but it'd be to everyone's benefit for you to verify."
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 eager to do stuff like provide integration for Pidgin if only there was better documentation.
[0] https://conversations.im/omemo/
[1] https://conversations.im/xeps/multi-end.html
[2] http://mail.jabber.org/pipermail/standards/2015-November/030...
This would solve part of the trust issue both for proprietary and open source software (I mean, who's actually using or verifying reproducible builds?). It would also be a huge problem for intelligence agencies or other adversaries who want to do this undetected.
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.
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.
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.
How would whatsapp know what language to present the words in?
"Ok, your pattern is Bread Cloud Tiller..." "Scheiße! We're being MITMed! My pattern is Brot Wolke Pinne..."
Alternatively, the party whose code is being confirmed would just select the language, and the other party's UI could automatically update to show the code in the chosen language. The first party would still have to pick a language both people understand but (as long as both parties have a working internet connection) there wouldn't be a sync issue.
> They do speak a common language, it's usually just not English.
I think you misunderstood the original poster was getting at. Here's the full parenthetical: "(perhaps with icons instead of specific words? if you don't speak a common language with your chat partner then the app is useless anyway)". So replace the words that you're supposed to read with little pictures. Then it doesn't matter what language the people speak as long as they're speaking the same language, since they'll be "reading" the images. You'll see a little house icon, and read "house" or "casa" or "jia" or whatever.
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.
In contrast, in CONIKS, a user had to check every single epoch. Which was impractical and meant you relied on third party auditors.
This doesn't deal with the restore from backup issue. I think given the FBI apple phone issue though, maybe it's worth reevaluating the risk vs. reword here. Especially if user visible warnings are opt in.
I've wonder if things like multi-device support or deriving a private key from a passphrase (mini-lock style) will eventually make user identity far less likely to change. Then it might be safer to complain louder when your in the situation that someone's identity has changed.
There's a QR code representation as well that can be scanned to verify.
They're unified, they're mostly language-agnostic, and there is shitload of them so the representation would be much more compact than hexadecimal or base64-encoded string.
Put it on a .io domain for bonus points.
If those only'd be international, I'd seriously propose key fingerprints based on animated meme-filled "gifs". Because that's what the common audience understands (or at least my impression is so). Not some weird-looking strings of meaningless digits and letters.
The notion of a cryptographic protocol framework, rather than a complicated negotiation scheme for a kitchen-sink protocol, is also somewhat novel.
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...
One example: WhatsApp is one of the primary messaging services used in Brazil, with something like half the population using it. The vast majority of which don't speak any languages other than Portuguese.
When the courts in Brazil shut down WhatsApp for 48 hours, there was a huge outcry because it is THE primary means of communication for people, especially to talk to family who have gone abroad.
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). Each word is mapped to a byte and then a blob of binary data becomes a nonsense word.
So for example "tasfyn-partyv" instead of "1242B24A".
The first I encountered that was in SILC, where it was used to make the key fingerprint more or less pronounceable. It's interesting that the encoding scheme never really got wider attention, although it is available in both openssh and openssl.
Similar ideas come and go, and get rediscovered - so maybe now is the time for wider acceptance.
A bit of googling provided me with a nice starting point for implementations, so babble print has certainly been recognised in some circles.[1]
That only works in English, again.
Of course that's not helpful when two people who don't speak a common language are trying to establish communication, but it probably isn't their biggest problem.
They already spent a bunch of time and effort finding these phonemes to build Esperanto, right?
Its choices are large, irregular, unclearly defined and basically Eastern Polish.
Lojban is designed to be well-defined on phonemes, but that still only works when knowing its (rather simple) pronunciation rules.
[1] http://web.archive.org/web/20090918202746/http://tothink.com...
Is there any work on encrypting group chat sessions?
Maybe the next step is a more obvious indicator.
They do this to prevent degradation attacks.
Don't know what kind of funding they've been having, but for an open-source app, it's pretty polished.
So I fail to see the problem. It still likely protects you from nosy neighbors or nasty non tech savvy competitors, even if it doesn't protect you from state level actors or from Facebook itself.
The above, in addition to the fact that open source is neither required for auditing, nor guarantees proper auditing occurring (see OpenSSL having vulnerabilities for years before anybody released them to the public)
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'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 instead of specific words? if you don't speak a common language with your chat partner then the app is useless anyway).
3) What's the next step? My feeling is that the next step is securing the build and distribution pipeline. WhatsApp could partner with security firms around the world, like Kaspersky Lab in Moscow, perhaps one in Germany and another in Iran, to make it harder for the software to be forcibly backdoored by a single decision of a single government representative. This would require splitting the RSA signing keys used by the app stores. I have some code in my inbox that claims it can do this (it's written by some academics and I obtained it after a bit of a runaround) but I never found the time to play with it.
Of course, getting a bunch of security firms to sign off on every update, no matter how trivial that update is, might prove politically difficult inside Facebook. If mobile platforms supported in-app sandboxing better then the app could slowly be refactored to be more like Chrome, where the base layer doesn't trust the upper layers. Those upper layers wouldn't have access to key material and could then be updated more freely than the higher privileged components.