Accelerating H.264 & DTLS certificate generation
Chrome 52 beta channel release notes were published covering over 30 bug fixes, enhancements to the support for H.264 in Chrome and changes to default DTLS certificate generation algorithm for more privacy and better performance. This version is expected to hit your browser (Stable channel) on July 26.
The support for WebRTC H.264 in browsers is required by the IETF and is important for browser interoperability (assuming not all browsers will support both H.264 and VP8 in the short term) and interoperability with legacy video systems.
WebRTC H.264 enhancements in Chrome
Support for H.264 in Chrome was first introduced by Google in Chrome 50 but back then it came with some restrictions, some of which are being fixed in Chrome 52 H.264 implementation.
Following are the enhancements:
H.264 is now supported in Chrome for all desktop platforms.
Hardware accelerated encoding has been enabled for OS X (renamed MacOS). As mentioned before, hardware acceleration is very important for performance and battery life considerations (not only mobile, also laptops and high capacity servers).
On Windows Chrome is still using a SW codec for H.264 encoding and this codec will be optimized in future releases.
ECDSA in WebRTC: More security and faster performance
Another feature added in Chrome 52 is the default usage of ECDSA in WebRTC (Elliptic Curve Digital Signature Algorithm) replacing the currently used 1024-bit RSA keys for generating the self-sign certificate used in the DTLS handshake.
There were 2 reasons for making this change:
- Cryptographic strength
The previous algorithm (1024-bit RSA) takes about 1 second to process. Call setup time is an issue in VoIP in general due to ICE process and this is just another delay added. The new algorithm used (ECDSA) is fast, how fast? By the thousands faster.
1024 bit RSA is just not enough today. Hacking the RSA key requires factorization of large integer numbers. This is getting easier to do as processing power gets better and efficient algorithms are developed.
I’m not a cryptography expert but in short the Elliptic Curve Cryptography (ECC) gives you the same level of security for a much smaller public key. Chrome 52 is now using a 256-bit ECC public key, it provides a similar level of security as a 3072-bit RSA public key but since ECC is much faster it avoids the seconds of call setup delay.
Mind the interoperability gap
The switching to ECDSA as the default algorithm in Chrome may cause interoperability issues with existing systems that don’t support it (e.g. WebRTC GWs). Although Google doesn’t say RSA is being factored out of Chrome it might happen sometime down the road as will probably eventually be done with SDES. In a post on WebRTCStandards we mentioned the fact that ECDSA is now mandatory to implement in WebRTC and therefore the change Google has done in Chrome 52 makes a lot of sense.
There is more to Chrome 52 so head over to the release notes and see the details.