Hacker News Reader

Comment by nvr82 | Hacker News Reader

Steel is not rolling it's own crypto. It uses AES in cfb mode as implemented by libmcrypt.

Building your own abstractions on top of AES directly is no less dangerous or prone to error.

> Building your own abstractions on top of AES directly is no less dangerous or prone to error.

You're telling me it's just as dangerous to implement a well-known library that has working AES-CFB as it is to roll your own AES-CFB implementation?

That's silly. Yes, it's dangerous to do any form of crypto. But there are really good resources on how to implement it correctly, and if you're using an existing library, the risks are significantly reduced.

Yes, insofar as the likelihood of introducing an exploitable catastrophic flaw in either scenario is essentially 1.

If you think you can just slap AES on something and call it a day, you're going to have a bad time.

This can be reduced to a simple mathematical equation:

    (risk of hand rolling AES * risk of poor implementation) > risk of poor implementation

Also, if your assumption that the likelihood of introducing a catastrophic flaw is 1 was correct, there would be no correctly implemented crypto anywhere (although it would make the above equation false).

I agree with the nature of your arguments: crypto must be treated with care, and must be vetted by experts. However the whole "DON'T DO CRYPTO EVER!!" mindset is a lot more harmful in the long run. It's a powerful and dangerous tool, but it should be documented and understood instead of making us cower in fear.

Sorry, I missed your reply to this. In case you do ever read this, my point is that:

    (risk of an amateur hand rolling AES * risk of poor implementation by an amateur) = risk of poor implementation by an amateur + epsilon = 1

Even experts make mistakes in these things, but amateurs don't even stand a chance. An amateur will make more mistakes doing both, for sure, but there are bound to be enough catastrophic flaws that it simply doesn't even matter at that point. More real-world attackers are going to try and exploit your abstractions on top of AES than try to exploit your AES implementation itself.

Reply on news.ycombinator.com