Switching to Conscrypt as the default security provider
- Mentors
- Michael Hoisie, Julia Sullivan
- Organization
- Robolectric
- Technologies
- c, android, java, c++, jvm
- Topics
- java, android, Unit test, Conscrypt
Switching to Conscrypt, simulating the security APIs becomes much more high-fidelity and it achieves the goal of Robolectric to make it similar to an Android environment.
Currently, Robolectric uses BouncyCastle as the Java Cryptography Extension (JCE) security provider. Starting in Android P, Android switched to using Google Conscrypt as the security provider. To be more consistent with Android, Robolectric should update the default security provider to Conscrypt.
As it is using the BouncyCastle, this means that whenever the JCA APIs are used in a Robolecetric test, BouncyCastle will be used by default. Officially, In Android the default JCE provider is Conscrypt. This is a Java wrapper over BoringSSL. The goal is to have Robolectric switch from BouncyCastle by default to Conscrypt.
The Conscrypt module uses BoringSSL, a native library that is a Google fork of OpenSSL and which is used in many Google products like Google Chrome for cryptography and TLS.
Conscrypt uses Java code and a native library to provide the Android TLS implementation as well as a large portion of Android cryptographic functionality such as key generators, ciphers, and message digests. Conscrypt is relatively selective and focuses on the most important and widely-used algorithms.
Conscrypt also supports the curves in Elliptic Curves crypto operations and it is much faster than BouncyCastle as it is optimized native code. But BoringSSL doesn't have official releases and makes no guarantees around API or ABI stability.