Swift Crypto
swift.org
swift.org
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
> 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.
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.
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 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.
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.
> 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.
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.
—— 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.
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).
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.
Other crypto frontends don't include different backends just because "testing", if they do they do because they have platform specific reasons.
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).
But maybe there’s other vulnerabilities to be considered too and hard to have a suite which reliably tests for them all.
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.
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a...
Since Vista, the plan has been doing in COM what was thought out for Longhorn with .NET.
As such, all new APIs introduced since Vista are mostly COM libraries, and now UWP, which is an improved version of COM, after its hard rebirth with WinRT and UA.
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.
> 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...
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.
Sadly. I was waiting for it too.
https://support.apple.com/en-us/HT210748
It's not really surprising. Developing a macOS SDK for letting developers load their whatever on a PCIe-mounted FPGA is a huge undertaking, only done by those manufacturers of FPGAs (and not for macOS). There really isn't any market justification to build that for what's effectively a glamour product.
> 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]
> 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.
You'd want a probability more like 1-in-a-million (or 1-in-a-billion). That's 2^39 (or 2^34), which is 1000 messages a second for 17 years (or 7 months).
Again, probably still safe for many use cases. But you do have to think about it for a second. XChaCha20's 192-bit nonce capacity lets you totally ignore that factor, which is a nice property for generic crypto recommendations.
Generally speaking leaking that two plaintexts are the same is better than leaking two plaintexts XORed together. If you’re in a use case where that’s liable to happen (i.e., you don’t rekey “frequently”) I’d happily take the former leaked bit over the latter leaked messages.
There are also a handful of existing constructions you can just take off the shelf rather than rolling your own thing and getting it wrong.
With AES-GCM, if you reuse a nonce with two different plaintexts, you reveal the XOR of the two plaintexts!
How often is swift used on a non-Apple platform? Also why?
Though the way all of those work is substantially different. Swift doesn't monomorphize generics like Rust does[0], for example.
Swift doesn't have a concurrency story yet, so it is possible to have data races if you share data between threads. An ownership system[1] is in the works, but it is not complete yet.
[0]https://www.reddit.com/r/rust/comments/7gkiie/implementing_s... [1]https://github.com/apple/swift/blob/master/docs/OwnershipMan...
Protocols are fairly close to traits, and I much prefer that approach (and Scala's traits), to traditional OOP.
Swift can monomorphize generics, but it doesn't do so by default. Normally this is left up to the compiler, but it's possible to force monomorphization using inlining attributes.
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.
https://www.infoq.com/news/2020/01/ibm-stop-work-swift-serve...
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.
Where is Swift heading? If Apple isn't dogfooding it themselves.