Why WebCrypto Encryption Matters: Apple’s Argument for Ditching Older Methods

2 minute read
| Analysis

In a recent WebKit blog post, Apple made a compelling argument for adopting some new coding standards for encryption. The technology behind those web pages we love to use is ever-evolving, but sometimes the trick is convincing developers to learn new ways of doing things. Let’s look at the argument Apple makes for adopting WebCrypto encryption, in easier-to-understand language.

webcrypto encryption

There are many ways to lock up websites, but some are definitely better than others (Image Credit: meineresterampe)

What Is WebKit and WebCrypto Encryption?

WebKit, in short, is a mechanism for showing you those web pages you love in your browser. It powers Apple’s Safari web browser as well as Chromium-based browsers like Google Chrome and Opera.

Apple created the WebCrypto API to bring cryptography, the cornerstone of information security, native to the web browser. Cryptography is what’s behind those secure websites you visit, like the checkouts for shopping sites and your bank’s website. Previously, developers have used several very successful JavaScript cryptography libraries to allow cryptography on the web.

Why Should We Change If the JavaScript Libraries Are so Successful?

The post dives into quite a bit of highly technical programming mumbo-jumbo, but the gist of it is this: WebCrypto encryption and the new SubtleCrypto method are more secure and operate faster than competing third-party JavaScript libraries.

Performance Increases Using WebCrypto

See the table below, demonstrating WebCrypto’s performance in AES-GCM encryption and decryption. The table also showcases how quickly SHA–2 can determine a file’s overall integrity the file is encrypted or decrypted.

webcrypto encryption speeds

This table demonstrates how much faster WebCrypto encryption and decryption is compared to other methods (Image Credit: WebKit)

You can see that the table says higher numbers are better. Let me elaborate. WebCrypto encryption is able to encrypt a file at a speed of 1.33GB per second. By way of comparison, the fastest JavaScript library can only do so at around 12MB per second. That’s a huge performance increase, and the results are similar for both decryption and the SHA–2 digest integrity check.

The Problem With JavaScript’s Security

In addition, the post points out that WebCrypto encryption is functionally more secure. In non-native JavaScript libraries, secret or private keys have to be stored within the “execution context” of JavaScript. This means JavaScript stores them in the executable or resource scripts or files used by the library.

This lends itself to an extreme vulnerability, because those JavaScript resources are exposed at runtime and could be attacked – the keys can be stolen by skillful hackers. We call this an XSS, or cross-site scripting attack. Such an attack happens when hackers inject malicious scripts into web sites we trust, usually through our computers.

This typically happens because a Trojan or other malware on the user’s computer injects the malicious code. I believe we may have seen examples of this with LastPass and LinkedIn, although those sites haven’t disclosed precisely how they were breached.

WebCrypto API: A More Secure Model

WebCrypto stores the keys outside of the JavaScript “execution context.” This limits the chance of a malicious person stealing the private key through an XSS attack. In other words, a hacker can’t execute malicious JavaScript in your browser to steal a secure web site’s private keys.

The fact that security and performance are better across the board with WebCrypto API should be enough to encourage developers to migrate their secure web apps. So, why haven’t more secure websites implemented the WebCrypto API?

These Things Take Time

Developing a secure interface for a transport medium (like the web) that is so inherently insecure takes loads of time and resources. Once they’ve completed the job, companies are reluctant to devote the time, energy, and money to do it over again.

Apple’s latest argument, in the form of the blog post we’ve been discussing, should help speed things up. It explains in readily understandable language (if you’re a developer) why the WebCrypto API is superior to non-native JavaScript libraries. I fully believe some companies are already in the lengthy process of adopting these changes, and others are sure to follow suit after Apple’s compelling argument.

4 Comments Add a comment

  1. geoduck

    We call this an XSS, or cross-site scripting attack. Such an attack happens when hackers inject malicious scripts into web sites we trust, usually through our computers.

    Glad you mentioned this. Just a week or so ago we were having a discussion of the need for a good Anti-malware on the Mac. Someone said it wasn’t necessary as long as you didn’t download software outside of the MacAppStore and “Avoid sketchy sites”. Well, you can get hit from any site, and this is how. About once every couple of months I get a warning, either from Safari or Avast about a page on GoComics. Never the same one. It never is there the next day, Just occasionally the page I hit every day is a carrier.

  2. dizzy1618

    Google forked Webkit into Blink a few years ago, so your opening paragraph there is slightly inaccurate 🙂

  3. Jeff Butts

    @dizzy1618 Actually, not at all inaccurate, despite what you may have read on Wikipedia. Apple owns all rights to WebKit at this point and is behind much of its active development. Look at WebKit.org, the official web page for the project. At the bottom, you’ll see:

    WebKit and the WebKit logo are trademarks of Apple Inc.

    My opening paragraph doesn’t say that Apple invented WebKit, just that Apple is behind it now and is making a compelling argument for adopting the WebCrypto encryption.

Add a Comment

Log in to comment (TMO, Twitter, Facebook) or Register for a TMO Account