There are comments flying around as to whether cryptography should be approached as a science or as engineering. It apparently started on Twitter. Bruce Schneier has weighed in and linked to an interesting essay by Colin Percival.
The actual border lands might not be surveyed yet, but I believe there's a distinct field of cryptographic engineering, just as computer architecture can be independent of circuit design. In both cases we try to establish design rules so that engineers can build things with predictable properties. In both cases we can push the envelope of those rules and yield disaster.
We establish an engineering discipline by trying to codify the design rules, teach them, build with them, and assess the results. That's what we see in security/cryptographic engineering these days. It's healthy even though we end up with occasional vulnerabilities.
Crypto and Proofs
Colin Percival argues that we should treat cryptography as a science, since we have the tools to prove cryptographic properties. The problem is that the provable mechanisms don't just drop magically into working systems. They must be integrated into a system that has all sorts of other properties, many of which could weaken or destroy the effectiveness of the crypto mechanisms.
The security community went this route back in the 1980s - the Orange Book tried to establish a set of standards for building computers with provable security properties. In a sense they succeeded, because we bulit many such systems (LOCK, for example). However, the provable properties were rarely the ones that determined the success or failure of the system in question. We would spend maybe 25% of the development cost on incorporating some provable properties, and deduct that 25% from the testing budget. The result was always a system that met a few abstract requirements but failed at doing more concrete things, like operate reliably.
I believe that crypto engineering exists as a discipline, and I've tried to write books to help the matter along. My first book, Internet Cryptography, was a love-letter to the notion of crypto engineering. There was very little math, and most of the examples were intended to help software designers construct cryptographically sound mechanisms using the available buliding blocks. My textbook is explicit about providing crypto building blocks to use in building secure systems.
Crypto engineering suffers from an image problem because crypto gives the illusion of impenetrable security. In theory we ought to be able to protect information perfectly with our crypto mechanisms, if we can apply the mechanisms correctly, protect the mechanisms effectively, and interpret the results accurately. Thus, some people argue that crypto systems should only be built by mathematicians who can also analyze and prove their correctness. Then the mathematicians write their code in C and forget to check for buffer overflow.