@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...

According to current research on cryptoanalisys strenght of AES-256 is comparable with bruteforce key size about 220-bits. So there is no sense to use pure bruteforce. Of course 2^220 is still very big number, but future technics may still lower number. Beside of that, there are additional tricks that could be used against particular AES implementation (in hardware or software), that may lead to recovering the value of the key. This is the most current problem.

A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...

Leonard Nimoy, We'll Miss you Martin Rowe5 comments Like many of you, I was saddened to hear the news of Leonard Nimoy's death. His Star Trek character Mr. Spock was an inspiration to many of us who entered technical fields.

Making the Grade in Industrial Design Rich Quinnell16 comments As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

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.