81–90 of 138 posts
I don't understand why this is such a massive problem (front page news for days now, really?). Mind you, I am not a crypto expert, but enough with the bitching already. Crypto experts, just crack it then.. who cares about the special conditions in the contest which make it so difficult. Just do it, prove your point and carry on. $200k is PR, everyone knows that already.
I don't understand why this is such a massive problem (front page news for days now, really?). Mind you, I am not a crypto expert, but enough with the bitching already. Crypto experts, just crack it then.. who cares about the special conditions in the contest which make it so difficult. Just do it, prove your point and carry on. $200k is PR, everyone knows that already.
This does not make it secure in the slightest, as the terms are set up specifically to exclude most of the attacks that are used in crypto validation these days. See - http://www.thoughtcrime.org/blog/telegram-crypto-challenge/
The contest, as proposed by Pavel, while limited for the moment, does cover an important issue as far as our users are concerned. And the scope will naturally expand with time, should Telegram be invulnerable under the current conditions (see contest FAQ: http://core.telegram.org/contestfaq ). Quoting a post by Pavel here on HN: "Telegram will always be interested in creating incentives for the crypto-community to ch…
First, SHA-1 should be used with the HMAC construction. HMAC is very easy to implement, see RFC 2104. Your developers can do it in a day. You can also use Keccak instead, it does not require HMAC, and there is a version with 224-bit output.
Second, I don't see a problem with IGE. Despite others calling it "ancient," it was proposed at about the same time as CBC. There is a proof of security against adaptive chosen plaintext attacks. Nonetheless, you could use a more studied mode like CTR, but most importantly use the encrypt-then-MAC composition, i.e. AES-CTR + HMAC. (An authenticated mode would be best, but GCM is not easy to implement.)
Finally, the DHKE really must be authenticated. Everything else depends on it, since the key (auth_key) is not ephemeral. The least complicated way to authenticate is the Station-to-Station protocol.
Best of luck.
Earlier quoted context omitted.
TextSecure is also using a protocol of its own design. I think the difference is largely the motivation at the other end. Moxie is genuinely engaged and interested in crypto and, much much more importantly, improving the trust models associated with it (see Convergence as another example). The Telegram guys seem more interested in being a 'hip' app with the latest secure IM solution. This doesn't even necessarily mea…
which are easy to understand and reason about but I know for a fact weren't designed by world class crypto-experts I though Satoshi was anonymous? Do you know something the rest of us don't, or are you making assumptions on the code (and if so, how can you make those assumptions when you also state it was a success)?
He clearly isn't talking about Satoshi when you look at the entire sentance
The contest, as proposed by Pavel, while limited for the moment, does cover an important issue as far as our users are concerned. And the scope will naturally expand with time, should Telegram be invulnerable under the current conditions (see contest FAQ: http://core.telegram.org/contestfaq ). Quoting a post by Pavel here on HN: "Telegram will always be interested in creating incentives for the crypto-community to ch…
Although I am not a cryptographer, I understand the criticism you have received. Some feedback based on my very limited experience: First, SHA-1 should be used with the HMAC construction. HMAC is very easy to implement, see RFC 2104. Your developers can do it in a day. You can also use Keccak instead, it does not require HMAC, and there is a version with 224-bit output. Second, I don't see a problem with IGE. Despite…
I can vouch for this, having just written an (embedded) HMAC implementation in half a day :)
Earlier quoted context omitted.
I'm worried that to people unfamiliar with modern crypto, the diagram of your protocol and the "technical FAQ" might sound credible or even convincing. But it is not. The message integrity protection this system describes is not up to modern standards. The system seems to use SHA1, which is a fault for a new system (no new system should use SHA1), but that's not the biggest problem; the biggest problem is that the SH…
I hope Durov brothers are taking notes. Making a half-baked Facebook clone is not the same as making a fully-secured messaging system. PS: These guys are still copying Facebook. Facebook released a messaging app, so these guys did the same. But, hey, Telegram is different because it uses MITM and it's "secure".
The contest, as proposed by Pavel, while limited for the moment, does cover an important issue as far as our users are concerned. And the scope will naturally expand with time, should Telegram be invulnerable under the current conditions (see contest FAQ: http://core.telegram.org/contestfaq ). Quoting a post by Pavel here on HN: "Telegram will always be interested in creating incentives for the crypto-community to ch…
"Secret Chats do not use mandatory authentication via a third-party or pre-shared information. We may later add an option to forbid Secret Chat initialization, unless the user has confirmed the key (using a QR code, NFC, etc.) for advanced users."
"Forward Secrecy is available for Secret Chats, but requires user action at the moment — it can be achieved by deleting secret chats and creating new ones, or logging out periodically (since logging out kills all secret chats)."
Unless I'm missing something, their recommended way of getting forward secrecy opens users up to man in the middle attacks, since if users are setting up new secret chats often enough to protect against an attacker obtaining their keys and decrypting past messages they're not going to be able to confirm the keys match every time.
Earlier quoted context omitted.
That would be nice. But, for what it's worth: don't use Telegram. It's a mess. TextSecure was built much, much more carefully.
Is TextSecure open source?
Earlier quoted context omitted.
TextSecure is also using a protocol of its own design. I think the difference is largely the motivation at the other end. Moxie is genuinely engaged and interested in crypto and, much much more importantly, improving the trust models associated with it (see Convergence as another example). The Telegram guys seem more interested in being a 'hip' app with the latest secure IM solution. This doesn't even necessarily mea…
which are easy to understand and reason about but I know for a fact weren't designed by world class crypto-experts I though Satoshi was anonymous? Do you know something the rest of us don't, or are you making assumptions on the code (and if so, how can you make those assumptions when you also state it was a success)?
If the crypto is broken, then break the crypto and collect the 200k. Or if its vulnerable to a MITM, then explain how. Or if its vulnerable to chosen plaintext/ciphertext or known plaintest, explain how. There has been so much piling on of telegram, but nobody has actually proven any problems with their code or protocol. Meanwhile telegram is trying to do the right thing by being open source and taking the time to re…
Which is what it's about: cryptography is mostly about trust with a bit of math thrown in. If you can't trust that it won't be broken (see: all the issues 'moxie and 'tptaeck bring up for an example) then it shouldn't be used.