| I tried IBM BlueCryptor which does what you said of using OpenSSL in Linux and CommonCryptor in Apple OS, but the problem that it took 132 seconds to run my unit test in Linux, while it took only 5 seconds in Mac OS. When I used your CommonCryptor version in Linux before it was taking almost same time like Mac OS. So I am switching back to use yours and not the BlueCryptor.
Could you elaborate more on the dangers of using your CommonCryptor version in Linux?
Thanks
Hi Amr,Am 11.06.2016 um 07:46 schrieb Amr Aboelela <amraboelela@gmail.com>:
Hi Nik
Yes I should have used NSUTF8StringEncoding
I just found the root of the problem though:
CommonCrypto_for_GNUstep/Source/AESedp$ vim AESAssembly.h
Change:
// Select which implementation to use.
#if 1
#define UseAESedp_IntelAssembly
#else
#define UseAESedp_GeneralC
#endif
To:
// Select which implementation to use.
#if 0
#define UseAESedp_IntelAssembly
#else
#define UseAESedp_GeneralC
#endif
I guess that might work, but it’s just a workaround for the problem. The root cause would probably lie within the architecture specific assembly code. You’ve just switched to the slow C implementation of the AES algorithm to make things work. That being said, the CommonCrypto port is seriously out of date, and Apple has essentially prevented us from doing a new one (short of a complete rewrite) because the newer CommonCrypto source dumps have a dependency on CoreCrypto, which is only available under a seriously restrictive evaluation license. So unless you are porting something with a lot of CommonCrypto calls, you might just be better off #ifdefing stuff to use openssl, gnutls or any other well maintained crypto library instead.Cheers,Niels
|