
Swift Crypto - johns
https://swift.org/blog/crypto/
======
oflannabhra
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](https://forums.swift.org/t/on-the-road-to-swift-6/32862)

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

[https://boringssl.googlesource.com/boringssl/](https://boringssl.googlesource.com/boringssl/)

~~~
woadwarrior01
Which is why, they're vendoring a copy of BoringSSL. The readme on their git
repo[1] clearly states this.

[1]: [https://github.com/apple/swift-crypto](https://github.com/apple/swift-
crypto)

~~~
protanopia
That allows them to avoid the problem, but why introduce the problem in the
first place? Why not use something that is intended to be used as a crypto
library?

~~~
woadwarrior01
They had an existing API to comply with[1]. NaCl's API doesn't cover
everything they need. Their choices were down to 1. Use OpenSSL (or a fork of
it, which BoringSSL is) 2. Roll their own crypto. They chose #1 on all other
platforms and stayed with #2 on the platforms they control (I might be
mistaken here, perhaps they wrap some OpenSSL derivative on their own
platforms too). And that in my opinion is a reasonable choice, given the
constraints.

[1]:
[https://developer.apple.com/documentation/cryptokit](https://developer.apple.com/documentation/cryptokit)

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

~~~
jws
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._

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

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

~~~
ken
From what I’ve seen, Windows APIs are in C++, and Swift doesn’t really offer
any C++ interop. You’d have to wrap everything in C functions first.

Plus, Windows isn’t an officially supported platform for the Swift compiler.

I wouldn’t hold my breath.

~~~
rrdharan
Most core Windows APIs are C APIs, the only stuff that requires C++ AFAIK are
things like ATL and MFC which are just (very thick) wrappers..

~~~
lenkite
This ignores all the new UWP API's which are the basis for modern Windows
applications and will work on all future versions of windows. C++ is the
preferred language here:

[https://docs.microsoft.com/en-us/windows/uwp/cpp-and-
winrt-a...](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-
apis/intro-to-using-cpp-with-winrt)

------
pazimzadeh
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...](https://www.apple.com/newsroom/2019/06/apple-unveils-powerful-
> all-new-mac-pro-and-groundbreaking-pro-display-xdr/)

~~~
AceJohnny2
Afterburner isn't user-programmable.

They use it for accelerating their codecs only.

~~~
danpalmer
I believe there’s an SDK for it. It may not be publicly available (yet?), but
third party codecs are going to be able to take advantage of it.

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.

~~~
ken
Apple has never mentioned any SDK for programming the FPGA, AFAIK. Source?

~~~
yoz-y
Craig Federighi mentioned in one interview (with Gruber I think) that the card
can be reprogrammed. IIRC there were hints that they could be user
programmable in the future, but of course nothing was neither confirmed nor
denied.

~~~
ksec
I think this is missing in context. ( To me at least ). The card can be
reprogrammed by _Apple_. And Apple could offer additional functions or
features with it. I take that as something similar to current Afterburner
function as in H.265 / 266 Video Encode or Decoding.

------
cakoose
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](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.)

~~~
CiPHPerCoder
This gives you a collision after 2^48 messages (via the birthday problem).
Each message can be up to 2^36 - 256 bytes long.

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...](https://libsodium.gitbook.io/doc/secret-
key_cryptography/aead)

~~~
TylerE
2^48 is an absurdly large number.

That's enough that you can generate 1000 messages a second for several
millenia.

~~~
cakoose
Yeah, 2^48 is huge, but that gets you a collision probability of ~40%.

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.

------
duckqlz
>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?

~~~
xkemp
There's some momentum for Swift on servers. It has at least the potential for
C-like performance, although the last time I tried it wasn't quite there yet.
Might also be useful for having a second stack that works on the client as
well as the server.

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.

~~~
Smoosh
An example for zOS as a server:
[https://www.kitura.io/](https://www.kitura.io/)

~~~
ChrisMarshallNY
Kimura is cool, but not sure what its future is:
[https://www.theregister.co.uk/2019/12/17/swift_ibm_pulls_bac...](https://www.theregister.co.uk/2019/12/17/swift_ibm_pulls_back_open_source_priorities/)

~~~
ChrisMarshallNY
Whoops. Autocorrect typo. "Kitura." (I have "Kimura" in my dictionary).

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

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

~~~
favorited
More apps have been adopting Swift with each OS release. On iOS specifically,
the number of system binaries using Swift more than doubled between iOS 12 and
iOS 13.

[https://www.cultofmac.com/655444/swift-code-usage-
ios-13/](https://www.cultofmac.com/655444/swift-code-usage-ios-13/)

------
pjmlp
So I wonder if in a future Swift for Windows, will
Windows.Security.Cryptography be made use of, or only Apple gets special
treatment.

~~~
favorited
Since the goal is to reimplement CryptoKit.framework, I'd guess that whoever
works on the Windows port (probably Saleem, let's be honest) would have to
decide the right course of action.

------
brian_herman
I want something like this for python or C.

~~~
riquito
Cryptography is the goto libary for Python crypto

[https://cryptography.io/](https://cryptography.io/)

------
iod
Without knowing the .org, I thought this was going to be about SWIFT,
[https://www.swift.com](https://www.swift.com) , the electronic funds transfer
service, working on some sort of blockchain or cryptocurrency related
announcement.

