Why is crypto so slow? What factors are behind such cautious development?
Why is crypto so slow? What factors are behind such cautious development?
While the world of security races ahead, rolling out new developments and products on a monthly basis, its foundational discipline, cryptography, is comparatively slothful. Why?

Tech moves fast. The last few years have proven that. It wasn't too long ago that we were lugging around the pale bricks we used to call iPods. Now, the newest iteration of that technology comes with facial recognition. 

Security moves at a similar pace. And because of the generally poor quality of password selection, we've seen the rapid adoption of biometric solutions that collect highly personal information. Innovation surges forward.

However cryptography - the field which holds it all up - runs at a decidedly slower pace, marking its breakthroughs in years, not quarters. With something so inherently important, why would it be so slow to evolve? 

When we talk about security, we are often talking about the fast-moving security industry. We talk about fast moving endpoint protection or firewalls. Less of that conversation has to do with the halls of academia, where much of cryptography lives.

As an academic field, crypto agonises over specificity. Its practitioners are far more cautious than their more sales-oriented cousins. As a result, they spend a lot of time trying to get things right and less time worrying about quarterly sales. 

For those of us in this field, that caution is bred from experience. Crypto history is littered with mistakes and cryptographers are not eager to repeat them.
 
But that sloth doesn't just come from one side. The industry has its own hang-ups about change. Broadly speaking, they're more likely to go with the things that they know work and that have kept them relatively safe for years. 

My colleagues and I in this industry want simplicity. The industry wants TLS libraries that work and keep them safe, it wants the agility to move between different mathematical algorithms when needed and it wants to be able to hold onto its time tested, proven and prized cryptosystems. This too, can thwart the forward movement of cryptography.  

Sometimes cryptography actually overshoots the technological capabilities of the day. When Whitfield Diffie and Martin Hellman published the Diffie Hellman (DH) cryptosystem in 1976, computational power could not match up with the promise of their work. And it didn't catch up for a long time.

The latest iteration of the DH algorithm involves slightly newer math based on Eliiptic curves. ECDH is only just now becoming popular, largely because of Perfect Forward Secrecy (PFS). And only a few decades late. 

In 2013, 44 percent of websites did not support PFS. Now, that number is just below seven percent, according to Qualys' SSL Pulse measurements. 

RSA Keys, like all asymmetric cryptosystems, rely upon a pair of private and public encryption keys. The RSA cipher scheme has one relatively major problem. 

The privacy of a conversation is entirely dependent on the security of the private RSA keys. Should one of those private keys leak, anyone with knowledge of them could listen to conversations or decrypt old conversations. It also opens up the possibility of a Man in the Middle attack, whereby an attacker pretends to be one of its legitimate participants.

PFS circumvents that problem altogether by generating unique keys for each conversation. If attackers get their hands on a private key, they will only be able to impersonate the server but not decrypt any old or new conversations, thus preserving the privacy of future interactions. 

The tech industry has been catching on. Google has provided PFS with Transport Layer Security since late 2011 as has Twitter since 2013, and the Wikimedia Foundation since 2014.  The most significant adoption of late is Apple's. On January 1st, 2017 the App store began making its apps use PFS. 

But perhaps the most profound adoption of PFS will come in the form of TLS 1.3. In 2014, the group working on TLS 1.3, decided to abandon RSA altogether. Citing shaken confidence in the cryptosystem, they decided that it would only allow protocols that supported PFS. This development could send RSA keys on their way out the door, at least where TLS is concerned. 

That change will not be immediate. System administrators and IT operations teams will want to hang on to their prized RSA keys for a while, especially internal to the data center. In the short term, PFS may be used to secure external interactions while internal network operations will be overseen by more traditional cryptosystems. Give it a couple of years though, and people will start to feel Crypto quickly catching up with them. They will likely want to move to newer cryptosystems.

Contributed by Jeff Costlow, director of security, ExtraHop.
 
*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.