Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

Generally, the thing with cryptography is the first breaks tend not to be useful. Crafted messages, terabytes of data, a compromise in one round of several in the key, etc. Theoretical stuff.

But they then tend to get worse rapidly, building on those useless cracks to drive the wedge deeper. And so in general it's best to assume that if something's slightly broken, soon it will be all the way broken.

View on HN

As a counterpoint (for crypto algo design), we seem to have gotten much better at designing things so that small breaks don't turn into large breaks.

https://rwc.iacr.org/2020/slides/Aumasson.pdf

That isn’t really the case. Sha1 still isn’t broken in a particularly useful way. Md5 is still basically safe from pre-image attacks.

https://shattered.io/

SHAttered is a collision attack on SHA-1, not a pre-image attack. There is no known pre-image attack for SHA-1.

Yet. We get closer every time a new vulnerability is discovered.

> Yet. We get closer every time a new vulnerability is discovered.

Skipjack is the famous counterexample to this: it's been broken up to 31 rounds, but specified usage mandates 32 rounds. Skipjack was given immense scrutiny due to the NSA's role in its design, and we're no closer to a full-round break of it than we were in 1999.

Even that is only theoretical, it's not a practical attack.

MD5 even still has pre-image resistance. A practical preimage attack would indicate something even more serious was overlooked with a design of a hash function. A practical attack would mean you could reverse the value of what produced the hash, by just using the hash.

Only seriously lousy cryptographic hash functions would have bad preimage resistance. Heck even the pigeon hole principal makes this aspect of design easier for a hash function. If a wildy used hash function some how had a practical pre image attack i would be more concerned about our process of standardizing algorithms.

Collision attacks can still be useful in an attack tree

This is quite disingenuous, as with hash functions there's infinite preimages that map to each digest.

It’s not at all. Understanding the differences between the types of hash image resistance is critical to know whether it matters for your application.

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).

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.

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.

> 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/

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.

AES has been broken for over a decade. 256 bit AES is actually only 255 bits strong. It has not progressed any further, and AES is the most popular algorithm globally and has had over two decades of eyes on it.

This definitely is not generally true, especially for “academic breaks” that don’t even approach feasibility.

I really think security people fear the wrong things. Unless they are fundamentally flawed very few actual crypto breaks happen in practice. Most real world breaks are the result of implementation bugs, side channel attacks, and social engineering.

If I had to choose between a buggy code base implementing Noise with the latest hipster crypto and a well written memory safe audited code base and protocol using RSA-1024 and RC4, I would feel safer with the latter. (Unless my adversary were the NSA or someone else at that level, in which case I would layer three or four systems for defense in depth.)

This is not an argument for the use of weak crypto. It’s an argument for fearing the implementation, deployment, and users more than the crypto.

Big blobs of C are scary regardless of what they implement, especially if they are messy and have not had many eyes on them. The meat bag in front of the computer is usually the least secure component. If you look at real world breaks it’s usually bad opsec or phishing. The hipsterest crypto won’t help you if you are tricked into running malware or you have an insecure PHP script on a web server.

RC4: https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy#Weak_...

Point taken. I may have reached for too extreme an example, but AFAIK there were other issues with the WEP construction besides just RC4 being weak.

I think the point still stands though. When I read about breaks (and when I saw them back when I did infosec) it was phishing most of the time. Someone would be tricked into running malware. That’s how most organizational compromises happen. The rest were memory errors like buffer overflows in non-security application code and bugs in bespoke code exposed to the Internet.

My point was that people are afraid of the things that are sexy to be afraid of, and tend to ignore the more mundane but more commonly attacked vectors.

The same applies to firewall obsession in netsec. People will obsess over the firewall and then type “npm install” on production systems. It’s not sexy to worry about that.

Package managers scare the shit out of me…

Reply on news.ycombinator.com