Thankyou Quinn and nk_kennedy, for all the helpful advice you have given.
I am seeing clearer now.
Thank you Quinn for reply.
This is what I am in the process of doing at the moment.
However, I have a bit of a doubt about AES in the CryptoCompatibility code.
Would I be right in saying that it can only do AES128 ?
If that is the case, would I be right that I would need to make an interface to CCCryptorCreateWithMode to be able to specify AES256 with CBC ?
I have the impression that this would mean a sequence of calls :
CCCryptorCreateWithMode
CCCryptorUpdate
CCCryptorFinal
CCCryptorRelease
Have I understood this correctly ?
Hi Quinn,
Thank you for your reply.
you can then decide whether it’s worth your time porting them to Swift.
There is really no decision to make, it would appear that I have to go with that - if I keep with CommonCrypto, unless there is a "better" option (???).
So, from what I see, CommonCrypto is an Apple Open Source C library (no lib file ?) which requires an Objective-C wrapper, hence the CryptoCompatibility sample code.
Can you confirm that I do not need to adjust the settings of the Swift app to do this (I already mix C++/Objective-C++ and have a bridging header ) ?
When I compare the include dir on the open source page - here - there are considerably more headers.
Within my XCode sdk installation I have :
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/CommonCrypto ->
CommonCrypto.h
CommonCryptoError.h
CommonCryptor.h
CommonDigest.h
CommonHMAC.h
CommonKeyDerivation.h
CommonRandom.h
CommonSymmetricKeywrap.h
module.modulemap
9 as opposed to 26 in the open source site.
Can you confirm that I will indeed be able to do AES-CBC and RSA-ECB with just these headers ?
