I know a thing or two about Objective-C. It’s not bragging. If you’re reading my blog, there’s a decent chance that I know more about Objective-C than you do. I have opinions about it. You should take them seriously even if you disagree. They’re founded on shipping a lot of code. I’ve shipped Cocoa software solo and in big teams, OS X and iOS, year-long release cycles and 30 hours to build a demo for Steve Jobs. I’ve been writing ObjC since 10.4 was the new hotness, before ARC, before properties, before Intel. There are many developers with much more experience, but even so, I know a thing or two about Objective-C.

I have no idea how to write Swift.

Neither does anyone else.

Not even Apple.

Ever since Swift came out, I keep seeing weird comments that Swift is a functional programming language. I’ve puzzled a bit over why anyone would say that, since there’s really very little “functional” about Swift. It’s a pretty traditional object oriented language with a focus on generic programming.

My conjecture is that people are using a feature list to determine a language’s paradigm. But there’s a reason we use the word paradigm.

paradigm. (n) A worldview underlying the theories and methodology of a particular scientific subject

“A worldview.” Yeah, that captures it.

The first public beta of Swift has been out for a week. I’ve been there since the beginning. I’ve read almost the entire book and have written many dozens of lines of Swift code. So as an expert in the field, I’m finally in a position to write the definitive review of the language. That’s a joke, son. But I’m going to dive in anyway, since that’s what you do once you hit your 140 character limit.

First, a spoiler. I basically like Swift. Given its goals and its constraints, I think it’s a move in the right direction. Many of those complaining most about Swift seem to misunderstand one or the other.

Renaissance 2014 has been a great conference so far, and I loved getting the chance to discuss security today. If you’re looking for the slides, code, and links, they’re available at github.com/rnapier/security-right. If you missed my talk and would like to see it, don’t forget that the videos will be available for $49 through tomorrow (Jan 31). After that, it’ll be $99.

More later, but right now I’m more interested in this talk on software ethics, so I’m going to get back to listening.

Short version: If you want to pin your SSL certs easily, go get RNPinnedCertValidator.

If your app uses SSL to communicate with your server (and it should), you generally don’t need to trust every certificate that Apple trusts. You should just trust the specific certificate of your server, or maybe your own root signing certificate. But there’s certainly no reason to trust the over 200 certificates in iOS 7’s root store.

The practice of trusting only your own certificate is called “pinning,” and I’ve discussed it several times at conferences. I then say something like, “It’s easy. You just do this:”

Summary: If there is any chance that your RNCryptor passwords include multi-byte characters (Chinese, for example), you really need to upgrade to RNCryptor 2.2 when it comes out this week.

I hate it when I do stupid things. But then you all get to learn something, so luckily some good can come of my shame. Please learn something so this isn’t all for naught.

Issue #77 in RNCryptor is one of those classic bugs. Here it is, as gently pointed out to me by Arthur Walasek:

int result = CCKeyDerivationPBKDF(keySettings.PBKDFAlgorithm,      // algorithm
                   password.UTF8String, // password
                   password.length, // passwordLength
                   ...

I have had this bug since I first wrote this code for iOS 5 PTL, and it’s horrible. The problem, if you haven’t seen it yet, is that -length returns the number of characters in password, not the number of bytes. In many languages you can get away with that, but not in multi-byte languages like Chinese.

I got an interesting question recently:

Assuming a password is not in a dictionary, what length is required to make a brute force attack infeasible?

That’s a pretty good question, and we should be able to answer it fairly easily given a few assumptions.

The short answer is, using RNCryptor and some reasonable security assumptions, it would be very difficult to brute-force an 8 character password randomly taken from all the easily typable characters on an English keyboard. The rest of this article will discuss my assumptions, and how you would calculate good lengths for other assumptions.

After several years of WordPress, I finally decided to make a change. The main change was getting rid of comments. There were several useful comments over the years, but the vast majority of the comments that came in were spam. The spam filters got most of them, but over the last year, more and more have been getting through. They’ve become more subtle over the years, and so more of a headache to deal with on my side. The handful of useful comments weren’t worth it. Most of the time, people comment in order to ask me a question. They can still easily do that through email, and I can post any interesting threads as another blog post.

If you’re using RNCryptor, you may want to join the forum I’ve finally setup: https://groups.google.com/forum/#!forum/rncryptor

I’ve built a candidate fix for the RNCryptor HMAC vulnerability. It’s on a branch (issue44) currently, but I’ll merge it to master next week if no one sees problems, and update the docs. By default it is incompatible with v1 files. If you need to be able to decrypt v1 files, you can define RNCRYPTOR_ALLOW_V1_BAD_HMAC when building.

Please let me know if anyone encounters issues.