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

Telegram - secure, free messaging

telegram.org

Post reply on HN
Print view View original

101–110 of 231 posts

Re: Telegram - secure, free messaging

#101

Post by ge0rg »

TelegramApp wrote: post #92
micheljansen wrote: post #73

Earlier quoted context omitted.

In this case, even if you remove the ad-hominem attack (a bunch of randoms), a valid point remains: implementing crypto is already notoriously difficult, let alone designing cryptographic protocols.

Still, there are sometimes valid reasons for not re-using existing solutions. In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability. Disclaimer: I work for Telegram.

It is a really bad idea to compromise security for speed and connection stability. Processing power is a question of scaling the hardware, communication speed is hardly affected by a proper encryption scheme, neither is reliability of the application-layer protocol.

Usability, however, is a different beast. You must compromise security to make a chat application appeal to "regular" users. Still, this is a trade-off that can be clearly communicated to the user and to developers, and does not require a custom crypto protocol. You can achieve the same effects with using existing and tested libraries.

Edit: Disclaimer: I am the developer of the yaxim Android XMPP client and the operator of the public yax.im XMPP server (both available at http://yax.im).

Re: Telegram - secure, free messaging

#102

Post by gr3yh47 »

na85 wrote: post #7

From their FAQ: > Q: How secure is Telegram? > Very secure. We are based on a new protocol, MTProto, built by our own specialists from scratch, with security in mind. At this moment, the biggest security threat to your Telegram messages is your mother reading over your shoulder. We took care of the rest. Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point.

With all the revelations of built in weaknesses and such with existing encryption schemes... I don't know. I think we need a new one.

That said, it should probably be developed by a panel of experts. I would love to see something by Bruce Steiner et al, where 'et al' is a group that he selects. As you pointed out a group without heavy crypto experience can't realistically roll their own and have it actually be secure.

Re: Telegram - secure, free messaging

#103

Post by jzwinck »

kitd wrote: post #45
sillysaurus2 wrote: post #33

Earlier quoted context omitted.

He's done nothing in crypto, and he's rolled his own protocol. That's historically been recipe for disaster regardless of how many honors you hold. Colin Percival is similarly decorated, along with being a cryptographer (he's the FreeBSD security officer): http://www.daemonology.net/papers/ ... yet even his crypto app Tarsnap was broken for over a year before he noticed, due to a typo during an innocent-looking refac…

You are correct to be wary. However, the MTProto java impl is here: https://github.com/ex3ndr/telegram-mt

Great, let's take a quick look.

TcpContext.java[1] says:

    MAX_PACKED_SIZE = 1024 * 1024 * 1024;//1 MB
    READ_DIE_TIMEOUT = 5 * 1000; // 15 sec
So those are bugs, though I'm not sure if documentation or code. Most importantly to me, there are very few comments in the code, and the few there are are incorrect. One might infer that this code has been written either in haste, or by someone who believes that comments are not needed in this sort of systems code.

There are also writeInt() and readInt() method which seems to be little-endian, which seems odd for a network program. No comments near them.

Finally, there's a "Package" class which is just a byte array and a flag. And there's a method which writes it after a cute encoding for the length divided by 4. But there is no code which checks that the length is evenly divisible by 4. This may lead to incomplete Packages being written, with what effect I am not sure.

In summary, I wouldn't trust this program, having reviewed one of its source files mostly at random.

Oh, and despite its README saying that it is designed for mobile, it uses TCP Keep-Alive, which seems like a bad idea for mobile specifically (due to keeping the radio alive and draining the battery). Again, no comments explaining why.

[1] https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j...

Re: Telegram - secure, free messaging

#104

Post by veeti »

TelegramApp wrote: post #88
gprasanth wrote: post #5

Is HTTPS not secure channel for communication between client-server? What is the reason behind using an entirely different protocol for client-server communication[0] over HTTP? [0] - http://core.telegram.org/mtproto

The main reason is speed. MTProto is designed to work fast on weak mobile connections. Another reason is security, with HTTPs you need to trust more parties.

> Another reason is security, with HTTPs you need to trust more parties.

No, you don't. Use a self-signed certificate that is hardcoded in the app.

Re: Telegram - secure, free messaging

#105

Post by huhtenberg »

TelegramApp wrote: post #84
huhtenberg wrote: post #22

Looking at [1], it has several red flags. The replay protection is overly complicated and doesn't kick in after the message is decrypted. This makes it possible to DoS the server with forged messages. Key derivation uses a custom scheme. Typically there's no reason NOT to piggy-back on existing schemes and there's plenty to choose from - from TLS to IKE. Also, as already mentioned, there's again NO reason not to use…

The reason for designing something new was this: in order for really secure messaging to catch on among the masses today — it needs not only be secure. When you want to compete with the likes of WA, you also need be fast and reliable on weak mobile connections. TLS/HTTPS is slow and takes a lot of time to restore connection on fragile networks. MTProto was born as a result of an experiment: whether it would be possib…

This is all great, but it reads like a marketing speak. There was this imperfect world full of idiots, slow, ugly and dim lit and then we came along and lifted the gloom.

Sorry, you have to do better than "TLS/HTTPS is slow". Anything over TCP is slow on congested and lossy networks. That's given, but that's hardly a reason to reinvent the whole crypto stack.

How is your protocol superior / faster / better than DTLS with session resuming? Is it faster than IKE in Quick Mode or IKE v2, which are both datagram protocols designed to work over lossy networks? What are the inherent problems with adopting DTLS or IKE to your purposes? This is dead easy to do without touching original crypto design and it instantly removes all questions pertaining to the quality of your crypto design. So why not?

I'm not a professional cryptographer, but I know applied crypto well and I've seen my share of custom crypto designs. Virtually ALL of them are is a result of thinking that it's better and easier to invent something new than to diligently learn what exists and understand how it works. It's fine for some areas, but it is decidedly not a way to go in the cryptography domain.

Re: Telegram - secure, free messaging

#107

Post by ge0rg »

I have not run the app, but from the Android source code it looks like this "secure" app is uploading your contacts including full names and all their phone numbers into the "cloud":

MessagesController.readContacts() [0] is called on creation of the MessagesActivity. When invoked for the first time, it collects first names, last names and phone numbers from the Android Contacts interface, creates a table containing the data, and passes that to importContacts() [1], which performs an RPC call to "the cloud", passing the contact list upstream and obtaining a server-processed list as a reply.

For me this is a major trust breach, and makes all the fuzzy claims about the app's security absolutely worthless.

[0] https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

[1] https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

Re: Telegram - secure, free messaging

#108

Post by bnr »

na85 wrote: post #7

From their FAQ: > Q: How secure is Telegram? > Very secure. We are based on a new protocol, MTProto, built by our own specialists from scratch, with security in mind. At this moment, the biggest security threat to your Telegram messages is your mother reading over your shoulder. We took care of the rest. Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point.

They did not roll their own crypto, it's using AES with Diffie-Hellman key generation. [0]

You can now argue whether that's still "from scratch". (Is building something on top of TCP "from scratch"?)

[0] http://core.telegram.org/api/end-to-end

Re: Telegram - secure, free messaging

#109

Post by carsonreinke »

na85 wrote: post #7

From their FAQ: > Q: How secure is Telegram? > Very secure. We are based on a new protocol, MTProto, built by our own specialists from scratch, with security in mind. At this moment, the biggest security threat to your Telegram messages is your mother reading over your shoulder. We took care of the rest. Oh good, a bunch of randoms have rolled their own crypto. I stopped reading at this point.

No, see this: http://core.telegram.org/mtproto

Re: Telegram - secure, free messaging

#110

Post by e12e »

ge0rg wrote: post #101
TelegramApp wrote: post #92

Earlier quoted context omitted.

Still, there are sometimes valid reasons for not re-using existing solutions. In our case, we needed something that is both secure and competitive in comparison to mass market solutions in terms of speed, working on weak connections and usability. Disclaimer: I work for Telegram.

It is a really bad idea to compromise security for speed and connection stability. Processing power is a question of scaling the hardware, communication speed is hardly affected by a proper encryption scheme, neither is reliability of the application-layer protocol. Usability, however, is a different beast. You must compromise security to make a chat application appeal to "regular" users. Still, this is a trade-off t…

Thank you for the plug for yaxim. I've been searching around for a "good enough" jabber client for android, and while yaxim isn't there yet (for me: no otr support, single server) it looks like it's headed in the right direction!
Post reply on HN