Top 25 Series – Rank 24 – Use of a Broken or Risky Cryptographic Algorithm

There are a few rules every developer should follow when applying encryption:

– don’t invent your own algorithm
Cryptography is a difficult topic, best left to the experts. Implementing encryption algorithms is difficult and there are many traps waiting. Many times, you can get away with a broken custom algorithm, but only because nobody challenges the implementation. If you are happy coding unimportant websites nobody needs, then your time is probably cheap enough where you don’t mind wasting a few hours implementing your own broken algorithm.

It is best to stick with standard algorithms. Currently, AES (American Advanced Encryption Standard) is the standard encryption algorithm. The advantage of using a standard like AES is that you will find support in various programming languages and that future support is likely as well.

– use the strongest algorithm you can find
Cryptography is a constant battle against the ever increasing abilities to break encryption. Not only do researchers use better and better hardware to brute force encryption keys, but they also come up with more efficient algorithms to search for the key.

It is important to “over design” encryption. The goal should not be to find a “sufficient” algorithm, but the best you can find/afford. It is very hard to predict how de-ciphering techniques will evolve in the next 5 or 10 years.

Even if you use a strong encryption algorithm, understanding the details of implementing the particular algorithm is important. Whenever encryption is implemented, it is important to read any instructions that accompany the related libraries.

5 thoughts on “Top 25 Series – Rank 24 – Use of a Broken or Risky Cryptographic Algorithm”

  1. Implementing encryption is mandated by standards like PCI-DSS, however this can be done so wrong it makes the encryption worthless.

    There is nothing in the “manual” of implementing an encryption algorithm that prevents big application architecture security problems.

    For Example (a quote from my blog):

    A well intentioned programmer decided to use Triple DES as the underlying cypher and understood that the key must be kept a secret. He created an Oracle package (a group of stored procedures, stored functions, and common data variables) where he included an encrypt and decrypt function. He then used the Oracle “wrap” utility to “encrypt” the package because the key he used was hard coded into the package.

    The underlying cypher is good. And this method will protect the data stored on backup tape. However, it completely negates the need for knowing the key to decrypt the data in a live environment. A SQL Injection attack can reveal the decrypted data (in this case credit card numbers) without knowing the key.

  2. Hello

    i need some help basically i’m very much interested to know more about Tiger Hash Fucntions. I’m studying
    Bsc Information Security at Salford University. I would be most greatful if anyone out there could provide me information or point to the right direction. Here the areas i’m try to investigate.

    1. Implications of tiger hash functions being used in any communication systems?
    2. How can tiger hash function be enhanced or upgraded?
    3. What new ways can tiger hash functions are used in security?
    4. What are the critical analyses of tiger hash function in the last 5 years?
    5. What are the limitations of tiger hash functions in communication systems?
    6. Why can tiger hash function not be used for other purposes?
    7. Can tiger hash function be used for a short or long term and why?
    8. Overview of the tiger hash function problem



Leave a Reply

Your email address will not be published. Required fields are marked *