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

[babysimon]

What else is there?

[babysimon]

Sorry, I should have RTFL.

[pavlos.livejournal.com]

Is your point that OSS crypto is especially bad, or no better than CSS?

Pavlos

[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

[giolla.livejournal.com]

Of the 4 you list of course at least 2 have thier roots in CSS. I can't recall where IPSec sprang from but it has had a fair amount of commercial input.

GPG is really an odd one out having started life as OSS drifted into CSS and then back out.

/* Obviously I am looking back to where those 4 first originated from, SSL, SSH, PGP, Sunscreen? */

[giolla.livejournal.com]

Sorry SSH 1. was of course open source at first,though not AFAIR SSH v2.

[ciphergoth.livejournal.com]

I'm not really making a point about open versus closed source software - see my reply to Pavlos. For one thing I'm really talking about protocol design rather than implementation, and terms like "open source" don't exactly apply to protocols (though they can apply to the protocol documentation). Also it's unclear to me how "commercial input" affects a thing's status as open or closed source.

IPSec sprang from IPv6 and was later back-ported to v4.

[giolla.livejournal.com]

As far as the open/closed source thing goes I was just pointing out that at least half of the OSS crypto things you listed have commercial roots.

Which leaves OSS crypto looking even iffier, as what you actually have is:
"OSS crypto is mostly ok when it's implementing things developed in the commercial world."
SSH V1 was not terribly good, V2 was much better and was a commercial development.

The Commercial input comment was because I can't now recall the history of IPSec, but AFAIR it borrowed heavily from commercial products such as SunScreen. So yes the final thing is opensource but based on closed source development which leaves GPG as the only "mostly ok" crypto to have actually come from the world of open source, the rest being "OpenSource copies closed source"

Which doesn't hugely support the idea that CSS crypto "sucks much worse for the most part".

[ephermata.livejournal.com]

The thing to remember with IPSec is that it came out of the IETF. The IETF has a remarkably open process, but most of the people involved are employed by companies. So there are occasionally conflicting loyalties and hidden agendas. At the same time, you have a lot of very smart people trying their best to put together something that works well enough. The resulting process is...interesting. I don't think it would be accurate to characterize it solely as either "open source" or "closed source." It's just IETF.

Someone could write a book on the IETF and security protocols. I am not that person. The closest I've seen to analyzing what goes on are some comments in the Perlman, Kaufman, and Speciner book about the genesis of IKE. Eric Rescorla also had some comments in his presentation on "The Internet is Too Secure Already," but I don't know if he's written them down in more concrete form.