4 ms·

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

by kitd 13y ago

sillysaurus2 13y ago
Interesting. Some observations: TextSecure has been a work in progress for two years: https://github.com/WhisperSystems/TextSecure/commits/master?page=12 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 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.
- haarts 13y ago
  Textsecure != Telegram. Textsecure is a replacement for SMS/text messages and Telegram for Whatsapp type messages. Totally different things.
jzwinck 13y ago
Great, let's take a quick look. TcpContext.java[1] says: MAX_PACKED_SIZE = 1024 * 1024 * 1024;//1 MB READ_DIE_TIMEOUT = 5 * 1000; // 15 sec So those are bugs, though I'm not sure if documentation or code. Most importantly to me, there are very few comments in the code, and the few there are are incorrect. One might infer that this code has been written either in haste, or by someone who believes that comments are not needed in this sort of systems code. There are also writeInt() and readInt() method which seems to be little-endian, which seems odd for a network program. No comments near them. Finally, there's a "Package" class which is just a byte array and a flag. And there's a method which writes it after a cute encoding for the length divided by 4. But there is no code which checks that the length is evenly divisible by 4. This may lead to incomplete Packages being written, with what effect I am not sure. In summary, I wouldn't trust this program, having reviewed one of its source files mostly at random. Oh, and despite its README saying that it is designed for mobile, it uses TCP Keep-Alive, which seems like a bad idea for mobile specifically (due to keeping the radio alive and draining the battery). Again, no comments explaining why. [1] https://github.com/ex3ndr/telegram-mt/blob/master/src/main/java/org/telegram/mtproto/transport/TcpContext.java https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j...
- ToastyMallows 13y ago
  Curious, why are those bugs?
  - rattray 13y ago
    5ms * 1000 != 15s. It's unclear whether the comment is outdated, and 5s is in fact intended, or whether 15s was intended and the 5 is a typo (therefore a bug, although unlikely a critical one). Either way, it's certainly sloppy programming, and the kind of thing that can lead to more serious problems.
    - ToastyMallows 13y ago
      Ah, duh. I was analyzing too in-depth. Thanks.
    - wcummings 13y ago
      Someone probably updated the constant and forgot to / was to lazy to update the comment
tptacek 13y ago
I looked for 4 minutes. * 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.

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

by kitd 13y ago

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

sillysaurus2 13y ago

Interesting. Some observations: TextSecure has been a work in progress for two years: https://github.com/WhisperSystems/TextSecure/commits/master?page=12 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 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.

haarts 13y ago
Textsecure != Telegram. Textsecure is a replacement for SMS/text messages and Telegram for Whatsapp type messages. Totally different things.

jzwinck 13y ago

Great, let's take a quick look. TcpContext.java[1] says: MAX_PACKED_SIZE = 1024 * 1024 * 1024;//1 MB READ_DIE_TIMEOUT = 5 * 1000; // 15 sec So those are bugs, though I'm not sure if documentation or code. Most importantly to me, there are very few comments in the code, and the few there are are incorrect. One might infer that this code has been written either in haste, or by someone who believes that comments are not needed in this sort of systems code. There are also writeInt() and readInt() method which seems to be little-endian, which seems odd for a network program. No comments near them. Finally, there's a "Package" class which is just a byte array and a flag. And there's a method which writes it after a cute encoding for the length divided by 4. But there is no code which checks that the length is evenly divisible by 4. This may lead to incomplete Packages being written, with what effect I am not sure. In summary, I wouldn't trust this program, having reviewed one of its source files mostly at random. Oh, and despite its README saying that it is designed for mobile, it uses TCP Keep-Alive, which seems like a bad idea for mobile specifically (due to keeping the radio alive and draining the battery). Again, no comments explaining why. [1] https://github.com/ex3ndr/telegram-mt/blob/master/src/main/java/org/telegram/mtproto/transport/TcpContext.java https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j...

ToastyMallows 13y ago
Curious, why are those bugs?
- rattray 13y ago
  5ms * 1000 != 15s. It's unclear whether the comment is outdated, and 5s is in fact intended, or whether 15s was intended and the 5 is a typo (therefore a bug, although unlikely a critical one). Either way, it's certainly sloppy programming, and the kind of thing that can lead to more serious problems.
  - ToastyMallows 13y ago
    Ah, duh. I was analyzing too in-depth. Thanks.
  - wcummings 13y ago
    Someone probably updated the constant and forgot to / was to lazy to update the comment

tptacek 13y ago

I looked for 4 minutes. * 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.