views:

421

answers:

1

I've been reading about Stanford's Secure Remote Password protocol, and it looks ideal for the sort of environment in which iPhone apps run. Unfortunately, I haven't been able to find a good Objective-C implementation of the protocol. Nor, as far as I can tell, do the crypto libraries in the SDK implement it.

Does anyone know of such an implementation?

Failing that, what's my best bet going to be, do you think? I could try to build OpenSSL into my app, but that feels like a really big thing to add for this one little piece. I could try to translate the JavaScript or Java implementations into Objective-C, but that violates the #1 rule of crypto (use a known, tested implementation).

Couple of follow-up items: first, it should probably be obvious from context, but I'm going to need something that is compatible with closed-source commercial usage (the JavaScript implementation I linked to, I later noticed, is AGPL).

Also, assuming I do end up going with OpenSSL, I'm having real trouble finding an example of using it to do SRP. Their site claims the code is in there, but I can't find any evidence of it, either in the OpenSSL documentation, or grepping the source code (v 0.9.8k). (Or am I seriously misreading things, and I still have to apply one of their patches to the OpenSSL source?)

EDIT:

What I could really use at this point is ready-to-use code, a fairly complete recipe, or some kind of example of using SRP in OpenSSL. I'm pretty sure I could cobble something together from scratch with the protocol docs, but I'm really trying to avoid reinventing the wheel, if I can help it.

+4  A: 

The OpenSSL and GnuTLS implementations of SRP-TLS are the only C-based ones I know that are maintained (TinySRP hasn't been updated since 2001, and there have been many security notices against the underlying OpenSSL version it's based on, though I don't know if they impact TinySRP itself).

That said, every iPhone project I've built has eventually had to include a copy of OpenSSL for something or other. I recommend just biting the bullet and using it. The instructions you link to work fine.

Personally, I build OpenSSL into a Universal library using lipo that has both arm and x86 versions. That way I can link to a single .a for both Simulator and Device. The lipo is very easy. Just build the two libraries and glue them together. Here's the rule from my Makefile:

/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/lipo \
  -create \
  -arch armv6 iPhoneOS$(SDK_VER)/lib/$(1) \
  -arch i386 iPhoneSimulator$(SDK_VER)/lib/$(1) \
  -output iPhoneUniversal$(SDK_VER)/lib/$(1)
Rob Napier
So how big does the OpenSSL library for the device end up? (And is it structured enough that the linker can leave unused bits out?)
Sixten Otto
libcrypto.a + libssl.a are over 2.5M, but they don't represent anything like that in the final binary. If I remember the last time I investigated, OpenSSL added around 400-500k to the final binary size. More than I'd want, but less than I feared. I tried to reduce the number of files in OpenSSL to improve compile time, since we only needed a few functions, but I quickly found this unworkable. OpenSSL is structured enough for the linker to split-up, but not enough for the compiler. YMMV depending on what functions you use.
Rob Napier