Cocoaphony

A Week of Swift

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 Materials

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.

Pinning Your SSL Certs

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:”

RNCryptor: Truncating Passwords

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.

Brute Forcing Passwords

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.

New Blog Site

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.

New Forum for RNCryptor

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

Update on RNCryptor Vulnerability Fix

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.

RNCryptor HMAC Vulnerability (My Security Blunder)

Thank you to Allen Mann for discovering the following significant security vulnerability in RNCryptor.

The Vulnerability

RNCryptor computes the HMAC over the ciphertext only. It does not compute an HMAC over the header, particularly the IV. This allows an attacker to modify the IV and thus manipulate the first block (16-bytes) of decrypted plaintext. This is a major issue, and is exactly the kind of problem that RNCryptor is designed to avoid.

I will be modifying RNCryptor shortly to fix this. This will rev the file version to 2. I will provide a backward-compatibly option to read v1 files (default off). I strongly recommend that developers move to the v2 format.

I will try to get this out as quickly as I can, hopefully this week.

Animating Arbitrary KeyPaths

During CocoaConf-2012-Raleigh, I discussed my PinchView from Laying out text with Core Text. It’s a text view that squeezes the glyphs towards your finger when you touch it. I built it to demonstrate per-glyph layout in Core Text. While demonstrating it, I was pretty unsatisfied with how it looked when you touched it or let go. When you drag your finger on the view, the glyphs move around like water. It’s quite pretty. But when you initially touch the screen, the glyphs suddenly jump to their new locations, and then they jump back when you release the screen. Well, that’s no good. So I wanted to add animations.

But here’s the thing: what do you animate? While you do want to animate the glyph positions, you’re not doing it directly. The location of each glyph is dependent on the location of the current touch. What you want to animate is how much the touch impacts the glyph positions. A quick look over CALayer’s list of animatable properties confirmed that there’s nothing like that. But no problem, I added a custom property called touchPointScale and animated that. (I cover animating custom properties in the Layers chapter of iOS:PTL, and I still have to pull out that chapter every time to remind myself how to do it. Ole Begemann has a good, quick writeup on Stack Overflow.)