News and updates

Crypto Security - How many bits?

Very recently we have seen some progress in the cryptanalysis of Elliptic curves. This Austrian group have reportedly broken an elliptic curve at the 113-bit level of security, using 10 FPGAs.

Before proceeding lets put a number against "security level". Consider the Advanced Encryption Standard (AES) with a 128-bit random key. Lets call this AES-128. Now for elliptic curves we need twice as many bits for the same level of security. So a 256-bit curve is roughly comparable with AES-128.

Now that a 113-bit curve has been broken, we can easily project that it would be at least 18,446,744,073,709,551,616 times more difficult to break a 256-bit curve using the same record breaking methods. To describe this margin of safety as "generous" hardly does it justice.

So whatever problems we have designing secure systems, the mathematical crypto is not the problem. Of course one might surmise that an all-powerful "they" have more powerful computers, better mathematicians. That can maybe overcome even this margin of safety? However the Snowden revelations have briefly allowed us a glimpse of what they actually do - and they don't even try to break the crypto. They attack the implementation, they install computer viruses, they suborn manufactures to include back-doors etc. In these contexts, whatever margin of safety there is, is typically much smaller (like maybe "6"?) and hence much easier to overcome.

However there are always the siren voices that say, why not use AES-256, and at little or no cost and double the number of digits in that cryptographic margin of safety? And indeed most crypto algorithms can be jacked up to a much higher level of security at surprising little cost.

But what is the point? There is no problem out there for which this is a solution! And in practise there is a cost. A higher level of security - all other things being equal - does require more computing resources. So by suggesting such a strategy certain platforms which might have benefited from cryptographic protection, become non viable. And by encouraging such a course of action, those voices groundlessly undermine confidence in Elliptic Curve Cryptography.

So lets stick with AES-128/ECC-256 and concentrate instead on getting the other aspects of secure system design properly worked out.

Read more about our MIRACL research and innovations in our MIRACL labs.