The Simplistic Trio: Three of cryptography's many musketeers

WindowSecurity.com - Simplicity can take on many forms, within the context of cryptography, but we'll look at three “acts of simplicity” that are concerned with the effectiveness of cryptography, in practice. In conclusion – and I know I harp on this quite often – I'll throw in my spiel on using a MAC; it will be short, sweet, and with enough substance to get the point across.

My rationale is simply (pun intended) this: After thinking through these three acts of simplicity, I started to see the correlation between all of them, and how it all pointed toward what I sometimes call "cryptographic conservatism," which is, simply (there I go again), the philosophy of being resourceful and positively paranoid. Someone of this frame of mind would design with security in mind, first and foremost, by eliminating unnecessary complexities and using a primitive for what it can be securely used for (i.e., using a block cipher in both your encryption and authentication schemes), without introducing more primitives, where applicable. Also, this type of cryptographer wouldn't be quick to write off seemingly “unlikely” attack models; they would allow cryptography to address such attack models, and learn that the insider (implied “ally”) is sometimes more potentially dangerous than the outsider (implied “adversary”).

Good paranoia – the kind that isn't put-on-your-tin-foil-hat incompetence-driven – is a crucial step toward building a thorough cryptographic solution. Be reasonable, but not scantily clad. Minimize the assumptions you have to make, where you can. This basically summarizes what you'll read throughout the rest of this article.

Keeping your ducks in a row, and their feathers to themselves

The first act of simplicity is a general principle that exists even more basically than within the realm of cryptography itself; however, when pertaining to cryptography, it becomes a necessity. It does, at least, if you understand the importance of simplifying the analysis of a system to the greatest extent possible. With that said, it shouldn't be too much of a surprise for me to mention modularization of components.

This is a fairly basic concept that coincides with keeping your ducks in a row; it's easier to account for each of them if you do, so you don't have any ducks leading other ducks astray. Although there may be cases of dependence between modules, in some scenarios, stress – and I mean stress – independence between modules. (This is reasonable; it's not always the case where we can entirely eliminate dependencies altogether, but we can minimize them.) Ideally, they should be secure on their own, such that insecurity will be local within that module. This separation of “ducks” into their own respective modules makes analysis much simpler. Simplifying module-to-system interfacing is a cornerstone to why modularity is good; that is, if it's done properly, just as with everything in cryptography. Being modularized pays off tremendously.