CommonCrypto in Swift

As far as I am concerned, everything about this is a little scary. Some guy like tptacek will come in here and school me (please do, senpai), but even a crypto novice* like me can see there are a thousand ways an API this low-level can go wrong. Some off the top of my head:

1. ECB mode might as well not be implemented. It sucks in a thousand ways, only one of which is the one displayed in the talk. ECB is half of the time the first crypto mode a novice implements (IV? What's an IV?) and using it over the wire is an instant replay attack vulnerability.

2. There is no sane default to AEAD of any sort, and modes like GCM do not even appear to be supported, per this talk. CBC is malleable [1]. Both BEAST and POODLE attacks were on TLS CBC.

3. DES? Seriously? Can we not deprecate this in new libraries, or at least make it a forced add-on to the library vs. an easy to choose built in?

Way too much is left to the developer, all of which are easy ways to shoot one's own foot. I hope you get your KDF right. I hope you get your cipher mode right. I hope you generate IVs from a proper, cryptographically secure random source and don't reuse them.

Low level crypto libraries like this are danger and death, and what someone with half the ability to implement a Swift-only library like libsodium should roll in here real fast, and save the Swift community from this mess before people start mucking around with all of these primitives in their production code. It's only a matter of time if this gets a lot of airtime without an easier solution. Instead, we'll probably end up with a few "secret messengers" that use "industry-standard Apple CommonCrypto library" and a string of primitive names.

These things are effectively an insecure default to publish these as the standard library. Wrappers on this stuff should probably be the default and the best practice from those writing language standard libraries should probably develop those the moment they have primitives available. To use a non-crypto analogy, think of using SimpleHTTPServer instead of socket in Python. We should have SimpleCrypto, with sane, secure defaults and standard primitives. It's a damn shame only a few people are pretty much qualified to audit and write this type of thing these days.

[1] http://cryptopals.com/sets/2/challenges/16/

* The entirety of my cryptographic knowledge comes from Katz, Schneier, reading a bunch of IACR papers, watching the Crypto conferences, and doing all the crypto challenges I can find online to solve. I believe that I know enough to be dangerous, and that is enough to know I wouldn't fucking touch this in a production app.