undefined | Better HN

0 pointslogicallee11y ago0 comments

> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine.

I disagree with you completely and absolutely. Your bridge in Boston isn't going to collapse the moment a researcher sitting in his bathtub in Tel Aviv has a eureka moment.

But if that eureka moment results in a preimage collision in a secure hashing algorithm, that hashing algorithm is broken for everyone all over the world forever. (Practically, as soon as the collision is public knowledge). Cryptographers have to actively seek out this information.

That's why MD5 is deprecated, even though the weakness is weaker than the one I've just stated. (It's just a chosen prefix collision that can be done today - a preimage [chosen hash] attack still takes nearly the full search space.)

Security is applied mathematics, the way engineering is applied physics. But the laws of physics don't change on an annual basis, or the way in which they change is too low-level to apply to engineering, whereas the laws of applied mathematics do.

Systems administrators have to keep up to date on an even more active basis, in some cases needing to patch any system within 48 hours of a public disclosure.

So I simply disagree that as an engineering endeavor implementation of cryptosystems is in any way similar to any other form of engineering.

In fact, for the particular example I used in the above case (a hash), the very existence of the operation is an open problem. ("The existence of such one-way functions is still an open conjecture", Wikipedia.)

What other branch of engineering relies on laws that may well be false?

0 comments

austinz11y ago

While it is true that fundamental weaknesses in cryptographic theory may be discovered at any time, the implementation of cryptosystems is, I would assert, still very much like engineering. Broken theory is distinct from broken implementation, although broken theory does end up breaking implementations as well.

Maybe some mathematician will prove AES is broken tomorrow. In terms of the analogy, I don't care. The most qualified, fastidious engineer building the most correct implementation of AES is going to have an insecure system on their hands at the end of the day if that's true, and there is nothing we can do about that on the implementation side.

This is distinct from some programmer reading "Learn Crypto in 24 Hours", building a bad implementation of an otherwise secure cryptosystem due to inexperience or carelessness, and then screwing people over because that bad cryptosystem goes into production code.

j / k navigate · click thread line to collapse