undefined | Better HN

0 pointsikawe6y ago0 comments

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.

0 comments

3 comments · 1 top-level

Nullabillity6y ago· 2 in thread

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.

ikaweOP6y ago

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.

Nullabillity6y ago

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.

[0]: https://github.com/apple/swift-crypto

j / k navigate · click thread line to collapse