This may be just a "nit", but isn't that 1 billion billion years the time required to evaluate ALL possible keys?

I guess what I'm pointing out is a slight flaw in the calculation/logic that seems to assume a brute force attack must calculate all possible outcomes prior to determining which was the correct one. Granted, It would still come out to about half a billion billion years (on average), which is still essentially "unbreakable"...

@Sparky: You have the Symmetric and Asymmetric (Public Key) parts switched. The Public Key algorithms are used to perform the authentication and key handshake, and then the symmetric algorithms such as AES or 3DES are used to encrypt the conversation. The author was only disussing the cracking of AES here, and with a brute force approach there would be no need to attack the Public Key handshake (although of course that's another attack vector that could be used!) Regardless, your concluding point at the end is valid regarding the cracker's need to know something about what properly decoded plaintext "should" look like. But in almost all cases, that is quite reasonable since the wrong decryption key yields statistically random jibberish and the correct key yields something that stands out as being non-random (regardless of what the payload actually is). Sure, the paranoid can obscure their plaintext in a really good way by performing another encryption layer, but then of course your workload has doubled to protect the traffic!

You are right. Allow me to add a couple of things: Please try to learn from history. Enigma had about 2^76 possibilities. Much more than single DES (!). In a way as users we are always behind: All we use can be broken, exept for 1 method...

Now you might think: "Yes, but Enigma had vulnerabilities", that's right. But each crypto system is designed by humans, so each crypto system is weak in a certain way. While trying to crack systems you have to think equally: Think as a software design engineer. So, let me suggest that by choosing large keys, they are often formed by primes. Well, with a -for example- 128 bit key, let us first test THE LARGEST PRIMES and I will ensure you that you will find the key faster than you think. This is what the 'capable bodies' would do (and probably will do). My thoughts are that this is the way you have to think while working with crypto. So -at least- use a 1024 bit key or even larger. The rest smaller than this already has been lost, it is not safe anymore.

Another annoying thing that most people forget is the following: Key exchange is one thing, but data exchange is another. Most people fuzz about key exchange and how safe this must be. Most fantastic procedures are designed for that. But then... , to be followed by a laughable data exchange format to be cracked by seconds (with some statistics only). Then you don't even *need* the key. Please consider this as well.

The best way to encipher data is with the Vernam principle. Only problem is that your key has to be as large as your message, and you have to distribute your key in a safe way. During the cold war the Washington-Moscow hotline worked with this principle. It contained the Siemens M190 mixer machine with a couple of TELEX machines. Look at the cryptomuseum dot com webpages and search for M190. This website will be an eye-opener for you and it is also good to learn about the history. Vernam is the way to go, anywaym have fun !

The cryptographic algorithms used in Advanced Encryption Standards are more secure due to 128-bit symmetric keys, if someone sets a password containing both letters and symbols it is very hard for any hacker to find out the code. I use a 128 bit key size password on our workflow management systems and I am sure no one will break it, for a better security I use a random password generator that maximizes the security of the password.

It is correct that there are ways to reduce the keyspace you need to search - and that future research may reduce this a little more. And it may turn out that in the future, there will be a breakthrough that reduces the search keyspace significantly - but there is no indication of that at the moment.
So even with 128-bit AES, the cheapest and most reliable way to break the key is to use one of the two traditional methods - the three B's technique (bribery, burglary, blackmail) or rubber hose cryptoanalysis. And it looks likely to remain that way for a long time yet.

I made a mistake in my calculations - the theoretical minimum switching energy is kT.ln(2). So it would only take 200000 years to power the calculations!

The energy argument is a good point. There are theoretical limits to information storage density, and to the minimum amount of energy for calculations.
As far as I know, the theoretical minimum energy for switching one line is kT, where k is the Boltzmann constant and T is the temperature (in K). That's 4e-21 J at room temperature. If we assume that testing an n-bit key takes 1000n switches (an absurdly low estimate), then it takes 5e-16 J per test, and thus 1.75e23 J total to do a brute-force crack of a 128-bit key.
The earth's current energy consumption is about 150 PWh per year, or 5.4e17 J per year.
That means it would take 300000 years to power the calculation to break the 128-bit key, assuming the same power generation of the earth, assuming absolute theoretical minimal switching energies, and assuming ridiculously small numbers of switches per test.
Call me naive, but I don't think the NSA has a secret AES-128 cracking lab...

What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.

To save this item to your list of favorite EE Times content so you can find it later in your Profile page, click the "Save It" button next to the item.

If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.