Security By Obscurity

Before we had the mathematically sound options for secure encryption and hashing, extra measures were often taken (and some are still today) by the creators of the systems using the encryption process to give them some uniqueness – additional methods of encryption hidden away in the black box of the service provided. Without access to the source code, it’s often impossible to tell how a service is encrypting it’s data.

A very simple example would be double encrypting, or double hashing. This is simply taking the result of an encryption (or hashing) process, and performing the same operation several more times – or perhaps even a completely separate operation – on the resulting encrypted data. More obscure examples of security by obscurity could include customized cryptosystems, unique algorithms, or even adding random data in a predetermined way.

So what’s all this about? Why do people bother with implementing these ideas? The reason is that it changes the fault point in the security of the application. Using a well known encryption system (such as BlowFish, or the SHA-256 hash function) means that you are putting all your eggs into this particular encryption basket – as long as the algorithm remains secure, so does your data. Naturally these days there is little concern for algorithms considered mathematically secure to be broken – but it has happened in the past. With some added obscure security measures, the focus is switched to keeping the design of the system unknown to potentially malicious users. With everything operating in a black box, as long as the source code of the application is not revealed attempting cryptanalysis would be immensely difficult (assuming good practice on the part of the system’s designer).