Never say never: Unbreakable encryption is a myth

0

There are many things that we take for granted today that were once thought impossible: flying in airplanes, traveling to outer space, running a mile in under 4 minutes, etc. The thing is, none of those things were ever truly impossible. They were simply implausible given the knowledge and technology at the time. As our understanding and techniques evolve, the once impossible becomes the simply mundane.

The same is true for encryption. Yesterday’s virtually unbreakable algorithm is today’s security weakness, and the same will eventually happen to the seemingly unbreakable encryption methods we use today as our knowledge and computing power continue to grow:

We hear a lot about encryption as a magic silver bullet solution that will secure and protect our data. Businesses and consumers are directed to employ encryption wherever possible, and in the wake of any data breach one of the first questions that comes up—often from encryption vendors with a marketing agenda—is whether the compromised data was protected with encryption.

Encryption evolves over time, though. A complex encryption algorithm may seem unbreakable when it’s first introduced, but cracking tools and decryption methods will adapt. Over time the computational power available to the average user increases as well, rendering outdated encryption tools virtually useless.

The Roman emperor Julius Caesar is credited with coming up with the Caesar Cipher to encode military communications. The Caesar Cipher offsets the letters of the message by a set number. For example, the name “tony bradley” with an offset of 4 would end up being “pkju xnwzhau”. A message converted using the Caesar Cipher would appear to be gibberish. It’s not very secure, however, because the maximum offset would be 25 and it would only take a minute or two to run through every possible permutation of the Caesar Cipher to reveal the “encrypted” text.

Now we have significantly more complex encryption algorithms using 128-bit or 256-bit keys. A 256-bit encryption key is theoretically unbreakable—today. A post on Reddit works through the math of the processing power required and claims that it would take longer than the entire universe has existed up until now to brute-force all possible combinations of a 256-bit key. However, a few years ago researchers at Fujitsu were able to crack a 923-bit key in just under 150 days using a combined total of just 252 processor cores.

There are two other important considerations aside from the length of the key itself. First, many algorithms are poorly implemented. Key generation for encryption typically uses a pseudorandom number generator. The computer can’t actually be random so the pseudorandom number generator has to be initialized using some known or finite value. If an attacker can find the weakness in the PRNG used to generate the encryption key, the length of the key itself becomes somewhat irrelevant.

Second, theoretical exercises that calculate the amount of time it would take to brute force every possible solution for a 256-bit encryption key seem to assume that the correct encryption key will be the last one that is tried. It is equally possible that a cracking tool will get the encryption key right after a week, or a day, or even on the first try.

Check out  the complete post on the RSA Conference blog: Today’s ‘Unbreakable’ Encryption Is Tomorrow’s Security Weakness.

Share.

About Author

I have a passion for technology and gadgets--with a focus on Microsoft and security--and a desire to help others understand how technology can affect or improve their lives. I also love spending time with my wife, 7 kids, 3 dogs, 5 cats, 3 rabbits, 2 ferrets, pot-bellied pig and sulcata tortoise, and I like to think I enjoy reading and golf even though I never find time for either. You can contact me directly at tony@xpective.net. For more from me, you can follow me on Twitter, Facebook, Instagram and LinkedIn.

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.