Brute force encryption keys base on their length

I need to clarify if my understanding is correct.

if I am using 4.2 GHz CPU -one core only- that means:

4.2 billions hertz = 4.2 billion operations per second. (about 2^32)

So:

32 bit key : 2^32 \ 2^32 = 1 second

64 bit Key : 2^64 \ 2^32 = 2^32 = 4294967296 seconds = 136 Years

My Questions:

1) Is my way of calculation is correct?

2) In Assembly language : is one line = 1 operation?

Your calculation gives the correct order of magnitude but is not correct. Different assembly operations take a different number of clock ticks/cycles. Also note memory access can be expensive, and it makes a big difference which cache layer if any you hit. To make matters worse there is a difference between an instructions throughput and latency because several instructions can happen simultaneously. If you really want to do micro optimizations yourself you can look up instruction cost here: http://www.agner.org/optimize/instruction_tables.pdf

For cryptographic operations we usually already have highly optimized code and we can just look up the cost in cycles of various cryptographic primitives. For instance SHA-3 is very efficient and can be implemented with a throughput of ~8 cycles/byte on modern processor.

Just in general you expect single cryptographic function invocations to take on the order of a few hundred cycles in efficient implementations.

In order to make brute-forcing low entropy passwords difficult we usually use tuneable Key Derivation Functions which can be made arbitrarily slow.

• Although serious bruteforce attacks don't use one core, or CPUs at all; they use highly parallel hardware such as GPU, FPGA, or ASIC. Even as far back as EFF's DES cracker in 1998, which did 2^56 in a few days (and I'm not sure why they didn't use complementarity to halve it). Apr 3 '18 at 1:20
• The question specifically stated single core cpu. Apr 3 '18 at 4:22