Hacker News Reader

Comment by meowface | Hacker News Reader

Even if Telegram's explanation did stand up to scrutiny and was ran by experienced cryptographers, the fact that its core code is closed source makes it utterly worthless from a security perspective. They can tout their own security all they like, but if no one else can independently verify it then it means nothing.

So far they've only published the source to their client, but their servers do all of the actual processing and cryptography.

All of Moxie's projects, on the other hand, have always been completely open source.

View on HN

Open source doesn't imply trustworthiness and it's a very dangerous assumption to make.

Any open source system can be screwed with in a variety of ways. The simplest and most effective option is to publish both the source and the binaries, but built latter from the an altered source. This will work in a vast majority of cases, because a lot of people make this ridiculous assumption that publishing the source automatically implies that the guy is good, open and trustworthy all over. And won't bother verifying the binaries. Virtually everyone will assume that since it's open there will be someone who will do the verification. Guess what? That someone will assume the same thing.

That's your good old social engineering. It's the humans that are exploitable, not the tech.

But let's say, as unlikely as it is, this such person materialized. Easy enough to run an independent build and verify the binaries, right? Sure. In theory. In a lot of cases, due to dependencies, it's either hard or nearly impossible to do. In other cases it translates into an non-trivial amount of work, which needs to be justified. I am aware of just one project - PGPfone - that published not just the code, but the exact build instructions to produce matching binaries. Everything else is just the "open source, trust us" model. And so the bottom line is that in heck of a lot of cases you will not be able to produce matching binaries.

Now, even if the binary difference in just several bytes that is 100% enough to screw everyone over. This is done by messing with an initialization of an internal random number generator, which all crypto stacks have. All you need to do is make the PRNG (semi)predictable and the best crypto won't stand a chance as there'll be no secrets.

In the end, if you are using pre-made binaries (and who doesn't?) that are not built by a trusted entity from a specific peer-reviewed snapshot of the sources, you have the exact same chances of running a flawed version regardless of whether its source is open or not. Except that in a closed source case you are likely to be more on guard for the surprises.

I am not saying open source == secure. Rather, closed source == impossible to know if secure. Making something open source doesn't instantly add a "secure" tag to it, but keeping it all closed leaves no chance for the tag to even appear.

With open source you can get intelligent, experienced experts to look through it. And if enough of them look through it and say it's good (for example, as many experts have done with the Bitcoin client and protocol), you can at least gain some degree of assurance, even if the possibility of a critical exploit being found in the future still always remains.

Also, you are right in that in this particular scenario, open source would only be the first step as you couldn't know if their servers are actually running the source they published. Open source + full end-to-end encryption and authentication are both required, as is the case with OTR and Moxie's project.

> This will work in a vast majority of cases, because a lot of people make this ridiculous assumption that publishing the source automatically implies that the guy is good, open and trustworthy all over. And won't bother verifying the binaries.

Probably worth linking to Ken Thompson's Reflections on Trusting Trust paper, which illustrates exactly what you're saying with a hypothetical (or not) C compiler backdoor.

http://cm.bell-labs.com/who/ken/trust.html

"You can't trust code that you did not totally create yourself [...] No amount of source-level verification or scrutiny will protect you from using untrusted code"

For me, the following lines also stood out:

"I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."

Presumably to would be possible to introduce a bug into every CPU manufactured, that even the manufacturer is unaware of.

Even scarier, researchers have shown that there are ways of backdooring CPUs via transistor doping so that even if the manufacturer suspects a backdoor, it may still be very difficult for them to find it: http://www.techrepublic.com/blog/it-security/researchers-cre...

Full paper: http://people.umass.edu/gbecker/BeckerChes13.pdf

Interesting. The "doping" attack seems to be aimed specifically at random number generating circuits. Presumably such attacks could be definitively detected by using the RNG to generate a long sequence and checking that the distribution of probabilities is as expected [1]? Is my understanding correct?

[1] http://www.johndcook.com/Beautiful_Testing_ch10.pdf

Reading the paper, it sounds like the attacker can make the trojan arbitrarily hard to detect, in exchange for making the resulting encryption harder to crack.

In the attack they describe, Intel's hardware RNG is supposed to return the results of encrypting 128 random bits using a 128-bit random key with the AES cipher. So an attacker trying to guess the random number returned would have to try 2^256 options. Instead, the attacker modifies the chip so it returns the results of a known key used to encrypt n random bits and 128-n known bits. They therefore only have to try 2^n options -- they can make guessing the random number as easy or hard as they want for themselves.

Now the AES part makes the results of the hacked chip appear random -- the results of AES(0), AES(1), AES(2) ... will have a random distribution in the 2^256 range. (The whole point of a cipher is that it should be impossible to draw any conclusions about the inputs by examining a bunch of outputs, even if the inputs are predictable.) To detect it in software, we'll have to generate enough numbers to start to see a suspicious number of repeated results. So if the attacker sets n==2, they'll have a really easy time cracking the resulting encryption, but we'll easily detect it -- we'll quickly notice that the RNG always returns one of four numbers. On the other hand if they set n==32, they'll have to try n^32 options to crack the resulting encryption, but there will be few enough repeats that we'll give up testing before we notice anything is wrong. (Of course if they're more paranoid and have better resources, they could go with n==64 or whatever -- it's like a dial they can use to set the difficulty where they want it.)

The neat thing here, of course, is that this backdoor is only valuable if you know the bits that have been hardcoded into the chip. So it remains secure against everyone in the world, except the one three-letter agency that managed to modify the chip.

Or their private contractors and consultants, I suppose.

"but their servers do all of the actual processing and cryptography"

I realize t'is the season to to piling on to the hapless Telegram folks, but I think that assertion is wrong.

Do you consider an HTTPS connection to be "their servers do all of the actual processing and cryptography"? Most people would (even though there are subtleties to reality) and Telegram certainly qualifies under whatever you consider HTTPS doing.

The only real difference is the usage of client keys and a custom protocol.

It's really not even enough to open source their server software because you would still have to trust that they ran that open source software unmodified on their machines.

Yep, that's also absolutely true. You'd have no idea if their servers were actually running the code they published.

Moxie's TextSecure on the other hand does full end-to-end encryption, with no work done by any server. Same with OTR and similar message encryption plugins. It baffles me why people are sticking to the "everything on the server" route for applications that focus on user privacy and security in this day and age, especially when there are a lot of good alternatives that don't.

They're going the 'everything on the server' route because this application is meant to compete with messaging services rather than appease the 'small crowd of crypto enthusiasts' as they have already stated.

If you host your own server with their server software, you can verify it's running unmodified.

They don't provide the server-side code, nor a way to ensure that your client is talking to a specific server. The only authentication is via a 5 digit code sent via SMS, so it's presumably very easy to spoof and control messages. You need on average 5000 attempts to log into another users account (they are send a "new device added" notification message though), which could be done reasonably easily if you knew a person would have their phone off for a period of time when you wanted to attack their account.

Wait the crypto is done server side? I haven't really looked into Telegram much, but that's fucking silly. Lavabit all over again.

This can't be right. Server-side crypto? I.e. client transmits to the server in plaintext? Surely no one is that clueless about cryptography.

its not done server side

Eh, yes and no. It's not sent in plain text to the server. However, in the sense that it's 'Lavabit all over again', or at least a procedure that produces isomorphic problems, the encryption seems to be being done server-side:

--------------------------

'The difference between messages in Secret Chats and ordinary Telegram messages is in the encryption type: client-client in case of Secret Chats, client-server/server-client for ordinary chats. This enables your ordinary Telegram messages to be both secure and available in the cloud so that you can access them from any of your devices — which is very useful at times.'

https://telegram.org/faq#q-why-not-just-make-all-chats-secre...

--------------------------

I have trouble construing that other than in you use the server's key to encrypt the message you send and then server encrypts it with the public key associated with the addressees' device at the time.

...

This seems to produce the same problem LB had in that you can be asked to turn over the keys to the messages on your server. And for similar reasons, you're doing encryption on your server.

Given that LB had that trouble, I also have difficulty seeing any non-malicious reason for solving the key distribution problem this way. Since you can set up secret chats that are end to end encrypted you could equally have asked the client's devices to exchange a private key using each others' public keys.

I'm tempted to explain it away in terms of the user being expected not to be technically savy enough to press the buttons on both devices when asked to do so. - But the client knowing about and using encryption in the first place implies at least some sort of technical competence which I would imagine is great enough to press two buttons when a prompt comes up saying something like:

'The device DEVICE NAME is asking for the key to read your messages.

If you did not try to set up your mail on another device within the last minute, press the REPORT ATTACK button.

Else press the ALLOW button.'

Still, I've overestimated the average intelligence of people before.

Reply on news.ycombinator.com