9 ms·

An Attack on Telegram

169 points by escapologybb 12y ago

air 12y ago
"This past spring, Juliano Rizzo (@julianor) and I came up with a cryptographic attack on Telegram's MTProto "secret" chat communications which can be performed in O(2^64) time." Using asymptotic notation without an argument (usually "n") makes me cringe. O(2^64) = O(1)
aw3c2 12y ago
Huh! Just yesterday I was fed-up with Textsecure being so buggy and bad that I looked at the Telegram homepage and thought "nice" apart from not completely being free software (or is it?). It says "Telegram messages are heavily encrypted and can self-destruct." which made me believe that all messages are heavily encrypted. Now this post says "By default, messages (...) are logged and stored on Telegram's servers". Damn.
- sz4kerto 12y ago
  "By default, messages (...) are logged and stored on Telegram's servers". Because most of the users need this for keeping the message history and they would not use Telegram otherwise.
  - praseodym 12y ago
    It also provides the user the ability to use several clients, e.g. on smartphone + laptop + tablet. That's a big advantage over e.g. WhatsApp.
    - phillc73 12y ago
      This is why I use Telegram. I was spending far too much money sending SMS messages to my friends overseas. A few hundred per month at EUR0.12 each starts to add up pretty quickly. Data is cheap, so instant messengers tend toward being almost free. Telegram has official clients for my FirefoxOS phone and for my Linux desktop. I've never used their secret chats. I appreciate their open source nature and am happy to support them.
  - aw3c2 12y ago
    I should have included "in a way that allows Telegram to view the message contents" in my quote then. They should be stored encrypted.
- cyphunk 12y ago
  This is exactly the problem with the communities "greater than though" tone toward anything non-EU/US engineered. The Telegram client is open source. Threema for example is NOT. WhatsApp for example, is NOT. Facebook Messenger, is not. Telegram appears to have the right balance in getting real peer review from having the system open source and verifiable while also garnering this huge animosity which has lead to even more review. As far as I can see Telegram and TextSecure are the only clients where the protocol can be verified through the open source client. I'm not advocating for its use but I'm sick of the misconceptions.
sz4kerto 12y ago
"Some viable alternatives I can recommend are Threema or TextSecure." The problem with Threema and TextSecure is that it's hard to convince my friends to use them because - Threema is not free and does not have desktop/web clients, and multi-device setup is not supported afaik - TextSecure is not really multi-platform The only popular, multiplatform messengers at the moment are Whatsapp, FB Messenger, Viber/Line and Telegram. Whatsapp doesn't have a desktop client, Messenger requires a Facebook Login, Telegram and Whatsapp does not have voice chat and I hate Viber's design -> so I keep using Telegram for messaging and Skype for voice. The network effects can be very nicely observed in messenger usages. In my home country almost everyone uses Viber, but in other countries I have worked (W-EU) almost everyone uses Whatsapp. In Germany people seem to know Telegram, in other places nobody heard about it.
- dsacco 12y ago
  I know you most likely meant synchronous voice chat, but if you can deal with asynchronous voice chat, you'll be able to have full end-to-end encryption for that and text messages using WhatsApp in partnership with Open Whisper Systems in the near-ish future.
  - sz4kerto 12y ago
    Yeah, that's not really acceptable when I'm calling the tax authorities or my car dealer to arrange an appointment :) for that purpose, Skype is 100% workable for me (even under Linux).
    - deleted 12y ago
      [deleted]
- cyphunk 12y ago
  Threema, Facebook, WhatsApp are not open source. TextSecure and Telegram have open source clients allowing for verification and trust of the protocol.
  - 12y ago
tomaskafka 12y ago
Isn't all this pointless when Telegram could just MITM everyone at will of any agency, as the client is closed source? Unless the whole client code is audited by third parties (and it is ensured that app store version = audited version), this whole exchange of keys with colorful qr code could be a charade.
- cyphunk 12y ago
  wtf? client is all OSS https://telegram.org/source https://telegram.org/source
  - dsacco 12y ago
    I believe the OP was referring to the fact that you have no assurance the application binary you receive on mobile is the same as the public open source version. This goes hand in hand with a third party audit. Whether or not it's open source doesn't mean much if you can't audit it. Open source counts if you're a developer and can read the code to see that a piece of software isn't e.g. calling home with user credentials in cleartext and storing them or worse. But this is a custom cryptosystem. Most people can't audit it, and the people who can are not going to use their (extremely lucrative) skillset on the software without personal investment like "I want to use this." Are they going to pay a consulting firm like Riscure to completely audit the codebase? No? Then it is insecure until proven secure. Open source isn't good enough.
    - cyphunk 12y ago
      Okay this problem of binary verification you should blame on Google and Andriod app ecosystem. At least on andriod if you install the apk yourself with Telegram and TextSecure you know exactly what you are running. For everythign else, you have no clue.
      - riquito 12y ago
        > if you install the apk yourself [...] you know exactly what you are running No, you don't. You know what you're running only if you compiled the sources or if you can compare the binary signature with the build of someone you trust (you or others that built from sources).
cyphunk 12y ago
Every one of these new chat systems have similar problems with key authentication. they fail in similar ways and try to solve the problem in similar and different ways. This articles contribution, while very valid with its "greater than though" tone, is gets on my nerves. I have no idea why it always seems to be a constant when people talk about Telegram without really investigating the dramatic headlines authors claim. Is it that we just hate anything engineered in Russia, China. Its boring already.
- dsacco 12y ago
  Do you have a data point to suggest real bias against the geographic engineering behind Telegram? All the substantial warnings I have read against it revolve around its lack of a respected crypto team (in fact, not having any experienced crypto team and conflating a bunch of maths PhDs with a real crypto team), not using acknowledged crypto design best practices (and flagrantly ignoring them for counrer-intuitive designs), and most importantly, using a contest instead of a real audit. Contest != audit. An audit has a specialized team of cryptographers who try to break the application in any scenario. A contest has restrictive scope that sets up a strawman and doesn't attract real, serious crypto auditing. As an example, this article's MITM doesn't qualify despite being a real attack. A contest means that you have no real knowledge of whether the crypto is broken if nobody succeeds. An audit means you can be significantly towards certain. You might already know this, but consider that if someone hosts a contest instead of an audit, and has all the other issues stated above, they will be met with hostility.
  - cyphunk 12y ago
    Valid criticism but I feel the items you mention get blown out of proportion. The Cryptocat team had similar areas where it was lacking and yet did not suffer the same backlash. This could be because they never ran a competition and worked to find a way to fund an audit several years later instead. The data point(s) that lead me to wonder of a geographic bias have to due with the tone of prior analysis of telegram I've read over the past year. This article included. And also a general, very male, arrogance in the security community that seems to constantly search for any reason to ridicule. I will have to go back and trace the history of my perception to find the tone I mention, which I can do tomorrow if you likewise can provide a datapoint for your understanding that they flagrantly ignored crypt design best practices. In watching the evolution of Pond, Telegram and TextSecure we see that to solve security or usability problems designers are required to venture to some degree into uncharted territory, away from best practices. So I question the flagrant claim. But I agree contests are just marketing ploys, little else. If Telegram wanted to "claim" otherwise they would need to start with paying the analysts from this article the full bounty.
utnick 12y ago
So the attack is due to the fingerprint of the key being smaller than the actual key and therefore theoretically possible to find another key with the same fingerprint.. Doesn't textsecure and threema have the exact same problem? Both show a fingerprint to the user instead of the actual key.
- semi-extrinsic 12y ago
  If that's the attack, then it's well known that PGP is also vulnerable to the same thing: http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...
known 12y ago
I like https://icrypt.me/ https://icrypt.me/
Shank 12y ago
I find it interesting in how there is some dependence on the fingerprint secret being shared across the Telegram channel in order to verify identity. What if a user sends the screenshots of the fingerprint over, say, a medium decided in the chat on the fly? Unless you can MITM every service they're using, you could just /tweet/ the fingerprints, for instance, and check on a different machine for a matching key. Or what if the screenshot is tampered with by hand, like, signing the center of the square with a finger drawn, transparent signature? How would an attacker replicate that? Of course, the "supervillain" model still works and enough computation time and power might find it, but there are a multitude of ways to ensure that the secrets match on everyone's devices.
shmerl 12y ago
They still didn't release the server code, didn't they?
- huhtenberg 12y ago
  And what would this accomplish exactly?
  - spoiler 12y ago
    It could reveal potentially exploitable server-side bugs.
  - shmerl 12y ago
    It can start a discussion on trusting it. Without that code it doesn't even start.
    - rakoo 12y ago
      Wrong, the whole point of end-to-end encryption is that security doesn't rely on intermediaries working as expected; they're only transports. Which is why having Telegram's server code wouldn't be useful from a security POV. What it could be used for instead is running alternate "pods" to distribute load over multiple servers.
      - shmerl 12y ago
        It's not all end to end. And there is a difference if the server is a malicious one. Anyway, since the service is centralized and not federated even if it will become all end to end encrypted, it's enough of a reason not to use it.
- StrLght 12y ago
  It sounds like you except that to happen. I don't think they will ever do that.
  - 12y ago
imaginenore 12y ago
O(2^64) is the same as O(1) Pretty pointless estimate. Just for reference to see how large 2^64 is, 2^64 microseconds = 584,555 years Even if you find 10,000 computers capable of 1 million checks per second (a huge "if"), it would still take 58 years.
- logicallee 12y ago
  Maybe it's the historian in me, but I found your numbers really, really funny! >Even if you find 10,000 computers capable of 1 million checks per second (a huge "if"), it would still take 58 years. I'm sorry if I'm missing the context but it sounds straight out of 1958! Like, when a PC takes a room, costs $2.9 million (2014 $23.1 million), and comes with a with a processing speed of around 100 Kflop/s [1] Like, "even if you find TEN THOUSAND" computers - like where would anyone find ten thousand computers in 2014 (Amazon and Microsoft's cloud farms only have like a million servers instnatly available on their clouds).... capable of a MILLION checks per second! That's a full Megahertz! It would still take you 58 years :) :-D Sorry!! It would have been a good argument in 1958 though :-D [1] http://en.wikipedia.org/wiki/IBM_7090 http://en.wikipedia.org/wiki/IBM_7090
  - hurin 12y ago
    2^64 is expensive, but breakable.
    - logicallee 12y ago
      I was specifically referring to the OP's awed overtones of 10,000 x 1 mhz, resulting in 58 years. Which I found really funny. The idea of 2^64 being inherently a large number... when a single graphics card costing a couple of hundred incidentally goes through 2^64 flop's all by itself every few weeks. There's nothing expensive about 2^64 as such. I mean it's expensive in the sense of, we're talking dozens of dollars here :)
bdkoepke 12y ago
I don't know why ChatSecure by the guardian project never comes up in these discussions: https://guardianproject.info/apps/chatsecure/ https://guardianproject.info/apps/chatsecure/ It uses Otr for encrypted chat, so you can use any otr client for the other side of the chat. I personally use pidgin on my laptop and ChatSecure on my cell. It currently supports at least iOS and Android, which encompasses most people that I know.
- orblivion 12y ago
  My experience with Chatsecure (at least the version I got from F-Droid) was that it was too buggy to be worth it. Specifically, it would initiate OTR conversations with people without me asking. I think it even did so when I explicitly told it not use OTR at all, though it's been a while. If they fix that I might use it again. Do you have this problem, and/or have they fixed it to your knowledge?
  - bdkoepke 12y ago
    I think the version in f-droid is 13.1.2. If you enable the guardian repository in f-droid that should have the 14.0.9 client which is considerably nicer. You can disable all otr if you want, or set it so you need to explicitly enable it when you are chatting with someone. The latest version has adopted the Android L theme as well so it is very well integrated. (I did have the same issue as you with the version in the f-droid repository).
- ncza 12y ago
  If I recall correctly the issue with ios xmpp clients is that you cannot run them in the background. Instead you must either have a provider that does push notifications or the client has to run constantly, draining the battery and closing automatically every now and then. At least that was the fatal result when I tried to convince friends to use xmpp a while ago.
  - bdkoepke 12y ago
    I personally don't use iOS so I'm not sure whether that is still an issue. They released an update for the iOS client fairly recently so you could give that a shot? The new iOS client seems like it is very nice: https://chatsecure.org https://chatsecure.org.
andyrj 12y ago
"If there was a way to efficiently cycle through DH parameters, an active man-in-the-middle attacker could spoof the fingerprint." Isn't this a rather big if? In my limited understanding of the math involved, the whole reason dhe is still secure is because this isn't the case. Which means an attacker couldn't just use any old sha1 collision, it would have to corellate to a valid set of dh params, which would have an effect on the computational complexity, right?
- yk 12y ago
  This is not a attack on DH, it is a attack on the verification mechanism. So the trick is, the attacker does not need to break DH, he just needs to find two sufficiently similar DH parameters, that the verification still works.
  - andyrj 12y ago
    I understand that this is not an attack on DH. I have not analyzed telegram but the statement I quoted seems to indicate it would need to be able to quickly generate many DH params. That doesn't seem to be a a computationally trivial task. http://security.stackexchange.com/questions/51129/can-you-generate-diffie-hellman-parameters-quickly http://security.stackexchange.com/questions/51129/can-you-ge... It seems like for this attack to be realistic you would need the math underlying DH to be broken somehow. At which point I think there are many applicatons who's security would be compromised that are far more disturbing than the security of telegram. Again I am asking for clarification because I may be misunderstanding the use of the quoted text and I have not looked at the code myself. As I read it, this analsis seems akin to someone stating that, a wall provides no security if we lived in an alternative universe where solids could freely pass through one another. That statement maybe true but who cares, that universe wouldn't continue using walls for security measures anyways. Excuse my metaphor there, I hope it clears up what I was asking about.
    - yk 12y ago
      As far as I understand the attack, the attacker brute forces his own DH secret, not the DH parameters. So attacker has the parameters for both connections, gets the public keys from both chat partners and then brute forces two secrets such that the hashes of the resulting DH shared secret match. For this the attacker needs 'only' to brute force the keys, not the parameters.
sddelbecbc 12y ago
https://crypto.cat/ https://crypto.cat/ is another alternative.
- realusername 12y ago
  There is still no Android app so I'm not sure we can consider it as an alternative.

169 points by escapologybb 12y ago

air 12y ago

"This past spring, Juliano Rizzo (@julianor) and I came up with a cryptographic attack on Telegram's MTProto "secret" chat communications which can be performed in O(2^64) time." Using asymptotic notation without an argument (usually "n") makes me cringe. O(2^64) = O(1)

aw3c2 12y ago

Huh! Just yesterday I was fed-up with Textsecure being so buggy and bad that I looked at the Telegram homepage and thought "nice" apart from not completely being free software (or is it?). It says "Telegram messages are heavily encrypted and can self-destruct." which made me believe that all messages are heavily encrypted. Now this post says "By default, messages (...) are logged and stored on Telegram's servers". Damn.

sz4kerto 12y ago
"By default, messages (...) are logged and stored on Telegram's servers". Because most of the users need this for keeping the message history and they would not use Telegram otherwise.
- praseodym 12y ago
  It also provides the user the ability to use several clients, e.g. on smartphone + laptop + tablet. That's a big advantage over e.g. WhatsApp.
  - phillc73 12y ago
    This is why I use Telegram. I was spending far too much money sending SMS messages to my friends overseas. A few hundred per month at EUR0.12 each starts to add up pretty quickly. Data is cheap, so instant messengers tend toward being almost free. Telegram has official clients for my FirefoxOS phone and for my Linux desktop. I've never used their secret chats. I appreciate their open source nature and am happy to support them.
- aw3c2 12y ago
  I should have included "in a way that allows Telegram to view the message contents" in my quote then. They should be stored encrypted.
cyphunk 12y ago
This is exactly the problem with the communities "greater than though" tone toward anything non-EU/US engineered. The Telegram client is open source. Threema for example is NOT. WhatsApp for example, is NOT. Facebook Messenger, is not. Telegram appears to have the right balance in getting real peer review from having the system open source and verifiable while also garnering this huge animosity which has lead to even more review. As far as I can see Telegram and TextSecure are the only clients where the protocol can be verified through the open source client. I'm not advocating for its use but I'm sick of the misconceptions.

sz4kerto 12y ago

"Some viable alternatives I can recommend are Threema or TextSecure." The problem with Threema and TextSecure is that it's hard to convince my friends to use them because - Threema is not free and does not have desktop/web clients, and multi-device setup is not supported afaik - TextSecure is not really multi-platform The only popular, multiplatform messengers at the moment are Whatsapp, FB Messenger, Viber/Line and Telegram. Whatsapp doesn't have a desktop client, Messenger requires a Facebook Login, Telegram and Whatsapp does not have voice chat and I hate Viber's design -> so I keep using Telegram for messaging and Skype for voice. The network effects can be very nicely observed in messenger usages. In my home country almost everyone uses Viber, but in other countries I have worked (W-EU) almost everyone uses Whatsapp. In Germany people seem to know Telegram, in other places nobody heard about it.

dsacco 12y ago
I know you most likely meant synchronous voice chat, but if you can deal with asynchronous voice chat, you'll be able to have full end-to-end encryption for that and text messages using WhatsApp in partnership with Open Whisper Systems in the near-ish future.
- sz4kerto 12y ago
  Yeah, that's not really acceptable when I'm calling the tax authorities or my car dealer to arrange an appointment :) for that purpose, Skype is 100% workable for me (even under Linux).
  - deleted 12y ago
    [deleted]
cyphunk 12y ago
Threema, Facebook, WhatsApp are not open source. TextSecure and Telegram have open source clients allowing for verification and trust of the protocol.
- 12y ago

tomaskafka 12y ago

Isn't all this pointless when Telegram could just MITM everyone at will of any agency, as the client is closed source? Unless the whole client code is audited by third parties (and it is ensured that app store version = audited version), this whole exchange of keys with colorful qr code could be a charade.

cyphunk 12y ago
wtf? client is all OSS https://telegram.org/source https://telegram.org/source
- dsacco 12y ago
  I believe the OP was referring to the fact that you have no assurance the application binary you receive on mobile is the same as the public open source version. This goes hand in hand with a third party audit. Whether or not it's open source doesn't mean much if you can't audit it. Open source counts if you're a developer and can read the code to see that a piece of software isn't e.g. calling home with user credentials in cleartext and storing them or worse. But this is a custom cryptosystem. Most people can't audit it, and the people who can are not going to use their (extremely lucrative) skillset on the software without personal investment like "I want to use this." Are they going to pay a consulting firm like Riscure to completely audit the codebase? No? Then it is insecure until proven secure. Open source isn't good enough.
  - cyphunk 12y ago
    Okay this problem of binary verification you should blame on Google and Andriod app ecosystem. At least on andriod if you install the apk yourself with Telegram and TextSecure you know exactly what you are running. For everythign else, you have no clue.
    - riquito 12y ago
      > if you install the apk yourself [...] you know exactly what you are running No, you don't. You know what you're running only if you compiled the sources or if you can compare the binary signature with the build of someone you trust (you or others that built from sources).

cyphunk 12y ago

Every one of these new chat systems have similar problems with key authentication. they fail in similar ways and try to solve the problem in similar and different ways. This articles contribution, while very valid with its "greater than though" tone, is gets on my nerves. I have no idea why it always seems to be a constant when people talk about Telegram without really investigating the dramatic headlines authors claim. Is it that we just hate anything engineered in Russia, China. Its boring already.

dsacco 12y ago
Do you have a data point to suggest real bias against the geographic engineering behind Telegram? All the substantial warnings I have read against it revolve around its lack of a respected crypto team (in fact, not having any experienced crypto team and conflating a bunch of maths PhDs with a real crypto team), not using acknowledged crypto design best practices (and flagrantly ignoring them for counrer-intuitive designs), and most importantly, using a contest instead of a real audit. Contest != audit. An audit has a specialized team of cryptographers who try to break the application in any scenario. A contest has restrictive scope that sets up a strawman and doesn't attract real, serious crypto auditing. As an example, this article's MITM doesn't qualify despite being a real attack. A contest means that you have no real knowledge of whether the crypto is broken if nobody succeeds. An audit means you can be significantly towards certain. You might already know this, but consider that if someone hosts a contest instead of an audit, and has all the other issues stated above, they will be met with hostility.
- cyphunk 12y ago
  Valid criticism but I feel the items you mention get blown out of proportion. The Cryptocat team had similar areas where it was lacking and yet did not suffer the same backlash. This could be because they never ran a competition and worked to find a way to fund an audit several years later instead. The data point(s) that lead me to wonder of a geographic bias have to due with the tone of prior analysis of telegram I've read over the past year. This article included. And also a general, very male, arrogance in the security community that seems to constantly search for any reason to ridicule. I will have to go back and trace the history of my perception to find the tone I mention, which I can do tomorrow if you likewise can provide a datapoint for your understanding that they flagrantly ignored crypt design best practices. In watching the evolution of Pond, Telegram and TextSecure we see that to solve security or usability problems designers are required to venture to some degree into uncharted territory, away from best practices. So I question the flagrant claim. But I agree contests are just marketing ploys, little else. If Telegram wanted to "claim" otherwise they would need to start with paying the analysts from this article the full bounty.

utnick 12y ago

So the attack is due to the fingerprint of the key being smaller than the actual key and therefore theoretically possible to find another key with the same fingerprint.. Doesn't textsecure and threema have the exact same problem? Both show a fingerprint to the user instead of the actual key.

semi-extrinsic 12y ago
If that's the attack, then it's well known that PGP is also vulnerable to the same thing: http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...

known 12y ago

I like https://icrypt.me/ https://icrypt.me/

Shank 12y ago

I find it interesting in how there is some dependence on the fingerprint secret being shared across the Telegram channel in order to verify identity. What if a user sends the screenshots of the fingerprint over, say, a medium decided in the chat on the fly? Unless you can MITM every service they're using, you could just /tweet/ the fingerprints, for instance, and check on a different machine for a matching key. Or what if the screenshot is tampered with by hand, like, signing the center of the square with a finger drawn, transparent signature? How would an attacker replicate that? Of course, the "supervillain" model still works and enough computation time and power might find it, but there are a multitude of ways to ensure that the secrets match on everyone's devices.

shmerl 12y ago

They still didn't release the server code, didn't they?

huhtenberg 12y ago
And what would this accomplish exactly?
- spoiler 12y ago
  It could reveal potentially exploitable server-side bugs.
- shmerl 12y ago
  It can start a discussion on trusting it. Without that code it doesn't even start.
  - rakoo 12y ago
    Wrong, the whole point of end-to-end encryption is that security doesn't rely on intermediaries working as expected; they're only transports. Which is why having Telegram's server code wouldn't be useful from a security POV. What it could be used for instead is running alternate "pods" to distribute load over multiple servers.
    - shmerl 12y ago
      It's not all end to end. And there is a difference if the server is a malicious one. Anyway, since the service is centralized and not federated even if it will become all end to end encrypted, it's enough of a reason not to use it.
StrLght 12y ago
It sounds like you except that to happen. I don't think they will ever do that.
- 12y ago

imaginenore 12y ago

O(2^64) is the same as O(1) Pretty pointless estimate. Just for reference to see how large 2^64 is, 2^64 microseconds = 584,555 years Even if you find 10,000 computers capable of 1 million checks per second (a huge "if"), it would still take 58 years.

logicallee 12y ago
Maybe it's the historian in me, but I found your numbers really, really funny! >Even if you find 10,000 computers capable of 1 million checks per second (a huge "if"), it would still take 58 years. I'm sorry if I'm missing the context but it sounds straight out of 1958! Like, when a PC takes a room, costs $2.9 million (2014 $23.1 million), and comes with a with a processing speed of around 100 Kflop/s [1] Like, "even if you find TEN THOUSAND" computers - like where would anyone find ten thousand computers in 2014 (Amazon and Microsoft's cloud farms only have like a million servers instnatly available on their clouds).... capable of a MILLION checks per second! That's a full Megahertz! It would still take you 58 years :) :-D Sorry!! It would have been a good argument in 1958 though :-D [1] http://en.wikipedia.org/wiki/IBM_7090 http://en.wikipedia.org/wiki/IBM_7090
- hurin 12y ago
  2^64 is expensive, but breakable.
  - logicallee 12y ago
    I was specifically referring to the OP's awed overtones of 10,000 x 1 mhz, resulting in 58 years. Which I found really funny. The idea of 2^64 being inherently a large number... when a single graphics card costing a couple of hundred incidentally goes through 2^64 flop's all by itself every few weeks. There's nothing expensive about 2^64 as such. I mean it's expensive in the sense of, we're talking dozens of dollars here :)

bdkoepke 12y ago

I don't know why ChatSecure by the guardian project never comes up in these discussions: https://guardianproject.info/apps/chatsecure/ https://guardianproject.info/apps/chatsecure/ It uses Otr for encrypted chat, so you can use any otr client for the other side of the chat. I personally use pidgin on my laptop and ChatSecure on my cell. It currently supports at least iOS and Android, which encompasses most people that I know.

orblivion 12y ago
My experience with Chatsecure (at least the version I got from F-Droid) was that it was too buggy to be worth it. Specifically, it would initiate OTR conversations with people without me asking. I think it even did so when I explicitly told it not use OTR at all, though it's been a while. If they fix that I might use it again. Do you have this problem, and/or have they fixed it to your knowledge?
- bdkoepke 12y ago
  I think the version in f-droid is 13.1.2. If you enable the guardian repository in f-droid that should have the 14.0.9 client which is considerably nicer. You can disable all otr if you want, or set it so you need to explicitly enable it when you are chatting with someone. The latest version has adopted the Android L theme as well so it is very well integrated. (I did have the same issue as you with the version in the f-droid repository).
ncza 12y ago
If I recall correctly the issue with ios xmpp clients is that you cannot run them in the background. Instead you must either have a provider that does push notifications or the client has to run constantly, draining the battery and closing automatically every now and then. At least that was the fatal result when I tried to convince friends to use xmpp a while ago.
- bdkoepke 12y ago
  I personally don't use iOS so I'm not sure whether that is still an issue. They released an update for the iOS client fairly recently so you could give that a shot? The new iOS client seems like it is very nice: https://chatsecure.org https://chatsecure.org.

andyrj 12y ago

"If there was a way to efficiently cycle through DH parameters, an active man-in-the-middle attacker could spoof the fingerprint." Isn't this a rather big if? In my limited understanding of the math involved, the whole reason dhe is still secure is because this isn't the case. Which means an attacker couldn't just use any old sha1 collision, it would have to corellate to a valid set of dh params, which would have an effect on the computational complexity, right?

yk 12y ago
This is not a attack on DH, it is a attack on the verification mechanism. So the trick is, the attacker does not need to break DH, he just needs to find two sufficiently similar DH parameters, that the verification still works.
- andyrj 12y ago
  I understand that this is not an attack on DH. I have not analyzed telegram but the statement I quoted seems to indicate it would need to be able to quickly generate many DH params. That doesn't seem to be a a computationally trivial task. http://security.stackexchange.com/questions/51129/can-you-generate-diffie-hellman-parameters-quickly http://security.stackexchange.com/questions/51129/can-you-ge... It seems like for this attack to be realistic you would need the math underlying DH to be broken somehow. At which point I think there are many applicatons who's security would be compromised that are far more disturbing than the security of telegram. Again I am asking for clarification because I may be misunderstanding the use of the quoted text and I have not looked at the code myself. As I read it, this analsis seems akin to someone stating that, a wall provides no security if we lived in an alternative universe where solids could freely pass through one another. That statement maybe true but who cares, that universe wouldn't continue using walls for security measures anyways. Excuse my metaphor there, I hope it clears up what I was asking about.
  - yk 12y ago
    As far as I understand the attack, the attacker brute forces his own DH secret, not the DH parameters. So attacker has the parameters for both connections, gets the public keys from both chat partners and then brute forces two secrets such that the hashes of the resulting DH shared secret match. For this the attacker needs 'only' to brute force the keys, not the parameters.

sddelbecbc 12y ago

https://crypto.cat/ https://crypto.cat/ is another alternative.

realusername 12y ago
There is still no Android app so I'm not sure we can consider it as an alternative.