HMAC in iOS 10+

Hi,


i'm trying to make a framework, with some ECC functions, to be shared between apps and other developers as well.


As i'm targeting iOS 10+ currently, i'm able to enjoy the excellent updates to the Security framework - from key and signature generation, to it's verification and making of shared keys. But i've run into a few questions.



First, is it possible to generate an HMAC without having to go to CommonCrypto, preferably using something from the Security framework (obviously it's possible to write ones own implementation for generating an HMAC, but let's leave this option out for n + 1 reasons)?


If no, then can i use CommonCrypto in apps destined for the App Store? If not, what are the options?

My current implementation is done using this function:

CCHmac(CCHmacAlgorithm(kCCHmacAlgSHA256), hmacKey, hmacKey.count, hmacData, hmacData.count, &hmac)

Which i presume does the same thing as the functions below?

If not, what are the differences between the above and the functions below?

CCHmacInit(...)
CCHmacUpdate(...)
CCHmacFinal(...)



Best of wishes,

Mikk

Accepted Reply

First, is it possible to generate an HMAC without having to go to CommonCrypto …

The iOS SDK has no other APIs for HMAC.

If no, then can i use CommonCrypto in apps destined for the App Store?

Of course.

Just for my own curiosity, what makes you suspect that CommonCrypto use would be a red flag for the App Store?

Which i presume does the same thing as the functions below?

Correct.

If not, what are the differences between the above and the functions below?

The one shot API is easy to use, and thus a no brainer when the data fits in memory. The incremental API is useful if you’re streaming through a large file, something that’s not uncommon in the crypto space.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

First, is it possible to generate an HMAC without having to go to CommonCrypto …

The iOS SDK has no other APIs for HMAC.

If no, then can i use CommonCrypto in apps destined for the App Store?

Of course.

Just for my own curiosity, what makes you suspect that CommonCrypto use would be a red flag for the App Store?

Which i presume does the same thing as the functions below?

Correct.

If not, what are the differences between the above and the functions below?

The one shot API is easy to use, and thus a no brainer when the data fits in memory. The incremental API is useful if you’re streaming through a large file, something that’s not uncommon in the crypto space.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for clearing it up for me.


For your curiosity - i think it was saved to my mind from some pages while digging through the examples, guides and QAs in the web for ECC. Probably reinforced by it not being a proper framework (from Swift's point of view).


This leads me to another question when building a Swift .framework.


To use CommonCrypto in the framework, i can't use a Bridging Header to import it?

If yes, then how one should proceed? Something with the module.modulemap?

i think it was saved to my mind from some pages …

Hmmm. There is parts of Common Crypto that are not public API — potentially very useful parts, like the AES-GCM support — which might explain your concern. Rest assured that the stuff declared in the public headers is public API.

Probably reinforced by it not being a proper framework …

You mean module here, not framework. Darwin, GCD, and many other things are modules, even though they’re not frameworks.

To use CommonCrypto in the framework, i can't use a Bridging Header to import it?

Correct.

If yes, then how one should proceed? Something with the module.modulemap?

I don’t know of an ideal way to do this. The way I usually deal with it is to write an Objective-C wrapper that provides the necessary CommonCrypto abstraction and then include that wrapper in my framework’s public API. My Swift code inside the framework can than access the wrapper like any other part of the framework’s Objective-C public API. And the Objective-C wrapper can include CommonCrypto inside its

.m
file, which avoids any non-modular include entanglements.

It would be nice if you could make this wrapper private (or, better yet, internal) but I’ve never dug into that deep enough to know whether it’s possible.

If you want a definitive answer to this I recommend you open a DTS tech support incident so that you can discuss it with one of our tools experts.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"