There has been a great deal of difficulty experienced in getting research performed by cryptographers in the last decade or so (beyond basic algorithms such as SHA and AES) applied in practice. The reason for this is that cryptographers don't . . .
There has been a great deal of difficulty experienced in getting research performed by cryptographers in the last decade or so (beyond basic algorithms such as SHA and AES) applied in practice. The reason for this is that cryptographers don't work on things that implementors need because it's not cool, and implementors don't use what cryptographers design because it's not useful or sufficiently aligned with real-world considerations to be practical. As a result, security standards are being created with mechanisms that have had little or no security analysis, often homebrew mechanisms or the standards editor's pet scheme. The problem is a lack of communication: Cryptographers often don't seem aware of the real-world constraints that their design will need to work within in order to be successfully deployed. The intent of this document is to cover some of those real-world constraints for cryptographers, to point out problems that their designs will run into when attempts are made to deploy them. Also included is a motivational list of extremely uncool problems that implementors have been building ad-hoc solutions for since no formal ones exist.

"Looking at all of the security protocols deployed in the last 10 years, you'd be forgiven for thinking that the only developments in crypto during that time (beyond basic algorithms) were HMAC and SPEKE"

The link for this article located at Peter Gutmann is no longer available.