
Telegram - secure, free messaging - macalicious
http://telegram.org/
======
moxie
The reason that cryptographers laugh at people who advertise "military grade
cryptography" or "we use AES256" is because the choice of crypto primitives is
often less important than how they're composed. Those phrases tend to reflect
a critical misunderstanding of that, and often mean that a project is using
secure primitives in a way that completely undermines their security.

At a glance, while this project is using secure (if aging) primitives, they've
made some extremely unusual protocol choices that they need to publicly
justify rather than simply describing in an API doc. Just at a glance, the use
of modes like Infinite Garble Extension (a failed mode for Kerberos) is
troubling, they made up their own KDF (with no proof), and they make what
appear to be some amateur mistakes with how they use RSA.

I'm obviously biased, but if you want a mobile-oriented asynchronous messaging
protocol, at this point I think the Axolotl ratchet should absolutely be its
basis: [https://www.whispersystems.org/blog/advanced-
ratcheting/](https://www.whispersystems.org/blog/advanced-ratcheting/)

If Telegram folks are on this thread, I'd encourage you to take a look at the
TextSecure protocol. If you think it's interesting, you can federate into our
network, get a provably secure asynchronous forward secrecy protocol, and also
have access to an existing 10MM user base.

~~~
TelegramApp
Two questions for you:

1\. Kindly be more specific about our RSA implementation. Please note, that we
only use RSA with public keys, not private. If you are aware of any possible
attacks on this setup, please let us know.

2\. And what problems with IGE are you aware of? Any known attack? As far as
we know, it is the ubiquitous CBC that has had issues. And by the way,
Kerberos had to abandon PCBC - not IGE.

Thank you for the offer to join in the project you represent. However, we feel
that what we are doing is going in a somewhat different direction and has its
own potential.

The team behind Telegram, led by Nikolai Durov, consists of six ACM champions,
half of them Ph.Ds in math. It took them about two years to roll out the
current version of MTProto. Names and degrees may indeed not mean as much in
some fields as they do in others, but this protocol is the result of thougtful
and prolonged work of professionals.

The basic copy on telegram.org rightfully appears as simplistic to the Hacker
News resident. It was written for the general public, since we want to bring
secure messaging to the masses — not just to the security geek, who has it
already (in oh so many forms).

But for the technically minded we provided rather detailed documentation for
our protocol:
[http://core.telegram.org/mtproto](http://core.telegram.org/mtproto) and API:
[http://core.telegram.org/api](http://core.telegram.org/api)

We would be glad to respond to criticism, but not on the level of "I looked at
it for 4 minutes, maybe they didn't think about X" (as another guy in the
comments below put it), or "why didn't you just use this?".

If anybody here can identify a specific point and prove that it is vulnerable
and can be hacked a certain way, we are ready to respond and\or fix, if
neccessary. Gentlemen?

~~~
moxie
_> 2\. And what problems with IGE are you aware of? Any known attack? As far
as we know, it is the ubiquitous CBC that has had issues. And by the way,
Kerberos had to abandon PCBC - not IGE._

IGE was the first attempt at an "authenticating encryption mode," originally
for Kerberos. It was a failed attempt (it does not provide integrity
protection), and had to be removed. That was the beginning of a 20 year quest
for an authenticating encryption mode that works, which recently culminated in
modes like OCB and GCM. I don't see any integrity protection documented
anywhere in your protocol spec, so if you're relying on IGE, it's broken.

What's more, any "problems" with CBC (I assume you're referring to padding
oracle attacks) are not specific to CBC, and are endemic to IGE as well.

 _> The team behind Telegram, led by Nikolai Durov, consists of six ACM
champions, half of them Ph.Ds in math. It took them about two years to roll
out the current version of MTProto. Names and degrees may indeed not mean as
much in some fields as they do in others, but this protocol is the result of
thougtful and prolonged work of professionals._

I don't think their academic credentials or the amount of time they spent on
this are the important metrics. If you're trying to suggest that they're
thoughtful, the best metric for demonstrating that would be something like a
proof for the (honestly naive-looking) KDF they made up.

In essence, the protocol seems to reflect many choices that anyone familiar
with the field can immediately identify as suggesting a lack of understanding.
It could be that these are simply brilliant moves that we non-ACM champions
are too primitive to understand, but if that's true, you need to justify them
with proofs in order to support them. Otherwise we're going to interpret them
for how they appear.

 _> Thank you for the offer to join in the project you represent. However, we
feel that what we are doing is going in a somewhat different direction and has
its own potential._

Could you describe how your projects objectives are inconsistent with a
protocol ratchet like Axolotol or the full TextSecure protocol?

~~~
TelegramApp
2\. A passing look at the docs would reveal that we do not use IGE that way,
and instead use SHA1 for integrity check (see 'message key' here:
[https://core.telegram.org/mtproto/description](https://core.telegram.org/mtproto/description)).
The problems you mentioned as endemic to IGE used for integrity verification,
are therefore irrelevant in this case.

As for KDF, going for slower provable algorithms used for each
incoming\outgoing packet may be a preferred solution for projects aimed at the
relatively small security crowd. But we don't really compete in this area, our
competition is WhatsApp and other mass market messengers.

~~~
sillysaurus2
_As for KDF, going for slower provable algorithms used for each
incoming\outgoing packet may be a preferred solution for projects aimed at the
relatively small security crowd. But we don 't really compete in this area,
our competition is WhatsApp and other mass market messengers._

What's this mean? You've created your own KDF, and the questions were: why is
it secure, and why didn't you use an already-proven KDF? Unless I'm misreading
something, it sounds like you've responded, "It's not that important, because
our target market isn't people who care about their security." Is that
correct?

EDIT: Judging by the upvotes, at least 5 other people are interested to hear
your thoughts on this. Considering this submission is almost off the
frontpage, that's a lot. As a security product, you should consider clarifying
your position on this, because your statement currently sounds like, "We don't
think security is a big deal since it's not a big deal to our target market."

~~~
TelegramApp
No. What we mean is, as I've just noted in the reply to tptacek, that so far
no attack was named that could harm the setup as described in our docs. And
since this setup also delivers the performance that we require in terms of
speed, we do not see why it would be necessary to change our approach to KDF.

~~~
ash
> so far no attack was named that could harm the setup as described in our
> docs

Even as a complete newbie in cryptography I can see a problem in your
reasoning. "Guilty until proven innocent" is the default when judging on a
system. "No attack was named" because Telegram uses algorithms combination
that was not proven with time. Nobody used them like this before. Why would
anyone try to break it if it wasn't used?

As a potential user of Telegram I don't trust it enough to use it. It's more
likely that someone with resources (e.g. government) could eventually break
your system than it could break another - time-proven - system.

------
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/...](https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/MessagesController.java#L555)

[1]
[https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...](https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/messenger/MessagesController.java#L1323)

~~~
TelegramApp
That is correct, Telegram does upload names and numbers — naturally, after
receiving permission to do so. (see also:
[http://telegram.org/privacy](http://telegram.org/privacy))

Apart from identifying Telegram users among the user's friends, this also
enables us to use proper names in notifications on the iPhone, as well as
facilitates moving between devices.

But you have highlighted an important issue. Our android developer relied on
the system prompts when it comes to uploading contacts, which is definitely
not enough for the issue at hand. We will add another prompt in the coming
version. (As well as update the GitHub code to the current generation soon,
it's been becoming a little stale.)

~~~
ge0rg
_naturally, after receiving permission to do so._

This is not quite true. I never gave anyone (especially not the users of
WhatsApp or Telegram) permission to upload my personal information to any
cloud services. You can not actually imply that permission from all contacts
merely by asking the user.

 _this also enables us to use proper names in notifications on the iPhone_

I do not know enough about the iOS internals, but my naive assumption would be
that after receiving a push notification, you can run code locally (like get
the contact name from a local database), not merely get the notification
displayed by the OS.

 _We will add another prompt in the coming version._

This is an improvement, but unfortunately does not tackle the first issue I
mentioned, with implying consent from the actual contacts.

~~~
ohwp
_" I never gave anyone (especially not the users of WhatsApp or Telegram)
permission to upload my personal information to any cloud services."_

On Android you do by granting rights to access your contacts and give full
network permissions. So you never know what a program will do with your
contacts and a network connection.

~~~
ge0rg
But in the real world,your contacts never told you "feel free to upload my
name and all my phone numbers wherever you want, so we can be linked by some
cloud service to improve their click-through rates". An app that uploads your
contacts is violating the privacy of your friends, even if it asks _you_ about
it.

------
na85
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.

~~~
userulluipeste
"Oh good, a bunch of randoms have rolled their own crypto. I stopped reading
at this point."

An ad-hominem attack. This is Hacker News and their work is open, how about
making a statement after researching the actual code instead?

~~~
micheljansen
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.

~~~
TelegramApp
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.

~~~
ge0rg
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](http://yax.im)).

~~~
e12e
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!

~~~
finnn
Have you looked at ChatSecure? It has OTR, multiple servers, all that good
stuff. It's not wonderful but it ain't bad (curious to hear what others have
to say, I haven't really used much else)

~~~
e12e
I have it installed, but not really looked at it. My last "burst" use of xmpp
was via facebook -- as most of my contacts don't use "plain" jabber right now.
Before that I used it a bit for work -- but then rarely on my phone.

Now that google is killing talk in favour of proprietary hangouts, I predict
it'll be a while before I'm a serious xmpp user again.

Sadly it's very hard to push process changes when one are in the minority in a
group... Thanks for the reminder though, it does look like it full-fills most
of my needs (and fixes annoyances I've encountered with other android
clients).

------
huhtenberg
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 TLS in
Anonymous DH mode with an app-level authentication of the session handshake.

Designing your own crypto protocols is a very interesting challenge, but for
practical purposes you just _have to_ recycle existing designs. There's really
no other way about it. A custom crypto doesn't make any difference for those
who doesn't know/care about it, but it certainly will not make you any friends
between those who does. Unless, of course, you can explain and prove why your
design is better than those that exist already, and these guys don't do this.

[1]
[http://core.telegram.org/mtproto/description](http://core.telegram.org/mtproto/description)

~~~
TelegramApp
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 possible to
create something that is both secure and fast.

Disclaimer: Unfortunately, I'm not Nikolay. But I do work for Telegram.

~~~
huhtenberg
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.

------
conroy

        The important thing to remember is that all Telegram messages
        are always securely encrypted. 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.
    

Where "securely encrypted" means that the Telegram server has full access to
message contents for ordinary chats. All chats should be "Secret Chats", not
the other way around.

~~~
giladvdn
Came here to say this. I also don't understand why "secret chats" can't be
kept in the cloud. Why can't they store encrypted messages and give them to me
to decrypt when I want to?

~~~
MAGZine
My guess is that it's a security thing. Even if they don't know the security
key, I would prefer if they kept no record of the message.

The real issue is that they could just make a lever that would still store
"secret chats," unless if they're being delievered p2p.

------
joosters
So many dubious claims on just the front page:

* 'delivers messages faster than any other application' \- _any_ application? Hmmm. They must be using magic.

* 'messages are heavily encrypted and can self-destruct' \- but like every system, the self-destruction is not assured since it's impossible to enforce.

* 'keeps your messages safe from hacker attacks' \- a bold claim. Maybe they do some stuff to protect messages, but it's not the perfect safety that this statement implies.

~~~
techquery
Have you tried the app? I've moved my top-5 chats from WhatsApp just because
of speed! The messages are sent really fast. But if you know any other
messenger apps for iOS, which are just about so fast, I'll definitely give
them a try.

Anyway yep, these marketing stuff is a bit too dubious, but what should they
write?

* is rather fast, faster than some applications

* can self-destruct, but sometimes can not (Ha!)

* etc

That's not the thing that happens in real world nowadays.

~~~
n1kh1lp
> Anyway yep, these marketing stuff is a bit too dubious, but what should they
> write?

How about some benchmarks to support this claim?

------
yeukhon
> Telegram is decentralized!

Great. Then...

> Telegram servers are spread worldwide for security and speed.

So this is what they mean by decentralized....

> As a result, Telegram is the fastest and most secure messaging system in the
> world

And this has exist for how many years?

I can probably say everything except private message, google hangout or
Facebook chat is already doing it. They have some of the top-notch security,
network and distributed system developers and they have their own cable
delivering more volume than your new service can combine together. and if I
want true privateness? I'd one-time pad everything. in reality, I guess PGP is
good enough.

~~~
lazyjones
> _I can probably say everything except private message, google hangout or
> Facebook chat is already doing it. They have some of the top-notch security,
> network and distributed system developers_

... and they are based in US of NSA - no thanks.

~~~
yeukhon
As an American I fear the NSA but at the same time to be fair, NSA is not the
only intelligence doing this sort of work. Let's be fair, every other
governments are doing similar things anyway, so maybe we should say no thanks
to every other website.

------
Ihmahr
People here are complaining a lot about this app, and rightfully so. However,
this is definitely the best encrypted communications app there is for ios and
therefore also the only app that is cross platform and able to reach a wide
audience. I know they didn't do it completely right, but it definitely seems
to be the best option that is currently available.

~~~
ge0rg
An "encrypted communications app" that is not using secure encryption is worse
than an unencrypted one - the users get a fake feeling of security, and might
reveal sensitive information to whoever is listening.

Regarding real security, have a look at ChatSecure, which is available for iOS
and Android, uses standard encryption protocols (XMPP with TLS, OTR), is open
source, and was developed by the Guardian Project (who have a track record of
developing security software):

[https://itunes.apple.com/de/app/id464200063](https://itunes.apple.com/de/app/id464200063)

[https://play.google.com/store/apps/details?id=info.guardianp...](https://play.google.com/store/apps/details?id=info.guardianproject.otr.app.im)

~~~
Ihmahr
Yes, I have been using chatsecure and I know it is much more secure but it is
almost unusable on ios because it can not run in background.

As for the false sense of security, you're probably right.

~~~
ge0rg
_but it is almost unusable on ios because it can not run in background_

Unfortunately, the only way around that is to integrate with Apple's Push
Service, which means you need to run a server-side component which notifies
Apple (and which in turn notifies your app). This is not specified for XMPP,
so most "XMPP clients" for iOS instead store your credential on the app
developer's infrastructure. However, this problem is being worked on:

[http://legastero.github.io/customxeps/extensions/push.html](http://legastero.github.io/customxeps/extensions/push.html)

~~~
chrisballinger
I am working on a protocol-agnostic, federated push messaging layer for
ChatSecure-iOS but it will be interesting to see if anything else pops up in
the meantime.

------
gprasanth
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](http://core.telegram.org/mtproto)

~~~
egeozcan
I also don't get this. If we stopped trusting HTTPS, how are we supposed to
make sure that we get an unmodified app from the play store, or the original
source code from GitHub in the first place? Am I missing something?

~~~
dchest
The fact that we have to trust TLS to deliver software doesn't automatically
mean that we should trust it for secure messaging.

Also, I think App Store software delivery doesn't depend on only TLS, but also
on Apple's signature. And you can visually verify that the source code
downloaded from GitHub doesn't contain backdoors.

~~~
egeozcan
My knowledge on cryptography is next to nothing. Would you mind explaining to
me what makes the case for secure messaging different than any other transfer
through a secured HTTP connection? I also read a bit on OTR Messaging and the
"Socialist Millionaires' Protocol" but just got even more confused.

~~~
dchest
It's not that messaging can't use TLS, of course, it can. I'm objecting to the
absolute (if we don't trust TLS for messaging, we shouldn't trust it one-time
download), e.g. see
[https://en.wikipedia.org/wiki/Threat_model](https://en.wikipedia.org/wiki/Threat_model)

------
utnick
A lot of haters in this thread. To be expected.

I've been following this space for a while and telegram is the best app out
there right now. The usability is great and they are trying to do the right
things when it comes to security.

The apps are open source and can be audited. I fully expect there to be bugs,
that is part of the process! You would be insane to trust your life to a
crypto app thats been around a few months. So yes, there will be bugs. But
that doesn't mean they should just give up. In a few years this could turn
into a really nice , secure app.

I think their big competition will be: Textsecure, also a great app and better
for security due to OTR. But the iphone app is still in development as is
their data channel. Once those are complete, they could take the #1 spot.

Also, hemlis is one to look out for. But they take about the same security
approach as telegram but seem to be less open so far.

~~~
salient
They are making a lot of bogus claims using marketing speak, and they are very
low on details, while saying the app will be opensourced "eventually".

For a "security" app, hell yeah you should be skeptical. Right now I think the
most interesting and most trustworthy secure messaging projects are TextSecure
v2 and Dark Mail (granted, that one isn't even out yet, their ideas so far
sounded quite good).

~~~
mahyarm
But the clients are open sourced:
[http://telegram.org/source](http://telegram.org/source)

------
grandpoobah
Where's the desktop app? I guess I'm old fashioned, because I'm looking for
the next msn/icq.

~~~
prepin
Mac [https://itunes.apple.com/us/app/messenger-for-
telegram/id747...](https://itunes.apple.com/us/app/messenger-for-
telegram/id747648890?mt=12)

Win [https://tdesktop.com](https://tdesktop.com)

------
niketas
To whom it may concern: Pavel Durov, one of the authors of Telegram, announced
he will pay $200K (or 200 BTC) to decrypt his traffic
[http://tjournal.ru/paper/durov-decifer-
telegram](http://tjournal.ru/paper/durov-decifer-telegram)

~~~
ash
Yes, but not yet. He _plans_ to announce the reward in a week. No encrypted
traffic published yet.

------
ingenter
>Q: Who are the people behind Telegram?

>Telegram is supported by Pavel and Nikolai Durov.

I would not trust social network owner with my messages.

~~~
josu
This is what the wikipedia says about Pavel[0]:

>Durov holds libertarian economic and political views and says he is a
vegetarian and identifies as a Taoist. He published anarcho-capitalist
manifestos describing his ideas on improving Russia. On his 27th birthday, he
donated a million dollars to the Wikimedia Foundation.

Well, I think I'd rather trust them than Google or Facebook, after all, you've
got to trust somebody.

[0]
[http://en.wikipedia.org/wiki/Pavel_Durov#Personal_life](http://en.wikipedia.org/wiki/Pavel_Durov#Personal_life)

~~~
chippy
> you've got to trust somebody.

Better the devil you know?

------
__alexs
Their HTTPS server isn't configured with the right certificate :(

Firefox gives me "The certificate is only valid for the following names:
*.stel.com , stel.com" for [https://telegram.org/](https://telegram.org/)

~~~
dchest
Looks fine
[https://www.ssllabs.com/ssltest/analyze.html?d=telegram.org&...](https://www.ssllabs.com/ssltest/analyze.html?d=telegram.org&hideResults=on)

------
eliteraspberrie
The authors' education credentials are impressive, and I admire their
initiative. However, they do not seem to have employed a cryptographer to
review their design and protocols, so I expect that serious security problems
will be discovered.

Personally, my expertise is rather in application security, so I will review
some of the source code over the holidays. At first glance the C client is not
bad.

The real metric of this project's success will be how they react to criticism,
harsh as it may be. I hope they learn from their inevitable mistakes and
succeed in the long term.

------
zcam
And it's based/hosted in the US: will not use.

~~~
kintamanimatt
Other countries are doing wholesale spying too and analogues to NSLs exist
elsewhere, albeit without a gag orders, e.g. RIPA in the UK.

------
artellectual
why does HN comments have to be so negative all the time? its very depressing
to read through HN comments.

~~~
sparkie
Because intelligent, educated folk don't blindly accept the claims of others
without scrutinizing them?

I don't see it as negativity. People are bringing attention to the details
that marketers typically omit (perhaps intentionally). If anything, these are
positive discussions as we're sharing our own views and experience to give
others more information to allow them to make more informed decisions. (i.e,
whether the claims of security can be trusted in this case.)

If you want comments that are always happy and positive about every claim made
by marketers, there's plenty of other places on the web for that.

------
TeeWEE
Everybody is so negative here. Ok rolling your own security protocol might not
be the best move. However, they want to be competetive with whatsapp.

Most people who try to make a whatsapp killer suck in uix. But this app is
really good and fast. I think its better than whatsapp in a multitude of
terms.

Okay, there are improvements. But I can submit a pull request to the android
app and improve it myself! How Awesome!

~~~
haarts
I fully agree. Everybody can surely agree this is vastly better that WhatsApp
despite it's shortcomings.

------
betterunix
[http://telegram.org/privacy](http://telegram.org/privacy)

That such a policy even exists should suggest that "secure" is the wrong way
to describe this. Reading through this, it looks like _yet another attempt_ at
what Lavabit and Hushmail were trying to do. In other words, snake oil.

------
adventured
"How is Telegram different from WhatsApp? Unlike WhatsApp, Telegram is cloud-
based"

Yeah, ok. Decided not to use it right there.

------
arianvanp
More info about their secure protocol is here:
[http://core.telegram.org/mtproto](http://core.telegram.org/mtproto)

technical description here :
[http://core.telegram.org/mtproto/description](http://core.telegram.org/mtproto/description)

------
asadlionpk
Devs of this app: Don't be disappointed by these harsh comments because most
of them contain technical fixes you need to do asap!

These suggestions, if implemented/fixed will surely get you some really
dedicated early adopters!

------
herge
tptacek should write up a block like
[http://craphound.com/spamsolutions.txt](http://craphound.com/spamsolutions.txt)
for everytime somebody rolls up their own crypto solution.

------
agilebyte
Awesome Fallout-style icons.

~~~
cedias
Open Api hasn't been this sexier !

------
andor
Like Threema, they use the PGP model, instead of OTR...

~~~
Tepix
What do you mean exactly? According to the FAQ, Threema offers perfect forward
secrecy:

Yes, Threema provides forward secrecy on the network connection. Client and
server negotiate temporary random keys, which are only stored in RAM and
replaced every time the app restarts (and at least once every 7 days). An
attacker who has captured the network traffic will not be able to decrypt it
even if he finds out the long-term secret key of the client or the server
after the fact.

~~~
andor
Oh, I thought Threema crypto is based on RSA+DH, but according to the FAQ they
use the NaCl library. That's quite nice!

------
motters
If this is closed source (and the source seems to be only implementing API
calls to a closed system) then it's fair to assume that this application is
probably insecure or has backdoors.

Also if the private key is stored in the cloud then it's likely to be subject
to requisitions.

~~~
TelegramApp
Private keys for secret chats are only stored on the two participating
devices.

As for server code — open sourcing the server code wouldn't really do much to
improve trust. You would still have to trust us that we are using THAT code,
not something different.

~~~
garethadams
Depending on your definition of "decentralised", open sourcing the code would
enable _other_ people to set up servers that they can trust is running that
code.

------
jeswin
Looks like they kept the interface exactly the same as What's App to attract
users. The smiley selection has the entire list of What's App smileys in
exactly the same order. What's App is going to be upset, but it might help
users.

~~~
arianvanp
I always that it was just the order of the emoji unicode range

~~~
VMG
I think it is, the default android keyboard is using the same emojis

------
okso
I see source code for clients, but nothing for the server side.

Are they using something standard or do they want to lock-down users to their
own proprietary servers ?

------
kristopher
Not sure how uploading all of your contact information to their servers counts
as "taking back our right to privacy."

------
jokoon
I don't understand, how is this thing on top of hacker news, while it's being
deconstructed like it's a toy ?

~~~
maigret
My suspicion: peoples with little idea on the topic vote it up, while the
knowledgeable vote it down.

------
subb
How can this be free? They're not Wikipedia. I'm not sure how they can pay for
multiple servers...

~~~
macalicious
[http://telegram.org/faq#q-how-are-you-going-to-make-money-
ou...](http://telegram.org/faq#q-how-are-you-going-to-make-money-out-of-this)

The brothers do have some money, I suppose, from their company. However, I'm
not sure if they are using the data gathered from this service, thus resulting
in revenue somehow (maybe in their social network).

------
ssewell
Random observation. What's with the crossed out "h" in chats on the landing
page?

------
xolve
This is not distributed at all. IRC is distributed.

Messages stored on cloud! Big privacy problem.

Just tall marketing claims.

------
yxhuvud
How about desktop clients? Being restricted to mobile devices is not very
practical.

~~~
solarmovement
Mac OS X desktop client is available in the App Store

------
thomasfl
If this get popular and the people behind it can be trusted, this could
replace sms and e-mail. The iOS, Android and CLI clients are open source, but
I they need to open source the backend too. I also like the idea of giving the
noun "telegram" a new meaning.

~~~
macalicious
Replacing SMS I can see, since whatsApp/GroupMe/iMessages/whatsoever is
already doing so, but replacing e-mail? Why would it replace e-mail in your
opinion? I think IM/chats have a completely different purpose compared to
e-mail, which unfortunately is often times used wrongly imho.

------
seanhandley
"Cloud based" eh? Very secure.

~~~
seanhandley
and apps on iOS and Android - no possible way data could leak there.

------
talles
Where have I seem this logo before...

------
aet
How does this operation make money?

------
adnam
Snake oil

------
bound008
Open != API

~~~
bound008
sorry... did not see that the source code is available for all platforms
including iOS.

------
totty
nice

------
andyl
How does this compare with Wickr?

------
alonium
Wow, there are so many cryptography experts with world names in this thread!

And interesting why you think that it's not possible to read most of
cryptography/cryptanalysis books and check common mistakes of implementation
afterward? Do you really think that this is _THAT_ hard?

Your scepsis would be understandable if they used _OWN_ cryptoalgorithm.
However their protocol is based on well known strong crypto.

~~~
rblaze
Yes, it's THAT hard. I'd read many good books and still feel bad looking on my
first attempts in protocol design.

BTW, IGE cipher mode isn't well known for being strong.

