Telegram - secure, free messaging
telegram.org
telegram.org
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/
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.
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 and 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?
Pray tell, why replay protection is done after decryption.
We could employ additional filtering techniques, but that increases processing time. And since modern hardware allows for very fast AES decryption, there is no particular gain in building additional layers of protection.
All that, naturally, implies that other anti-DoS measures are also being used.
In light of that, why would anyone in their right mind use a security product your organization developed?
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?
https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...
Long story short: you get integrity protection from IGE by relying on the fact that a bit error anywhere in the stream will irrevocably corrupt the rest of the stream, so you create an authentication code by sticking an all-zeroes block or (like I think Telegram does) a message digest to the end of the stream.
But it's possible with carefully chosen errors to first corrupt an IGE stream and then recover it, so that the remainder of the message after the corruption (including the "MAC" tag) will remain intact.
IGE is an extremely weird, and, at this point I'll venture: bad choice for a 2013-2014 cryptosystem.
Not even HMAC-SHA1, just "SHA1"? So you leave yourself open to length extension attacks? http://en.wikipedia.org/wiki/Length_extension_attack
How broken is it here? Who knows. Professional cryptographers would use an AEAD mode with a security proof, or the generic composition of a cipher (w/proof) with ciphertext encrypted by a MAC (w/proof). Instead, this system uses a '70s block mode (that nobody else uses) and a hash function from the '90s.
We are indeed using well-known older algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development, provided one takes care of the known drawbacks.
The weakspots of the said algorithms are also well-known, and have been exploited for decades. We used these algorithms in such a combination that, to our best knowledge, prevents any known attack from possibly succeeding. Although we’d be grateful to see any evidence of the contrary (so far absent from this thread) and update our system accordingly.
While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.
[0] – https://core.telegram.org/img/mtproto_encryption.png [1] - http://core.telegram.org/mtproto/description
They appear to be trying to use encrypt and mac, and not as far as I can tell relying on IGE mode to provide authentication. See the "Message Key" and "Important Tests" sections here: https://core.telegram.org/mtproto/description
There is also not, as far as I can tell from reading the protocol description above and the source code here: https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j... (in particular the EncryptedMessage method, lines 447 to 460) any sort of key in the MAC, it's just SHA-1 of the plaintext. It's also not encrypted as far as I can tell, it's listed in the unencrypted "external header" in the protocol description.
I can't think of an attack from this, but the fact that an adversary can generate a valid MAC for _any message_ by simply SHA-1'ing it seems really scary.
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."
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.
The consensus seems to be that you're doing encrypt-and-mac, where the mac is just a sha1? If that's true, then you're relying on broken properties of IGE (not provably UF-CMA), and your protocol does not provide provable integrity. That's an essential part of any secure protocol.
> 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.
That's interesting, because the thing you've made up is actually slower than a provably secure KDF.
Now, again, could I somehow direct your attention away from speculations and to what we are ACTUALLY doing (as, again, documented here [0], and now here as well [1]).
1. We are not doing plain encrypt-and-mac.
2. The SHA1 in question is for raw unencrypted data.
3. The message key is SHA1-dependent.
4. Note that the AES key and iv depends on that SHA1.
This can be described as a generic composition of cipher with ciphertext, encrypted by a MAC. The resulting data-dependant variable key denies all common attacks.
As for KDF, what particular solution do you have in mind? And even then — certainly, alternative solutions exist, but we do not see how changing this point would affect our system as whole. [1] As stated before, we'd welcome any information on attacks that could in reality threaten the actual setup.
[0] - http://core.telegram.org/mtproto/description [1] - https://core.telegram.org/img/mtproto_encryption.png
All popular KDFs (PBKDF2, bcrypt, scrypt) are adaptive (tunable). You choose the number of iterations.
Great crypto software avoids RSA. Good crypto software uses OAEP when RSA is used to encrypt. Crappy crypto software (see: DNSSEC) uses PKCS1v1.5. What are you using?
I didn't look carefully; I have probably missed something. Please explain how you are using RSA in the handshake/authentication for your protocol. Like Moxie said: it's not the underlying algorithms you use; it's the constructions you use to to them together, and to the data you're protecting.
Incidentally, "I refuse to respond to comments from people who have only looked at my system for a couple minutes" is not a habit of highly effective cryptographers.
The server now supports OAEP, although this has yet to find its way into the docs and clients. We will update. Thank you!
You need to publish the server-side source code for me to have any chance of making sense of this. I only see the client side of the connection in your source code, not the server response.
Is vkontakte [1] (russian social site) being somehow involved? I got confused by the illustrative images strongly resembling the vkontakte images.
Not to dive into Russian folk, but those look too culturally localized.
[1]: http://vk.com
Sexist.
In what areas of mathematics did these PhDs specialize? I hold a PhD in mathematics, but I would not feel comfortable rolling my own cryptographic algorithms for use in production (I'm a commutative algebraist by training).
Yes, because we all know that there are no women who can write code or analyze cryptographic algorithms. [rolls eyes]
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/...
Also, there are approaches to make number registration lookups more secure, e.g. bloom filters: http://en.wikipedia.org/wiki/Bloom_filter
I would expect such an approach from a "secure" app.
I did not want to imply that there is a perfect zero-knowledge synchronization mechanism for your contact book.
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.)
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.
Thank you, that was exactly my first thought.
In general, since we all are represented in other peoples' contact lists, it's worth considering what those other people are going to do with our data.
And it's not just the people you correspond with directly. I have a lot of people in my Thunderbird and email provider lists who I have no idea who they are, because someone in a chain of someones sent out a broadcast email with their address and my address.
Which means that if I were the sort of person to "upload my contacts!" I would have exposed people two or more hops away from me to whatever "service" I'd just submitted to.
Uploading your contacts may become the net equivalent of farting in public; it's rude.
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.
Ugh, this is such douchebag behavior for something that purports to be a "secure" app. Stop it immediately, please.
It's like saying "this heat is really cold". In other words: a contradiction in itself.
Only open-source apps on open-source operating systems can start making claims about security and trustworthiness.
...running on Open Source hardware.
Many modern smartphones employ a baseband processor and an application processor with shared memory. While the app processor might be running an open-source compiled Android, the baseband processor is usually on a closed, not externally verified (and very buggy) RTOS provided by the manufacturer (Qualcomm, MediaTek, TI, ...)[0].
Owning the baseband is sufficient to gain access to the raw RAM of the application processor, to read any IM messages and keys, to manipulate data, code and whatever else you like. And all this is completely undetectable by any "antivirus" software running on the app processor.
FTFY. Open sourced hardware by itself is of no practical use because the guy who manufactured it for you might have altered it in production.
>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.
That's a very bold and yet to be proven statement. Probably any crypto expert would know better than to say that.
This paragraph exactly pin points the problem with being a cryptographic nobody.
PS. I do like their icon designer.
He is one of most legendary math/programming champions of all time.
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 refactoring change. http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
And the only reason the critical bug was found is because it was open source. This, as far as I can see, isn't.
So we have a perfect storm of problems here: An author who has rolled his own crypto, isn't a cryptographer, and whose product is closed source. Trust Telegram at your peril.
It's worth noting that there's an app which already does what Telegram claims to do. It's called TextSecure, and it was written by Moxie Marlinspoke and several other big-name cryptographers: https://whispersystems.org/
... and it's open source: https://github.com/WhisperSystems/TextSecure/
... and they don't try to roll their own crypto: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2
These aren't coincidences. It's basic necessity.
EDIT: Telegram is open source, so I was wrong about that and it'd be unfair of me not to mention it. But the other observations still apply. Until Telegram is verified to be secure, I don't think it's a good idea to trust it, especially when secure alternatives like TextSecure exist.
TextSecure has been a work in progress for two years: https://github.com/WhisperSystems/TextSecure/commits/master?...
Telegram seems to have been in progress for two months: https://github.com/ex3ndr/telegram-mt/commits/master?page=2
Telegram also seems to be the work of a single author. While TextSecure was written mostly by Moxie, there were several other contributing members.
TcpContext.java[1] says:
MAX_PACKED_SIZE = 1024 * 1024 * 1024;//1 MB
READ_DIE_TIMEOUT = 5 * 1000; // 15 sec
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...
* Uses unpadded RSA in its authentication protocol
* Uses a novelty mode (IGE) for its bulk transport
* Does not appear to authenticate messages (other than by using IGE)
* Or, at least, what authentication it is doing must be happening after it decrypts data, not before
I could be wrong about any of these things, because again, 4 minutes. But this design does not look sturdy.
EDIT: Oeps, sorry.
Looks like the programme is open source: http://telegram.org/source
Colin's problem was that his (hand-written, from the looks of it) crypto primitives allowed him to use AES-CTR with a non-incrementing counter. I'm not sure if it's appropriate to say that in relation to a comment about "rolling your own protocol." I see that as a low-level problem.
Further, you've pulled a misdirection talking about TextSecure (which looks great, by the way). They don't roll their own crypto algorithms, but they have definitely tweaked and modified the OTR protocol for their own purposes in order to make it more secure. I'm left wondering why TextSecure is held up in contrast to someone who uses their "own" secure messaging protocol.
Whether or not this Telegram app is trustworthy (the lack of full source is suspicious), I have no idea. I would personally pick TextSecure over it.
It is not in fact reasonable to compare Telegram's ad-hoc protocol to the "extensions" TextSecure has.
The only point I wanted to make is that someone using a protocol (variant or original) that someone hasn't seen before is not inherently damning in and of itself. Mine was a general point, and yours is a practical one, which I mostly agree with.
The parent comment seems to imply that there is a pre-written solution for all cryptographic problems that can be dropped into place, and I also felt they were conflating high-level protocol problems with low-level cryptographic primitive problems (i.e., "rolling your own crypto" being used in a general sense). I think it is reasonable to compare two "non-standard" systems in that context, especially given how modifying an already-trusted protocol can go haywire if something is done wrong.
Whether or not an extension or protocol is reviewed, has a public spec, comes from a cryptographer, started from a more trustworthy protocol or has other practical elements that make it appear trustworthy on the surface, is another matter entirely. It 100% matters in practice, but not for a more general point.
I understand that Telegram is doing everything from the ground up and that TextSecure started with OTR, and that the ratcheting extension wasn't pulled out of thin air. I am not claiming in practice that Telegram and TextSecure are comparable (I did not mean to take anything away from TextSecure or the ratcheting scheme), and I personally would not touch Telegram in light of further snooping about and comments posted in this HN thread.
https://news.ycombinator.com/item?id=6913705
For further reference:
It's just an advertisement like any other. I'm sure the people responsible for the content of the FAQ know their target audience, so they know the wording will work for those whose attention they care about.
It is good that we, technical people, understand how completely worthless those words are. It begs for the "citation needed" label.
The question for me is this: do ordinary people (non-programmers in this case) really believe in most of the things ads tell them?
An ad-hominem attack. This is Hacker News and their work is open, how about making a statement after researching the actual code instead?
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.
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).
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).
Knowing this, I hope you can appreciate why the burden of proof on your unproven team and approach is fairly high.
We use well audited crypto primitives with formal proofs because they're known safe, or at least orders of magnitude safer than whatever these fools cooked up.
tl;dr provide proof or gtfo. We're not here to audit you.
When you're rolling out a secure system + implementation you want to use algorithms that have been proven, tested and certified as correct. It's a delicate field that can't be approached like your standard software development field. Yes, being a "random" and developing your own encryption algorithm out of the box is bad. Never trust anything like that. Period.
We know that writing crypto is hard and experienced crypto programmers make mistakes.
The possibility of a naive programmer creating a sturdy piece of crypto software with no previous experience is vanishingly small.
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.
You can now argue whether that's still "from scratch". (Is building something on top of TCP "from scratch"?)
Look at the description of their protocol, particularly the handshake, which negotiates number-theoretic parameters, and try to make a list of all the checks they'll need and the additional protocol that they'd need to specify just to make the handshake secure.
Not only that, but the crypto in Telegram is idiosyncratic; for instance, this is the only system I've ever seen that used IGE mode.
I've changed the part in the FAQ that seems to be one of major sources of this controversy, so that it no longer reads "built from scratch". This was poorly applied marketing language — we do use time-tested security algorithms. Even though Telegram doesn't uses MTProto instead of HTTPS due to mobile speed and trust issues.
AES in what mode? IGE? Why are you using an authenticated cipher mode from the 1970s that predates every modern AEAD construction?
DH with what group? How do you authenticate the exchange? How does forward secrecy work?
Saying "we didn't roll our own: we use RSA, AES, and DH" is extremely worrying; it suggests that you're not aware of where the complexity in a cryptosystem lives. Anybody on HN can write the trivial code to ask the JCE for an RSA or an AES. You have to do better.
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.
http://core.telegram.org/mtproto/TL-dependent
look like a great parody to me? can't tell if they are serious with these 'dependent types'
> TL Language (Type Language or Time Limit)
So it is a partially applied acronym with a branch in it!
There is something seriously messed up in this project.
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.
I'd like to see some papers/surveys/case studies on the matter. Yes, it's an "experiment", doesn't mean it's a good idea to roll out your own implementation before performing (and publishing) extensive tests.
Not saying you're doing something wrong, just that security-oriented people (usually who'd be interested in your product) may want to know more than just "yes guys it's secure, trust us".
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.
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.
The real issue is that they could just make a lever that would still store "secret chats," unless if they're being delievered p2p.
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.
... and they are based in US of NSA - no thanks.
* '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.
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.
How about some benchmarks to support this claim?
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://play.google.com/store/apps/details?id=info.guardianp...
As for the false sense of security, you're probably right.
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:
If you actually cared about security then you wouldn't be using iOS.
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.
No, you don't. Use a self-signed certificate that is hardcoded in the app.
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.
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).
And that would be a better time to market it as "very secure"
>Telegram is supported by Pavel and Nikolai Durov.
I would not trust social network owner with my messages.
>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.
Better the devil you know?
Firefox gives me "The certificate is only valid for the following names: *.stel.com , stel.com" for https://telegram.org/
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.
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.
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!
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.
Yeah, ok. Decided not to use it right there.
technical description here : http://core.telegram.org/mtproto/description
These suggestions, if implemented/fixed will surely get you some really dedicated early adopters!
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.
They do use forward secrecy on SSL, but not on the messages themselves.
Also if the private key is stored in the cloud then it's likely to be subject to requisitions.
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.
It would allow people to run your code (if they like it) on their own servers. Then they wouldn't need to trust you.
Are they using something standard or do they want to lock-down users to their own proprietary servers ?
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).
Messages stored on cloud! Big privacy problem.
Just tall marketing claims.
If you don't trust the backend in some particular way, nothing can help you to trust cloud storage. You should better take a look at end-to-end encrypted chats [1]. In theory they don't allow server to get access to any user data, except the fact of sending messages.
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.
BTW, IGE cipher mode isn't well known for being strong.
There are a great many ways you can all gaps which mean a hacker can circumvent your security arrangements, and we are sceptical because we've seen it done wrong so many times before that it is healthier to take the pessimistic view (assume it is wrong and be pleasantly surprised if it isn't, rather than unpleasantly surprised if/when it turns out not to be).