4 ms·

Care to give some sources for this claim? Even with some examples, it seems very vulnerable to the survival bias (examples where small flaws did not lead to a b

by Siira 5y ago

Care to give some sources for this claim? Even with some examples, it seems very vulnerable to the survival bias (examples where small flaws did not lead to a big blowdown are not paid attention to).

lucb1e 5y ago
They're not wrong in principle: attacks do often start as implausible and then some other shortcut or weakness is found and bam, there is a realistic exploit out of something that was deemed completely infeasible. I think in this context, it's a bit more nuanced. These shortcomings are fixed (I can't personally vouch for the correctness of the fix as I haven't looked at the source diff, but let's assume it's solid), so they're not left to linger and build on. There was also a more serious bug in the past though I forgot the details. If this is the worst they're finding now, I'm not so worried. What I hear of mtproto doesn't sound like bugs are compounding but rather like they're ironing our small (but not completely unimportant, of course) flaws. But of course we won't truly know if it's secure until someone finds a devastating attack.
- bjoli 5y ago
  The old attack was that the server provided the client with randomness when generating keys for private chats, allowing the server to effectively MITM all private chats. Pretty weird design decision.
martinralbrecht 5y ago
> As an aside, Jakobsen and Orlandi wrote: “We stress that this is a theoretical attack on the definition of security and we do not see any way of turning the attack into a full plaintext-recovery attack.” Similarly, the Telegram “FAQ for the Technically Inclined (MTProto v.1.0)” provides the following analogy: “A postal worker could write ‘Haha’ (using invisible ink!) on the outside of a sealed package that he delivers to you. It didn’t stop the package from being delivered, it doesn’t allow them to change the contents of the package, and it doesn’t allow them to see what was inside.” In hindsight, we think that this is incorrect. As explained above, our timing side channels essentially exploit this behaviour in order to do message recovery (but we need to “chain” two “exploits” to make it work, even ignoring practicality concerns). https://mtpsym.github.io/ https://mtpsym.github.io/
bitexploder 5y ago
You can simply see the history of algorithms over the last two decades. Look at things like RC4, which is notoriously hard to use safely. It had a history of many issues and was ultimately abandoned even though you could theoretically use it securely to this day. It is situational, but with cryptography, algorithms are deprecated from an abundance of caution in many cases. It’s a little different with a protocol and not a foundational algorithm, though. We can often correct a protocol in a safe way compared to an algorithm that is often simply deprecated. Still the sentiment is mostly correct, but perhaps a bit overstated.

by Siira 5y ago

Care to give some sources for this claim? Even with some examples, it seems very vulnerable to the survival bias (examples where small flaws did not lead to a big blowdown are not paid attention to).

lucb1e 5y ago

They're not wrong in principle: attacks do often start as implausible and then some other shortcut or weakness is found and bam, there is a realistic exploit out of something that was deemed completely infeasible. I think in this context, it's a bit more nuanced. These shortcomings are fixed (I can't personally vouch for the correctness of the fix as I haven't looked at the source diff, but let's assume it's solid), so they're not left to linger and build on. There was also a more serious bug in the past though I forgot the details. If this is the worst they're finding now, I'm not so worried. What I hear of mtproto doesn't sound like bugs are compounding but rather like they're ironing our small (but not completely unimportant, of course) flaws. But of course we won't truly know if it's secure until someone finds a devastating attack.

bjoli 5y ago
The old attack was that the server provided the client with randomness when generating keys for private chats, allowing the server to effectively MITM all private chats. Pretty weird design decision.

martinralbrecht 5y ago

> As an aside, Jakobsen and Orlandi wrote: “We stress that this is a theoretical attack on the definition of security and we do not see any way of turning the attack into a full plaintext-recovery attack.” Similarly, the Telegram “FAQ for the Technically Inclined (MTProto v.1.0)” provides the following analogy: “A postal worker could write ‘Haha’ (using invisible ink!) on the outside of a sealed package that he delivers to you. It didn’t stop the package from being delivered, it doesn’t allow them to change the contents of the package, and it doesn’t allow them to see what was inside.” In hindsight, we think that this is incorrect. As explained above, our timing side channels essentially exploit this behaviour in order to do message recovery (but we need to “chain” two “exploits” to make it work, even ignoring practicality concerns). https://mtpsym.github.io/ https://mtpsym.github.io/

bitexploder 5y ago

You can simply see the history of algorithms over the last two decades. Look at things like RC4, which is notoriously hard to use safely. It had a history of many issues and was ultimately abandoned even though you could theoretically use it securely to this day. It is situational, but with cryptography, algorithms are deprecated from an abundance of caution in many cases. It’s a little different with a protocol and not a foundational algorithm, though. We can often correct a protocol in a safe way compared to an algorithm that is often simply deprecated. Still the sentiment is mostly correct, but perhaps a bit overstated.