Would you recommend using this?

[svdo]

Hi @snej,

I'm working on an open source project, a peer-to-peer synchronisation library for iOS called "Pulse" (https://source.ind.ie/project/pulse-swift). The implementation of this library requires us to create self-signed certificates. Currently we're using OpenSSL for this. We're having all sorts of issues with that though, so we've been searching for alternatives.

Last weekend I ran into your MYCrypto library. I got it to work (with some modifications). What I like about it is that it is using the Apple APIs as much as possible. So here comes my question: with today's insights, would you recommend us using this library? I has been years since the last activity on this project, I'm not sure how widely it is used and whether it has been "proven in practice".

Thank you for your insights and advice!

Stefan

[snej]

These days, if you don't have a requirement to use a specific encryption type or data format, I'd recommend libSodium. It's what I'm using in my newer crypto-related code (which I haven't released yet.) But it sounds like you need to be compatible with an existing protocol, so it probably mandates what kind of ciphers/digests/signatures to use, right?

Most of MyCrypto works pretty well. The problems mostly have to do with using the Keychain, which is an absolutely terrible API and has only gotten worse over time. However, IIRC, the major Keychain problems I had involved trying to store symmetric keys, which you probably don't need to do.

[svdo]

Thanks Jens for your insights, I will have a look at libSodium. Maybe I'll stick with MYCrypto anyway because it is small and I can easily understand what it does :)

[snej]

The thing with libSodium is that it picks the algorithms for you. So if the protocol you need to implement is based on algorithms like RSA and SHA, you can't use libSodium.

But yes, feel free to use MYCrypto. If you run into problems, file issues and I'll see if I can remember enough about the code to help :)

[svdo]

Ok, maybe a question about the code then if I may.

I'm going to use this on iOS for creating a self signed certificate. So I'm looking at what MyCertificateRequest createSelfSignedIdentityWithPrivateKey:error: does. On iOS SecIdentityCreateWithCertificate is not available. So how to come up with a SecIdentityRef then... From studying your code, it seems that you are querying the keychain for an item with an expected digest as its kSecAttrApplicationLabel, this apparently returns the SecIdentity that was created. So here's the questions:

1. Is it an undocumented feature that you can get the SecIdentity this way? In other words: is it something that Apple may change (=break) in a future iOS version?
2. In identityWithDigest it actually says: kSecAttrApplicationLabel/*kSecAttrPublicKeyHash*/. Apparently you expected to need the kSecAttrPublicKeyHash? Was this based on 'trial and error'?

My concern here is that I want to understand how "future proof" this code is.

Thanks a lot!!

[snej]

Is it an undocumented feature that you can get the SecIdentity this way

My cynical answer is that most of the Keychain API is undocumented in this way — it gives you a handful of functions with a huge pile of properties to pass in, and doesn't specify what combinations of them work. (And what works is actually different across Mac and iOS, even though the API is the same...)

Was this based on 'trial and error'

Yes. I have literally spent entire days cursing the iOS Keychain and struggling to figure out what combination of properties to use to accomplish things.

[svdo]

I feel your frustration. 😬 Conclusion: it works as long as it does, we have tests in place to detect when it breaks 😄 Thanks again!

[svdo]

Hi Jens,

One more question. I decided to go ahead and reimplement the portion that I need in Swift. I'm pretty much done with that, I'll put it up somewhere soon, but I discovered something that I don't quite understand, I'm hoping you can shed a light on it.

When creating a self-signed certificate, in order to retrieve the matching SecIdentity you first import the certificate into the keychain, and then iterate through the identities in the keychain in order to find one with the expected public key digest. I discovered that there are actually two. They have the same public key digest, but their private keys seem to be different: if I sign something with the private key from the generated key pair, and also sign something with the private key of those two found identities, only one of them will give the same result. Also, when I get the raw data of the private keys, only one of them is the same as the one from the generated key pair.

Do you have any idea what's going on here, where is this second identity coming from?

[svdo]

Hmm, I think I found the answer on StackOverflow (http://stackoverflow.com/questions/19713368/secitemadd-creating-two-identities). This may actually be a bug in MyCrypto, I'm not sure that you pick the right identity :)

[snej]

Weird; that sounds like a Keychain bug. There should only be one Identity for a cert. But yeah, MyCrypto should set the options so it gets the right one.