6 ms·

> 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 l

> 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.

markonen 7y ago
Something like hardware offload comes to mind as potentially platform-specific.
- ikawe 7y ago
  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.
  - Nullabillity 7y ago
    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.
    - ikawe 7y 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.
      - Nullabillity 7y 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 https://github.com/apple/swift-crypto
olliej 7y ago
crypto kit is a core Mac and iOS library, as is coretls, etc.
- Nullabillity 7y ago
  Two wrongs don't make a right.
  - olliej 7y ago
    Neither Boring- nor OpenSSL make API guarantees, let alone ABI guarantees. That is a show stopper for a platform library. They also predate BoringSSL.
cerberusss 7y ago
Curiousness, not casual dismissal, is what's mentioned in the HN guidelines. But since you ask, they do mention some of the reasons: - Apple’s Secure Enclave processor - Able to test the implementations against each other
- Nullabillity 7y ago
  > - Apple’s Secure Enclave processor That's only referred to as something that is explicitly not supported. > - Able to test the implementations against each other Surely they could have done that anyway, since SC implements the CK API. Or they could have disabled the CK backend for all release builds.
  - simonh 7y ago
    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.
    - Nullabillity 7y ago
      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).
      - jayrhynas 7y ago
jws 7y ago
From most of the way down the page… 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.
- mzs 7y ago
  a great argument for better automated testing but not for rolling-out everywhere
- SahAssar 7y ago
  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.
- Rebelgecko 7y ago
  This seems weird to me. 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).
  - codyb 7y ago
    It seems like it’d be easy enough to test whether or not something was vulnerable to timing attacks. But maybe there’s other vulnerabilities to be considered too and hard to have a suite which reliably tests for them all.
why_only_15 7y ago
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.

markonen 7y ago

Something like hardware offload comes to mind as potentially platform-specific.

ikawe 7y ago
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.
- Nullabillity 7y ago
  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.
  - ikawe 7y 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.
    - Nullabillity 7y 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 https://github.com/apple/swift-crypto

olliej 7y ago

crypto kit is a core Mac and iOS library, as is coretls, etc.

Nullabillity 7y ago
Two wrongs don't make a right.
- olliej 7y ago
  Neither Boring- nor OpenSSL make API guarantees, let alone ABI guarantees. That is a show stopper for a platform library. They also predate BoringSSL.

cerberusss 7y ago

Curiousness, not casual dismissal, is what's mentioned in the HN guidelines. But since you ask, they do mention some of the reasons: - Apple’s Secure Enclave processor - Able to test the implementations against each other

Nullabillity 7y ago
> - Apple’s Secure Enclave processor That's only referred to as something that is explicitly not supported. > - Able to test the implementations against each other Surely they could have done that anyway, since SC implements the CK API. Or they could have disabled the CK backend for all release builds.
- simonh 7y ago
  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.
  - Nullabillity 7y ago
    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).
    - jayrhynas 7y ago

jws 7y ago

From most of the way down the page… 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.

mzs 7y ago
a great argument for better automated testing but not for rolling-out everywhere
SahAssar 7y ago
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.
Rebelgecko 7y ago
This seems weird to me. 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).
- codyb 7y ago
  It seems like it’d be easy enough to test whether or not something was vulnerable to timing attacks. But maybe there’s other vulnerabilities to be considered too and hard to have a suite which reliably tests for them all.

why_only_15 7y ago

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.