![David Garske](/assets/img/avatar_default.png)
Ran updated iPhone X benchmarks: ``` RNG 330 MB took 1.010 seconds, 326.879 MB/s AES-128-CBC-enc 920 MB took 1.005 seconds, 915.507 MB/s AES-128-CBC-dec 6095 MB took 1.000 seconds, 6092.130 MB/s AES-192-CBC-enc 820 MB took 1.000 seconds, 819.644 MB/s AES-192-CBC-dec 4860 MB took 1.001 seconds, 4855.794 MB/s AES-256-CBC-enc 710 MB took 1.005 seconds, 706.419 MB/s AES-256-CBC-dec 3935 MB took 1.001 seconds, 3930.830 MB/s AES-128-GCM-enc 1245 MB took 1.003 seconds, 1241.589 MB/s AES-128-GCM-dec 575 MB took 1.001 seconds, 574.547 MB/s AES-192-GCM-enc 1235 MB took 1.001 seconds, 1234.343 MB/s AES-192-GCM-dec 570 MB took 1.003 seconds, 568.521 MB/s AES-256-GCM-enc 1230 MB took 1.003 seconds, 1226.034 MB/s AES-256-GCM-dec 570 MB took 1.001 seconds, 569.199 MB/s 3DES 10 MB took 1.386 seconds, 7.213 MB/s MD5 95 MB took 1.037 seconds, 91.629 MB/s SHA 80 MB took 1.013 seconds, 78.943 MB/s SHA-256 1625 MB took 1.000 seconds, 1624.565 MB/s SHA3-224 60 MB took 1.010 seconds, 59.399 MB/s SHA3-256 60 MB took 1.073 seconds, 55.921 MB/s SHA3-384 45 MB took 1.042 seconds, 43.195 MB/s SHA3-512 35 MB took 1.164 seconds, 30.063 MB/s HMAC-MD5 95 MB took 1.044 seconds, 91.014 MB/s HMAC-SHA 80 MB took 1.007 seconds, 79.480 MB/s HMAC-SHA256 1705 MB took 1.001 seconds, 1703.126 MB/s RSA 2048 public 32800 ops took 1.003 sec, avg 0.031 ms, 32716.405 ops/sec RSA 2048 private 1200 ops took 1.041 sec, avg 0.868 ms, /33 ops/sec DH 2048 key gen 2354 ops took 1.000 sec, avg 0.425 ms, 2353.254 ops/sec DH 2048 agree 2500 ops took 1.013 sec, avg 0.405 ms, 2467.525 ops/sec ECC 256 key gen 46503 ops took 1.000 sec, avg 0.022 ms, 46502.069 ops/sec ECDHE 256 agree 14100 ops took 1.005 sec, avg 0.071 ms, 14034.697 ops/sec ECDSA 256 sign 29600 ops took 1.003 sec, avg 0.034 ms, 29500.554 ops/sec ECDSA 256 verify 11000 ops took 1.007 sec, avg 0.092 ms, 10921.516 ops/sec ```
wolfSSL and wolfCrypt Xcode Projects for OS X and iOS
This directory contains the following files:
wolfssl.xcworkspace
-- workspace with library and testsuite clientwolfssl_testsuite.xcodeproj
-- project to run the testsuite.wolfssl.xcodeproj
-- project to build OS/x and iOS libraries for wolfSSL and/or wolfCryptwolfssl-FIPS.xcodeproj
-- project to build wolfSSL and wolfCrypt-FIPS if availableuser_settings.h
-- custom library settings, which are shared across projects
The library will output as libwolfssl_osx.a
or 'libwolfssl_ios.adepending on the target. It will also copy the wolfSSL/wolfCrypt (and the CyaSSL/CtaoCrypt compatibility) headers into an
includedirectory located in
Build/Products/Debugor
Build/Products/Release`.
For the library and testsuite to link properly the build location needs to be configured as realitive to workspace.
- File -> Workspace Settings (or Xcode -> Preferences -> Locations -> Locations)
- Derived Data -> Advanced
- Custom -> Relative to Workspace
- Products -> Build/Products
These Xcode projects define the WOLFSSL_USER_SETTINGS
preprocessor
to enable the user_settings.h
file for setting macros across
multiple projects.
If needed the Xcode preprocessors can be modified with these steps:
- Click on the Project in "Project Navigator".
- Click on the "Build Settings" tab.
- Scroll down to the "Apple LLVM 6.0 - Preprocessing" section.
- Open the disclosure for "Preprocessor Macros" and use the "+" and "-" buttons to modify. Remember to do this for both Debug and Release.
wolfSSL
This project should build wolfSSL and wolfCrypt using the default settings.
wolfSSL-FIPS
To use the FIPS version, one must have the FIPS sources. The project won't build without them. Please contact info@wolfssl.com for more information about wolfCrypt with FIPS.
By default, this builds the wolfSSL and wolfCrypt with FIPS library. The default configuration enables the settings required for FIPS. Others may be turned on. The project also ensures the FIPS related objects are linked in the proper order.
Building libwolfssl.a
There are several options of builds. You can make a simulator build, or a device build. Both are debug builds.
You can make an archive for a device, as well. That is a release build.
Known issues:
When building for older i386 architectures and using tfm.c there are specific CFLAGS required to expose the necessary registers for inline assembly in tfm.c. An example script has been provided "build-for-i386.sh" that targets the watchos by default. If using SDK iphonesimulator10.1 or older you can change the SDK variable in that script however newer versions of the SDK no longer support i386 for the iphones.
Installing libwolfssl.a
Simply drag the file libwolfssl_XXX_.a and the directory include
and drop it into
your project file list pane where it makes sense for you. Allow it to copy the
files over to the project directory. This should automatically add the library
to the list of libraries to link against.
Click on your project target, then the "Build Phases" tab. On the targets list click your target. Click the disclosure triangle on the section "Link Binary With Libraries" and verify libwolfssl.a is in the list. If not, click the "+", and on the "Choose frameworks and libraries to add:" dialog, click the button "Add other..." then find the file libwolfssl.a.
Click on the "Build Settings" tab. Scroll down to the section "Search Paths". Add the path to the include directory to the list "Header Search Paths".
When using FIPS
When using the FIPS version the following preprocessors need to be defined:
IPHONE
HAVE_FIPS
HAVE_HASHDRBG
HAVE_AESGCM
WOLFSSL_SHA512
WOLFSSL_SHA384
NO_MD4
NO_HC128
NO_RABBIT
NO_DSA
NO_PWDBASED
The approved FIPS source files are from the CyaSSL project tag v3.4.8.fips. The files fips.c and fips_test.c, and the wolfCAVP test app are from the FIPS project tag v3.4.8a. The wolfSSL/wolfCrypt files are from tag v3.4.8.
Using the FIPS library
The FIPS library contains a self-check verify hash. Normally, on the desktop or server build, the library is built as a dynamic library. The library looks the same to every application that builds against it, and can be verified. For static libraries, when linking into your application, the addresses are all fixed, and the verify checksum becomes unusable. iOS does not allow dynamic libraries like this, so static builds are required. This creates a problem. Every time the application is changed, the FIPS checksum will change, because the FIPS library's position in the executable may change.
You need to add something to your application that will output the verifyCore value to be used. The verifyCore in fips_test.c will need to be updated with this value, the library rebuilt, and relinked into your application. The application should not be changed during this process or the verifyCore check will fail again.