We used ecb mode before, but now we need to change to aes-gcm algorithm to encrypt and decrypt messages and verify signatures. I know that there is “/AES/GCM/NoPadding” in java to achieve gcm. Does Apple provide corresponding function libraries?
We used ecb mode before
Yikes!
but now we need to change to aes-gcm algorithm
Much better.
Does Apple provide corresponding function libraries?
The only public API for AES-GCM is the one provided by Apple CryptoKit. That is only available in Swift. If you want to use it from Objective-C, create a Swift wrapper that publishes the necessary functionality to your Objective-C code.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
And if I need to support iOS versions older than 13, where CryptoKit was introduced? Thank you
And if I need to support iOS versions older than 13 … ?
You will to write or acquire your own AES-GCM library.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Is it ok to use ?https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60074/include/CommonCryptorSPI.h
will there be any issues in App Store review if we use above API?
Sadly, I'm trying update an app, that supports iOS 12. When upload to the App Store with this codes, I got an error: "Asset validation failed The app references non-public symbols = in Payload/YourApp.app/YourApp: _CCCryptorGCM". And the build has never been processed.
Is it ok to use [SPI]?
No. This is likely to get your rejected by the App Store ingestion process but, even if you get past that, you run the risk of binary compatibility problems down the line.
I recently took a DTS incident where the conversation went like:
Developer My app is broken on iOS 15 because a Common Crypto API is no longer present.
Quinn Weird. What API?
Developer [details redacted]
Quinn That’s not API, it’s SPI [1]. Where did you learn about it?
Developer From Darwin.
Quinn Darwin is cool but you can’t treat the stuff you find there as API.
Developer What do I do now?
Quinn You’ll have to write or acquire your own code for [details redacted].
Developer That’ll take a while. What about my users who can’t launch my app on iOS 15.
Quinn They are gonna write a bunch of angry reviews.
Don’t fall into the same trap!
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] In Apple parlance, SPI stands for system programmer interface. We don’t use the term private API because, by definition, APIs are public.
@eskimo you might want to think about changing your signature, because,
They are gonna write a bunch of angry reviews. Don’t fall into the same trap! Share and Enjoy
sounds quite utterly condescending...
I'm facing the same issue here, as I'm writing some crypto stuff for a core lib we're doing in C++ to be used by our apps devs on both MacOS and iOS (who are dealing with different layers, C++, Obj-C and Swift). I need to implement simple AES in both CBC and GCM (with AAD and tag) for different purposes, and I'm quite struggling to find a simple way of doing that using only native APIs. CommonCrypto or SecKey APIs are really nice, it's too bad I can't rely on those for my current needs, which are pretty standard in today's crypto landscape. I wanted to stay away from using openssl on apple platforms (no to mention they're not doing so good with modernizing their APIs and keeping decent performances...), but if I want to keep things simple, I might have no choice here... It would be really nice to have AES GCM available in lower-level APIs (it has been available in SPI, so it is already there somewhere...), I understand CommonCrypto is on its way out, but at least somewhere in Security where we could access it from core code where using Swift/CryptoKit would not always make total sense.
Please help my in my quest of keeping things simple :)
Cheers!
It would be really nice to have AES GCM available in lower-level APIs
Speaking personally, I agree with you, but that’s not how the system is currently built. If you’d like to see that change in the future, I encourage you to file an enhancement request describing your requirements.
Please post your bug number, just for the record.
As things stand today, your options are:
Bridge over to the Apple CryptoKit AES-GCM implementation, assuming that’s compatible with your deployment target.
Write or acquire your own AES-GCM code.
With regards that first option, on current production tools the best way to get from C++ to Apple CryptoKit is via C++ > Objective-C++ > Swift. That will improve when the Xcode 15 beta is released, because it has support for C++ interoperability in Swift. You’ll still need to write some glue, but you can skip the Objective-C++ step.
For more on that topic, see WWDC 2023 Session 10172 Mix Swift and C++.
Please help my in my quest of keeping things simple :)
If things were simple I’d be out of a job |-:
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
