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 ?