[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Implementation of CommonCrypto?
From: |
Niels Grewe |
Subject: |
Re: Implementation of CommonCrypto? |
Date: |
Fri, 4 Nov 2016 12:34:46 +0000 |
Hi Amr!
> Am 03.11.2016 um 00:57 schrieb Amr Aboelela <amraboelela@gmail.com>:
>
> 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.
Interesting, I’ve looked it up and it seem that BlueCryptor is written in
Swift, so it seems like I need to take a fresh look at what the Swift/C interop
story currently looks like. A 26.4x difference in performance sounds like a bug
that you’d want to report to the BlueCryptor project btw (maybe you already did
— I haven’t checked).
> Could you elaborate more on the dangers of using your CommonCryptor version
> in Linux?
Well, you’ve already discovered the bug in the AES assembly version, switching
to a slower pure C implementation. But in your place, I’d be be really
concerned about using a cryptography library that hasn’t seen bug-fixes since
the release of Mac OS 10.7.3 (that’s been release sometime in 2012, if my
Google search didn’t mislead me). It might be missing *a lot* of security fixes
that have been applied since then.
Of course, reimplementing the CommonCrypto API on top of libssl or libnettle
would be an option, but I’m not currently inclined to work on something like
that.
Cheers,
Niels