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).
Other crypto frontends don't include different backends just because "testing", if they do they do because they have platform specific reasons.
But since you ask, they do mention some of the reasons: - Apple’s Secure Enclave processor - Able to test the implementations against each other
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.
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.
> The new Mac Pro debuts Afterburner, featuring a programmable ASIC capable of decoding up to 6.3 billion pixels per second https://www.apple.com/newsroom/2019/06/apple-unveils-powerfu...
> Afterburner is a hardware accelerator card built with an FPGA, or programmable ASIC. With over a million logic cells, it can process up to 6.3 billion pixels per second. [0]
They use it for accelerating their codecs only.
From what I understand (like a graphics card) the user defined software is loaded on at runtime (like a shader). Theoretically any software like this could be loaded.
With Linux and Windows support, Swift can become viable for cross platform development.
Plus, Windows isn’t an officially supported platform for the Swift compiler.
I wouldn’t hold my breath.
Any COM aware language should be able to call them without any issue.
Naturally the first issue is to treat Windows as tier 1 OS to start with.
How often is swift used on a non-Apple platform? Also why?
Then, there's a big push for Swift+Tensorflow and other ML. The hope here appears to be the ability to implement "automatic differentiation" (or was it "integration"?). I don't remember enough math to fully understand, let alone try to explain that. But I can attest that even without being implemented, it has the power to get ML people salivating.
> Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
> Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
Sounds like its just a strong warning that they'll change their APIs when they want (in the name of security). Not that it isn't production ready.
> This code avoids some of the numerous pitfalls that you can encounter when constructing encryption schemes yourself. For example, it ensures that you use a randomly selected nonce, and that you authenticate your ciphertext.
The AES-GCM nonce is only 96 bits, which might be enough in many contexts, but is still a little short for comfort when selecting nonces randomly: https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html
It's surprising that the blog post just declared success without bringing this up at all.
(It looks like AES.GCM.seal does let you specify the nonce, though, in cases where you can maintain a counter yourself.)
This is less of a problem when each message also generates a random key, but still annoying to contend with.
XChaCha20-Poly1305 lets you generate 2^96 messages before having to worry about rekeying. https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...
That's enough that you can generate 1000 messages a second for several millenia.
Where is Swift heading? If Apple isn't dogfooding it themselves.
This hits almost all of those, and while it isn't the highest priority for lots of Swift users today, Swift Crypto will hopefully create a way for there to be lots of future users of Swift on other platforms. I'm really happy that the Core Team seems to have really taken those 3 efforts seriously.
[0] - https://forums.swift.org/t/on-the-road-to-swift-6/32862
The best answer was perfect swift libraries, which linked to OpenSSL but damn it was hard to figure out.
It is still too painful to write Swift outside of the blessed Apple world. This is a step, but still a long way to go.
