
CommonCrypto in Swift - astigsen
https://realm.io/news/danny-keogan-swift-cryptography/
======
adrtessier
Ack. If you need bindings in iOS, just use libsodium?

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/](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.

~~~
tptacek
You're not wrong, and Common Crypto is indeed a minefield that pretty much
everyone should avoid.

