Ideally, you should limit the server certificates you are willing to accept for a secure HTTPS connection. You can do this in connection:willSendRequestForAuthenticationChallenge: by using SecTrustSetAnchorCertificates() to set the acceptable list of root certificates to just your signing root (rather than “any trusted signing root”). This is detailed in Chapter 11 of iOS:PTL (page 222). I don’t believe I have any sample code posted for it, though.

That said, it’s certainly not the end of the world to just accept any device-trusted certificate (which is the default behavior). That gives you good protection against most attacks.

It’s a fairly simple format and should be implementable in any language. The one difficult part of it is that the HMAC is at the end. That means that when you get to the end of the message, you have to roll back 32 bytes to find the end of the ciphertext. This is required to allow streaming. As long as you’re able to encrypt or decrypt the entire message in memory, then this is a very easy format. If you want to support the same kind of streaming that RNCryptor does (where the entire message never has to be in memory), then you’ll need to do the same thing I do and use a read-ahead buffer.

RNCryptor will interoperate with OpenSSL format using RNOpenSSLCryptor, but this significantly reduces the security of the message. OpenSSL provides no message authentication, has a non-random IV, and a poor KDF.

As noted on the Data-Format page, I’ve considered supporting the more standard CMS format, but I don’t know a lot of products that support this and it would add a lot of code and data overhead for potentially little real benefit to developers. I’m not familiar with the formats that Windows uses for writing encrypted messages. If you have specs for the formats you’re interested in, I can look at them.

Generally if I were sending data to a server that the server was going to decrypt, I’d just use HTTPS. Is there a reason you’re performing a separate AES encryption?