The state of crypto products

[ciphergoth]

Just read this story on Slashdot, so in curiosity I downloaded the paper. And I have to echo and extend comments Peter Gutmann made about the state of crypto under Linux: when you hear about a product that uses crypto, open source, Linux based or otherwise, just assume that the crypto is woefully cack-handed rubbish from someone who's read Applied Cryptography if that.

ssh v2 is mostly OK. TLS (SSL v3.1) is mostly OK. GPG is mostly OK. IPSec is mostly OK. I don't know of anything else that people in the field think well of.

Comments

[ciphergoth.livejournal.com]

I know how bad OSS crypto is, and it sucks. We don't know as much about CSS crypto of course, but from what we do know, if anything it sucks much worse for the most part.

[pavlos.livejournal.com]

I guess you are caught between the two management deficiencies.

OSS - It's nobody's job to fix anything or provide a solid total package.
CSS - Management decides to fix only those issues that everyone knows about.

Honestly, I think important crypto for an ordinary geek is impractical and for a lay user it would be reckless. It might work and be better than nothing, but betting your freedom on it would be reckless.

Pavlos

[ex-meta.livejournal.com]

I think it's probably because the criteria by which cryptographic software is evaluated are utterly different to the success factors for most other kinds of software.

Cryptographers, I expect, value things like correctness, buglessness, straightforward coding style (to allow for review), and simplicity (to reduce the likelihood of errors).

Success factors for software in general seem to be coolness, early release, overgeneralization, and number of features.

[ciphergoth.livejournal.com]

I'm sure the software is full of security bugs as well, but that wasn't the problem that drew my ire. I mean that the high level cryptographic design is awful. Mistakes like using RSA without padding, failing to use a real MAC for authentication, using predictable IVs in CBC mode and so forth are commonplace - and they won't fix them even when you tell them exactly how to, because they don't know enough to understand that these are mistakes and refuse to listen.

Actually I'm coming to the conclusion that in general, choosing RSA is a bad sign. In particular, I don't know of a single advantage it has over Rabin-type schemes besides being a little easier to understand - Rabin is faster and provably as hard as factoring to break - but RSA is famous, so that's what people use. Not that Rabin is necessarily the best choice for all circumstances, but use of RSA indicates that no-one sat down and asked themselves "which of the zillions of asymmetric primitives is right for this application?" - they just thought "PK == RSA" and used that.

Obviously this doesn't apply when you're interoperating with an existing standard that uses RSA, but these monkeys always prefer to cook their own half-baked standards than use something well-understood.

I think it comes as news to these people that cryptography sometimes involves MATHEMATICAL PROOFS.

[pavlos.livejournal.com]

Why is this? I mean I understand how software bugs or design mistakes actually arise, but why does the problem exist overall? I would have expected the field to have the following properties:

• Really slow introduction of new designs.
• Only a handful of designs actively in use.
• Very clear designs, at the expense of other factors.
• Much activity in qualifying and fine-tuning existing designs.

What you are saying suggests the opposite. is it straightforward cluelessness, or that no-one has figured the right sort of abstraction to reuse and refine cryptosystems they way you can ciphers?

Pavlos