The results of these tests are not intended as an apples-to-apples comparison. The intention of these tests is to be able to make a comparison of different crypto-systems to estimate performance impact and where the data is useful.
As a baseline algorithm AES with a 128 bit key was chosen. This will serve as the minimal performance impact possible by encryption. This assumption relies on the AES implementation using a AES instruction set on the Central Processor Unit (CPU) [Gue12]. The testbench does not support this instruction set so the comparative difference in speed is going to be greater on a production system with an x86 CPU if properly set up.
5.2.1 Benchmark suite
The benchmark is done by a Java program that has a collection of tests, run them in randomised order, and prints out the results.
Each test implements an interface used to run the tests and print information about the test.
∗ This i s where keys are generated , mock data
∗ a l l o c a t e d e t c .
∗ This i s c a l l e d j u s t b e f o r e the t e s t .
∗∗ @return t r u e i f f no e r r o r s occurred boolean∗/ setup ( ) ;
5.2. METHODOLOGY 45
The main program generates up the test collection. It re-uses instances to save memory.
If any test fails it will get re-queued and run again at the end of the list. This will repeat for a number of attempts until the suite has made 2ntests wherenis the number of tests in the original list. A successful test will get removed from the cycle.
All tests has been set to repeat for 1000 cycles. To avoid key generation slowing things down the cycles use the same cleartext, the same keys and the same ciphertext every time. This means that if Java optimises its systems by caching results (called memorisation), all these tests are invalid. These kinds of optimisations does not seem likely because Java do not have a mechanism for telling the optimiser about deterministic functions.
The code used for these tests are included in Appendix C
5.2.2 GPSW ABE
The GPSW cipher is described in subsection 4.5.3.
For these tests AND gates are emulated using 2of2 nodes. Or gates could be emulated with 1of2 nodes, but the specific implementation uses the threshold 1 to indicate a leaf node.
46 5. BENCHMARKING THE ALGORITHMS
The implementation of this algorithm is one done by Liang Zhang [Zha14]. This implementation was in that project found suitable for a health record encryption.
For big data there is a different requirement for speed. Note that it is assumed that the implementation is correct, at least in terms of computing power. No major effort has been put into checking the implementation’s correctness.
This implementation uses a library for pairing based encryption written by De Caro and Iovino [DI11]. This library does the major heavy lifting of the implementation.
The impression of this library is that it is suitable for academic work, not yet for production.
Another candidate that were considered was De Caro’s implementation of a system by Brent Waters that uses a regular language as policy [Wat12]. This implementation was dismissed on basis on it being hard to automate variations and the preliminary run times being too long to even be considered.
The implementation uses the GPSW algorithm to seed the generation of an AES key. In the tests this AES key is used to encrypt/decrypt 32 bytes of data (one 256 bit AES key). This is a redundant way of doing things, but it it allows for a self chosen key to be used.
The tests for this algorithm has three variables: The number of attributes in total, the number of attributes assigned to a message, and the number of attributes used in the decryption key. Each of these variables have a separate test set where the other variables are kept fixed.
In the tests varying the total number of attributes in total the master key varied between 6 and 57. The number of attributes assigned to each message was one for encryption and two for decryption. The number of attributes in the decryption key was set to one.
In the tests varying the number of attributes in a message the number was varied between 6 and 57. The total number of attributes was set to 101. The number of attributes in the decryption key was set to one.
In the tests varying the number of attributes in the decryption key the number was varied between 2 and 56. The number of attributes in total was set to 101. The number of attributes in each message was set to 100. The key was built using a simple AND tree as seen in Figure 5.1.
5.2.3 RSA
The RSA algorithm is described in subsection 4.5.2
5.2. METHODOLOGY 47
B A
C A
A
B
B
AND AND
C
AND AND
D AND
AND
Figure 5.1: Examples of how AND trees are built for the tests, using 3, 2 and 4 attributes respectively
For these benchmarks the key lengths used are 1024, 2048, 4096, and 5120 bits.
The length of the data to be encrypted is 32 bytes or 256 bits.
The implementation used is Java’s built-in implementation of the crypto-system.
5.2.4 AES
The AES algorithm is described in subsection 4.5.1
The implementation used it Java’s built in implementation with Cipher Block Chaining (CBC) and PKCS5 for padding. This implementation should use the AES instruction set [Gue12] for encrypting the data [Koz] and thus be very fast.
The variable for this test is the size of the data to be encrypted. The tests are using a base number of 64 Bytes and bit shifting it between 1 and 19 bits. The result is every factor of two between 128B and 32MB.
48 5. BENCHMARKING THE ALGORITHMS