> On Apple platforms, Swift Crypto defers directly to CryptoKit, while on all other platforms it uses a brand-new implementation built on top of the BoringSSL library.
Oh great, more pointless differences. Just pick one and stick to it. If you trust the BoringSSL version then use it everywhere. If you don't, well, why are you using it on the other platforms?
I could understand it if it was very platform-specific (async networking, GUI controls, whatever). But come on, BSSL already exists everywhere, you're not saving yourself any porting work.
Given that we had do to this extra work, what advantage is gained from having two backends, instead of consolidating onto a single backend for both CryptoKit and Swift Crypto? The primary advantage is verification. With two independent implementations of the CryptoKit API, we are able to test the implementations against each other as well as their own test suites. This improves reliability and compatibility for both implementations, reducing the changes of regression and making it easy to identify errors by comparing the output of the two implementations.
Creating a working implementation of an algorithm like Chacha20 is really not that hard if you're comfortable with bit twiddling. It's much harder to create an implementation that works and doesn't have hidden problems, like being vulnerable to timing attacks. So they've made it slightly easier to do the easier part of crypto (get a correct result), while increasing their attack surface and the amount of effort that it takes to do the hard part of crypto (getting a result securely).
Wouldn't it be just as good to verify and test the ciphertext/hashes/signatures against other crypto libs in testing? It seems weird to include a dependency for some platforms just to "test the implementations".
Other crypto frontends don't include different backends just because "testing", if they do they do because they have platform specific reasons.
EDIT: it looks like my reading of this was incorrect. A careful reading of the source I think makes it clear SwiftCrypto avoids any use of the specialist hardware on Apple platform. My apologies for the confusion.
—— original (incorrect) comment
It does not say Secure Enclave is not supported, it says this:
“ a subset of the API is built around using Apple’s Secure Enclave processor to securely store and compute on keying material. Apple’s Secure Enclave processor is not available on non-Apple hardware: as a result, Swift Crypto does not provide these APIs.”
So if secure enclave is available it specifically _is_ used to implement some functionality, but this is implements in other ways on other platforms. However the APIs for secure enclave itself are not exposed in either implementation.
According to your quote, CK has some APIs that depend on the enclave, but SC does not support those APIs.
It says nothing about whether any other SC APIs use the enclave behind the scenes (but I doubt it, there's not much point in bothering with the enclave if the CPU has access to the key material).
I think the point he's trying to make is that the CK implementation of the APIs common to CK and SC may (or may not) make use of the secure enclave, and that's one reason to have different implementations.
A specific example would be secure enclave support.
FTA:
> However, alongside these simple ideas are a number of very complex implementation concerns. The first of these is about hardware. While much of Apple CryptoKit is a straightforward implementation of well-known cryptographic primitives, a subset of the API is built around using Apple’s Secure Enclave processor to securely store and compute on keying material. Apple’s Secure Enclave processor is not available on non-Apple hardware: as a result, Swift Crypto does not provide these APIs.
As your quote says, those APIs aren't available in SC anyway, so that's irrelevant.
The next paragraph is also interesting, though, since it is an argument against depending on system libraries:
> The second covers the software distribution model. In order to make it easier for developers to update Swift Crypto when they are using it on non-Apple platforms, we took advantage of the Swift Package Manager to distribute Swift Crypto. This allows users to pull in security fixes and API updates via simple swift package update.
They aren’t “available” as in they aren’t exposed in the interface.
But they are used by Swift Crypto when using a CryptoKit backed instance of Swift Crypto. They are not used when using the boringSSL backed Swift Crypto.
Where is that claimed? There are two paragraphs on the blog that mention secure enclaves or special hardware: your quote, and the following:
> With the exception of APIs requiring specialised hardware, it will always be the case that where an Apple CryptoKit implementation of an API is available, Swift Crypto will use it, but when such an API is not available it will be possible to use the Swift Crypto-based implementation. The core APIs will move in step with Apple CryptoKit, and our test suite is shared with Apple CryptoKit ensuring that both projects must pass each other’s test suites for the API, ensuring that both Swift Crypto and Apple CryptoKit will be completely compatible.
The SC README[0] contains one more mention of it, with the same general idea:
> SwiftCrypto exposes the portions of the CryptoKit API that do not rely on specialised hardware to any Swift application. It provides safe APIs that abstract over the complexity of many cryptographic primitives that need to be used in modern applications. These APIs encourage safe usages of the underlying primitives, follow cryptographic best practices, and should be the first choice for building applications that need to use cryptography.
You save on code size on disk by doing this because you can defer to the already existing dylib. This doesn't work for BoringSSL because I believe all the copies are vendored and the system doesn't share a single copy.
Oh great, more pointless differences. Just pick one and stick to it. If you trust the BoringSSL version then use it everywhere. If you don't, well, why are you using it on the other platforms?
I could understand it if it was very platform-specific (async networking, GUI controls, whatever). But come on, BSSL already exists everywhere, you're not saving yourself any porting work.