Why was BoringSSL chosen as the backend? According to Google,
> 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.
> 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.
How is the state of developing Swift application on Windows? Last I checked it was using Linux on Windows to compile Swift code.
With Linux and Windows support, Swift can become viable for cross platform development.
This, combined with Apple claiming that the Afterburner card for Mac Pro is a programmable ASIC, is pretty interesting news.
> 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...
The first example shows AES.GCM.seal(...) and then states:
> 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 will allow Swift developers, regardless of the platform on which they deploy their applications, to access these APIs for a common set of cryptographic operations.
How often is swift used on a non-Apple platform? Also why?
Oh great! I spent half an hour the other day figuring out how to do MD5 on Swift without CommonCrypto or Xcode.
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.
We are fast approaching Swift 6, and most of the Apps by Apple are still strictly Objective-C ( Not saying it is a bad thing ). Even the new Apply Pay App is Objective-C.
Where is Swift heading? If Apple isn't dogfooding it themselves.
So I wonder if in a future Swift for Windows, will Windows.Security.Cryptography be made use of, or only Apple gets special treatment.
I want something like this for python or C.
lol the word crypto is not a good choice unless you want to attract blockchain mob
Without knowing the .org, I thought this was going to be about SWIFT, https://www.swift.com , the electronic funds transfer service, working on some sort of blockchain or cryptocurrency related announcement.
This is one of the first fruits born of the three-fold Swift 6 initiative [0]: 1) Accelerate growth of the Swift software ecosystem (cross platform tooling and libraries) , 2) Create a fantastic development experience (build times and debugging), 3) Invest in user-empowering language directions (language APIs and memory ownership model, etc).
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