Cryptography Project

4005-705-01 Ken Beck Kevin Cheek Jonathan Potter 2009-11-06

1. Introduction.......................................................................................................................................3 2. Description of Akelarre ....................................................................................................................3 A. General............................................................................................................................................3 B. Cryptographic Primitive..................................................................................................................4 3. Analysis of Research Papers ............................................................................................................5 A. Cryptanalysis of Akelarre ...............................................................................................................5 B. Ciphertext-Only Attack on Akelarre...............................................................................................6 C. Two Rights Sometimes Make a Wrong ..........................................................................................7 A. Known Plaintext Attack..............................................................................................................8 B. Ciphertext Only Attack ...............................................................................................................9 C. Conclusions.................................................................................................................................9 4. Attack Descriptions.........................................................................................................................10 A. Known Plaintext............................................................................................................................10 B. Brute Force....................................................................................................................................12 5. Program Design...............................................................................................................................14 A. Overview.......................................................................................................................................14 B. Inputs and Outputs ........................................................................................................................15 6. Running Time..................................................................................................................................17 A. Benchmarks...................................................................................................................................17 B. Variant Comparisons ....................................................................................................................18 C. Brute Force Comparison .................................................................................................................0 7. Manuals............................................................................................................................................20 A. Developers Manual .......................................................................................................................20 A. Packages and Classes................................................................................................................20 A. Akelarre Class.......................................................................................................................20 B. KeyScheduler Class ..............................................................................................................20 B. Compilation...............................................................................................................................22 B. User Manual..................................................................................................................................22 A. Encrypt with Akelarre...............................................................................................................22 B. Decrypt with Akelarre...............................................................................................................23 C. Attacks & Benchmarks .............................................................................................................23 8. What We Learned...........................................................................................................................25 9. Future Work....................................................................................................................................26 10. Bibliography ....................................................................................................................................27

Introduction
Team coconut is a group of cryptography students who have decided to attack the Akelarre cipher. Akelarre was developed in 1996 and within a year was completely broken by Bruce Schnier and numerous other cryptography researchers. Today it is used as a common example in some cryptography books for demonstration purposes. However, even though it has been widely used in these books no one has actually created a real world known plaintext attack on Akelarre. The following is team coconuts reduced strength variant of such an attack.

Description of Akelarre
General
Akelarre was proposed in 1996 at SAC, and it was designed by G. lvarez, D. de la Gua, F. Montoya, and A. Peinado. Akelarre was written with the respected block ciphers RC5 and IDEA in mind. Akelarre uses design pieces from these two ciphers, and combines them into it's own presumably secure algorithm. However, only one year after its proposal, in 1997, a ciphertext only attack for it was released and since then it has been shown through various papers including those which we analyzed to be a weak block cipher. After the cryptanalysis of Akelarre, it's creators proposed an updated form, known as Ake98, that was intended to fix the weaknesses of Akelarre. Ake98 is much stronger than Akelarre, but is still considered broken because keys can be recovered in less than brute force time (on the order of 2 ). Akelarre is a 128-bit block cipher with a variable sized key that must be a multiple of 64 bits, and it can use any number of rounds. By default Akelarre uses as 128-bit key with 4 rounds. The algorithm for Akelarre is shown by the following diagram.
70

The main piece of Akelarre is the AR (addition rotation) block, and this is the part that was inspired by both RC5 and IDEA. Surprisingly enough, even though Akelarre uses designs of two presumably strong block ciphers, it itself has been shown to be weak with any key size and any number of rotations.

Cryptographic Primitive
The cryptographic primitive for Akelarre is a block cipher. In general, block ciphers are symmetric key ciphers which have a fixed block size. For illustration we will assume a block size of 128 bits. This means that the block cipher can take a plaintext input of length 128 bits and encrypt it outputting the ciphertext of length 128 bits. If the block cipher needs to encrypt anything more than 128 bits long, it must use a mode of operation. Akelarre uses a block size of 128 bits, and breaks each block into four 32-bit words which it then passes into the input transformation. Akelarre is an iterated block cipher, and it uses a round function after the input transformation, and it applies the round function repeatedly to an input block. From there the block passes to the output transformation.

Analysis of Research Papers

Cryptanalysis of Akelarre
This paper was written by Bruce Schneier and Neils Ferguson. Its goal is to provide an analysis of the Akelarre algorithm and it was published just a year after the proposal of the Akelarre cipher. This paper made a made a significant contribution to the problem due to the fact that it was one of the first papers to analyze the security of the Akelarre cipher. The two attacks described were significant and prevented the widespread adoption of the cipher. The first proposed attack on the cipher was divided up into four steps. The first step was to recover the output transformation sub-key bits. Exploiting the fact that the parity relation remains the same across the round function, he sets up this equation.

Y is a 32bit word from the output. K4 is a section of the sub-key. By plugging in values for y' Schneier can eliminate half the possible values for k4 and then exhaustively search 2 same equation for k1 and the find these sub-key bits in 2
32 31

possible values for the rest. He can then setup the

steps.

The second phase of the attack was designed to recover the input transformation sub-key bits. He can do this by choosing fixed values for x1, x2, x3, and performing a number of encryption operations for x4. This gives Schneier a sum parity relation that he uses to recover 31 bits of z4 and z1 The third phase and fourth phases of the attack are observations about the key schedule in the Akelarre cipher. In the sub-key generation each one can only have between 24.1 and 25.7 bits of entropy. Then due to other problems in the key schedule, the amount of information that can be gained about the master key changes dramatically between rounds. For example, the 5 round version of Akelarre is significantly weaker than the 4 round version of Akelarre. The attacker should be able to gain more information about the master keys from the observations in this phase. At the end of the entire process an attacker should know 80 bits of information about the 128-bit key leaving 2 possible keys to try. The second Schneier attack is based on the first but uses the differential characteristics to reduce the amount of time required. Schiener observation is that any 64-bit pattern that is repeated for the creation of a 128 bit key contains a differential with probability 1. Using this information he is able to reduce the time the previous attacks take to an average of 2
41 48

tries before a key is found.

Schneier took advantage of three fundamental weaknesses in the algorithm. He observed that even if those three weakeness in the algorithm were fixed, it would still be unclear how secure the cipher is. Despite his attacks and the observations provided, in our investigation it was Schneier's description of the algorithm that was the most helpful.

His description was clearer than the original Akelarre proposal and we used it as a stepping stone for the implementation of the encryption and decryption functions.

Ciphertext-Only Attack on Akelarre

This paper was written because the Akelarre cipher was presented and in order for it to be widely used research had to be done on it. This paper made a contribution in this area by describing a couple of different attacks that can be performed on the Akelarre cipher. This paper starts off by describing a plaintext-ciphertext attack, much like that described in the 'Two Rights Sometimes Make a Wrong' paper, but then goes on to describe a ciphertext-only attack, which is what we focus on for this analysis. The attack described requires some knowledge about the distribution of the plaintexts. For instance, the paper tells us it is sufficient to know that the plaintext contains ASCII-encoded English text. In this situation, the upper bit of the plaintext will always be zero. During the encryption process, the plaintext is XOR'd with various sub-key bits. Since the upper-most bit of every plaintext encrypted is zero, the upper-most bit of the XOR'd data becomes constant. After the full encryption takes place, it's possible to analyze several ciphertexts to determine which bits in the texts are constant. "By observing the ciphertexts it is possible to see where the almost constant bits have moved to." Once you know where these bits are located, it is possible to determine the 128-bit rotation amount mod 8. According to the paper, determining this number is possible nearly 100% of the time with as little as 100 ciphertexts. Once the rotation mod 8 is known, there are four possibilities for a 32-bit rotation. A 32-bit (not the full 128-bit) rotation is all that is necessary to determine the appropriate sub-key bits. Since there are only four possibilities, the rest of the attack is simply performed for each of the values. For each of the potential 32-bit rotations, the inverse of the rotation is applied to the ciphertexts. For simplification, the paper assumes this rotation is actually 0, which is what we do for our attack as well. Given this fact, we can rewrite the equation: , which is used in the known plaintext attack, as: , with the rotation taken out. The paper states that can take on either the values (1,3) or (4,2). If the first set of

values do not work, simply perform the attack again with the alternate set of values. For the purpose of this attack, assume the values for table "contains the distribution of distributions. are (1,3). The rest of the attack is apparently based on , where each ." These tables contain what are known as theoretical

the concept of Maximum Likelihood, and involves generating tables for every possible value of

After these distributions are created, the same thing is performed for table for every possible value of the three K's that contains the distributions of

and

, producing a

. The distributions found in this part of the attack come from generating several thousand ciphertexts and observing the actual distribution of the data. Thus, these tables contain practical distributions. Once the above steps are completed, the tables of practical distributions are compared with the tables of theoretical distributions. There will be the most correlation between theoretical and practical distributions for the sub-key values that are correct. In this way, it is possible to determine the sub-key values necessary for calculating the plaintext given only the ciphertext. This approach sounds at least a little feasible. However, I believe the creation of the distribution tables may prove impractical in practice. The sub-keys are all 32 bits in length, and thus generating the distribution tables would require generating a table for each of the possible key values. While this may prove more plausible in theory than brute forcing a 64-bit key, this will still take a tremendous amount of work. This paper made a novel contribution by attacking Akelarre then presenting a feasible ciphertext only attack. The attack we used in our project used this general approach, except that we used known plaintexts to make the attack even more doable.

Two Rights Sometimes Make a Wrong

Akelarre was proposed in 1996 at SAC. It combines ideas from two respected block ciphers: RC5 and IDEA. Since both of these ciphers are strong, it would seem that Akelarre being a derivative would be strong as well. In fact, this paper set out to prove that it is not the case. RC5 and IDEA each relatively simple, but when Akelarre combines ideas from both of them it ends up being complicated and fairly weak. The paper is entitled "Two Rights Sometimes Make a Wrong" because it shows that Akelarre is counter-intuitively weak (wrong) even though it combines two strong (right) ideas. The goal of this paper is to show that Akelarre is a weak cipher with any key size and any number of rounds. The following is the diagram of Akelarre that is used in this paper. It shows how Akelarre works and shows the variable names used throughout the paper:

Known Plaintext Attack

This paper describes a known plaintext attack on Akelarre that works, surprisingly enough, for any key size and any number of rounds. The goal is to recover enough sub-keys to be able to decrypt new messages. This paper demonstrates how to bypass the round function altogether and relate the ciphertext directly to the plaintext. The main weakness of Akelarre that this paper exploits, is that for round transformation there is a relation between the input and the output.

Then after R rounds we will get

where

After some substitutions, which can be found fully described in the paper, the next equation follows which relates the ciphertext to the plaintext completely bypassing the AR block:

In this equation,

denotes the plaintext, denotes the concatenation of bit strings,

denotes the keywords. This is the equation that we used as the basis of our known plaintext attack. The equation shows that there is a relation between the plaintext and the cipher text, and so, if the plaintext contains enough redundancy, the problem can be solved fairly easily.

Ciphertext Only Attack

The paper also describes a ciphertext only attack that is based on statistical analysis of the ciphertext. If you know that the encrypted message contained only ASCII characters of a certain language, statistical probabilities are enough to determine the eight key words the previous section. and . When you find these, you can then carry out the attack from

Conclusions
All in all, this illustrates that there are feasible attacks on Akelarre for any number of rounds and any length of key. It shows that even though Akelarre combining pieces of strong block ciphers (RC5 and IDEA) does not always produce a good block cipher. The attack we implemented for this project comes directly from the one in this paper. We used the known plaintext attack described by the paper, and implemented it for the weakened Akelarre cipher.

Attack Descriptions
Known Plaintext
The known plaintext attack described in the majority of the papers we utilized defined a method of attacking Akelarre that works, no matter how large the key and no matter how many rounds the algorithm uses. This was made possible because of a weakness in Akelarre's round function: it is possible to define the outputs of the round function in terms of the same round's inputs. This fact can be exploited for any number of rounds, and produces two equations in which the ciphertext can be related directly the plaintext input:

and

where

represents a 64-bit left-rotation of the right-hand side of the equations.

To simplify our attack, our reduced-strength variation of the algorithm removes the keyed-rotation from the input and output transformations, thus removing the rotations from the equation above, and producing:

and

To simplify this explanation, we will present 8-bit values here, as opposed to the full 32-bit values, but the steps can be expanded to any number of bits. The first step of the attack is to acquire 'sufficient known plaintexts'. According to the paper, five known plaintexts should suffice to solve for the four unknown sub-keys and the unknown rotation. Thus, four plaintexts should suffice to solve for the unknown sub-keys alone: X={ {78 77 6d 71} {65 61 76 6a} {75 70 73 66} {6a 6f 66 6b} } The above plaintexts produce the following ciphertext (truncated to still represent a byte).

Y={ {9c 61 70 a2} {77 67 87 79} {7b 52 4e 99} {b2 1f 57 4e} } Given these values, we can create multiple equations to represent the K's:

Let's simplify these equations by assigning shorter variables for each K:

This gives us four equations and four unknowns. The problem with solving these equations is that the addition and subtraction, alongside the XOR's, makes it difficult to solve for a specific value. The papers suggest, instead, to solve each equation one bit at a time. This allows us to rewrite each of the equations utilizing just XOR's. For the first bit, the original equation becomes:

which can be rewritten as:

All bits after the first bit must take into consideration the possibility of a carry from the previous step's addition / subtraction. Thus, for bits , the above equation becomes:

We can rearrange the above equation so that b XOR c is on one side, then, with two plaintext/ciphertext pairs, we can generate two equations and two unknowns. Setting the two equations equal to one another (since b XOR d will be the same in both), we can perform a bit-by-bit brute force attack and find a and c. This attack is demonstrated in the class Coconut.BacktrackAttack.

While this method should work, in our tests, we were unable to generate the appropriate values. The attack simply fails on the plaintexts generated by our algorithm. However, we came up with a solution that at least works in finding a, c, and b XOR d for problem 20 presented in ("Applied Cryptanalysis",210). This attack does not utilize the carry bit at all. Instead, it just determines all values of a and c, bit by bit, that satisfy the equation:In known plaintext attack description talk more about what we actually implemented -Kevin Cheek 11/7/09 7:27 PM , where (X1,Y1) and (X2,Y2) are two different plaintext/ciphertext pairs. For instance, to start off, the values (0,0), (0,1), (1,0), (1,1) for (a,c) are tested against the equation. For each value that the equation holds true, four new values are generated by OR'ing the value with each of the original values shifted to the left by one. These new values are tested against the equation, and the process repeats until all bits are found. This provides us with a list of values that satisfy the equation. This list is narrowed down by verifying that the subkeys solve the equation given several different plaintext/ciphertext pairs. Benefits of the known plaintext attack: 1. Can operate "offline", meaning once the plaintexts and ciphertexts are acquired, there is no more reason to use the encryption algorithm. 2. Requires determining only the four-byte sub-keys that Akelarre produces; thus, it works no matter how large the key is. Downfalls of the known plaintext attack: 1. Does not work in every situation. The plaintext/ciphertext pairs that are used must be sufficiently different in order to have the highest chance of success. 2. Cannot reproduce the exact plaintext, just XOR's of the plaintext, in most situations.

Brute Force
Since the goal of the known plaintext attack above is to determine enough key bits to eventually be able to determine plaintext from just the ciphertext, a similar approach will be taken for the brute force method. The only way to determine plaintext given only the ciphertext in a brute force manner would be to know the entire key used to encrypt the ciphertext. Thus, our brute force program is provided with a single known plaintext, and its accompanying ciphertext, and tries every possible key until encrypting the plaintext gives the ciphertext. Our brute force attack is very simple, it starts with a key of 0, and checks if the plaintext encrypted with that key is equal to the ciphertext. It continues this in a loop, incrementing the key by one each time, until the key becomes 0 again, by integer overflow. If at any point the plaintext encrypted with the key we are testing is equal to the ciphertext, the attack stops and we have found our key.

This attack will run in

time where

is the key size (in bits). For this bound we can treat the encryptions at

each step as taking constant time

because they don't depend on the key size, only on the message size.

Program Design
Overview
The Akelarre application consists of two class files. The first is called Akelarre.java and the second is called KeyScheduler.java. The Akelarre.java file is responsible for performing the actual encryption and decryption functions. The way it does this is performed in a couple of steps. The first step that has to happen is when an input key is read in from the user, sub-keys need to be created. The key schedule will at that point create encryption subkeys then will convert those sub-keys to decryption sub-keys and return them to the main Akelarre program. After this has occurred if the user wants to encrypt text the encryption function is called with the encryption sub-keys and the operation is performed. If the user wants to do a decryption the decryption keys are passed to the exact same function and the cipher text is returned as plaintext.

The attack program we use to launch our attacks is called AkelarreAttacks.java. It is responsible for all of our timing and benchmarks. The way that it works is by first benchmark how long it takes to compute the random ciphertext and random keys for the number of runs. It will then subtract that from the current time and start performing the benchmarks. It then launches the brute force attack and returns the average amount of time it took to complete each operation. Following the completion of the brute force attack, the bit attack is run.

The bit attack works by using using the equation described in the known plaintext attack description and trying bit by bit to determine what values satisfy the equations. The way we check for the satisfiable is by having a large number of callback functions which implement the TestFunction, TestPlaintext, and getXOR interfaces. The functions then get passed along to the attack function which will iterate through the binary values to determine if the conditions are satisfied.

Inputs and Outputs

Encryption & Decryption
The encryption and decryption application is called Akelarre and is in the Akelarre package. It can be used by entering the following commands on the command line:

Encrypt (random key): $ java Akelarre.Akelarre encrypt 12345678123456781234567812345678 key: AED5DC6C E39DBF3F 96B300F1 903C39A7 output: C61410B9 B3934CC7 A8D03F7F 84044082

Encrypt with key: $ java Akelarre.Akelarre encrypt 12345678123456781234567812345678 1234567812345678

key: output:

12345678 12345678 98EB2000 D212A711 2B263EF0 DC9C1711

Decrypt: $ java Akelarre.Akelarre decrypt 98EB2000D212A7112B263EF0DC9C1711 1234567812345678 key: 12345678 12345678 output: 12345678 12345678 12345678 12345678

Attacks & Benchmarking

The benchmarking application is easy to use and simply takes two arguments. The first argument is the number of runs and the the second argument is the number of bits to use in the key. E.g. java Coconut.AkelarreAttacks <NumRuns> <NumBits> . Attempting to break 100 encrypted texts with 8 bit keys would result in the following:

$ java Coconut.AkelarreAttacks 100 8 Bruteforce Key (8 bits) Total time (ms): 88 Time - Key Gen Time (ms): 84 Time / run (ms): 0.84 Bit Bruteforce (8 bits) Total time (ms): 201 Time - Key Gen Time (ms):199 Time / run (ms): 1.99

Running Time
Benchmarks
For our attack we decided to modify the algorithm so that it used a modified key size. We used 8, 16, and 24 bit variants and we also removed the rotation structure from the algorithm to further weaken it. We then benchmarked our brute force algorithm against our non-brute force algorithm For each key size we ran each test 100 times and took the average running time for each attack. All tests were run on the California lab machine while no other users were logged in and a minimal number of processes were running. The results of our runs are in the following table. [Check out benchmarks and see if we need to do the doubling thing] -Kevin Cheek 11/7/09 7:27 PM Key size (bits) 8 16 24 Non brute force attack (ms) 1.99 4.47 12.65 Brute force attack (ms) .84 29.49 9173.36

The following is a graph of our non-brute force attack versus our brute force attack. The data for the graph is taken from the table above, and the running time is graphed on a logarithmic scale so that the smaller values can be seen, because it increases wexponentially for the brute force attack. As you would expect, our non-brute force attack is substantially faster then brute force for keys of size 16 bits and greater. Since we can find the key for Akelarre in less time than brute force, we have successfully broken the (weakened) cipher in cryptographic terms, and since our attack increases exponentially slower than brute force, based on the benchmark data, we have also broken the (weakened) cipher at least for small key sizes in practical terms.

Variant Comparisons
For the benchmarks above, we weakened the cipher by reducing the key size so that we only used keys of 8, 16, and 24 bits. We did this to allow the brute force attack to complete in a reasonable time, but also because our non-brute force attack is not efficient enough break large key sizes (though it can do better than brute force.) You can see from the table above that as we move to stronger variants of Akelarre (bigger key sizes,) the running time of both the brute force attack and the non brute force attack increase exponentially. For the non brute force attack, the running time goes from approximately 2 to 4 to 12 which follows, roughly, an exponential function (2 to 2 to 2 .) The brute force attack goes from about 1 to 29 to 9000 which follows a much faster growing exponential function (for example roughly 40 to 40 to 40 ).
0 1 2 2 3 1

Brute Force Comparison

The brute force method needs to try all of the 2 possible keys where
n

is the number of bits in the key, but our non

brute force algorithm filters out at each bit, all of the key configurations that do not satisfy our equation (given in our attack description.) Because of this, the non brute force algorithm will always run faster than brute force. Based on the benchmarking data, both the non brute force attack and the brute force attack increase exponentially, but the

non brute force attack increases much slower exponentially than does the brute force attack. You can see from the data in the table that for a key size of 16 bits the non brute force attack has a significant speed advantage, and with a key size of 24 bits the non brute force attack is many times faster in comparison than it is with 16 bits. Because the non brute force attack increases exponentially slower than brute force, it will always be faster. The speed difference between the two will only increase as the key size increases.

Manuals
Developers Manual
Packages and Classes
Our code is written in Java, and is organized into three packages: Akelarre, Coconut, and Test. The Akelarre package includes all of the code to implement the Akelarre algorithm itself. The Coconut package is used for all of our attacks on Akalarre. The Test package is used for JUnit tests of our Akelarre algorithm and our attacks. The Akelarre package contains two classes and they are described hereafter. Akelarre Class This class is contained in the Akelarre.java file and it is the main implementation of the Akelarre algorithm. It also contains various helper functions. The most important functions in this class are Akelarre.encrypt(int[] plaintext) and Akelarre.decrypt(int[] ciphertext). As the names suggest, these functions let you encrypt and decrypt messages according to the Akelarre specification. The constructor for this class lets you make an Akelarre object with a specified key, for example Akelarre a = new Akelarre(key). The default key size and default number of rounds as well as a few other settings are defined as static constants of the Akelarre class, and can be changed to suite your needs. KeyScheduler Class This class is contained in the KeyScheduler.java file and it is the implementation of the key scheduler for the Akelarre algorithm. This class is used by our Akelarre class in order to generate the sub-keys for each round. The most important function in this class is KeyScheduler.schedule(int[] key). This will create the round sub-keys and will return them in an array. The constructor for this class lets you create a KeyScheduler with a specified number of rounds and key size, for example KeyScheduler keyScheduler = new KeyScheduler(numberOfRounds, keySize). The default number of rounds for Akelarre is 4 and the default key size is 128 bits. The Coconut package contains two classes and they are described hereafter. AkelarreAttacks Class This class is contained in the AkelarreAttacks.java file and it is the class that collects all of our attacks and performs benchmarking on them. This class is used to compare each of our attacks in practical terms with benchmarking data, and allow us to see the effect on each attack of varying the key size. The most notable function in this class is the main method which accepts command line parameters and runs the benchmarking based on these parameters. You

can use this method by "java AkelarreAttacks <NumRuns> <KeyMask>" where key mask is simply the number of bits to use for the key. This command will output the average running time over NumRuns runs of each attack on a key size of KeyMask. There are three attacks contained in this class: backtracking, bit brute force, and brute force. The backtracking attack is a failed attempt that is left in for reference purposes only as it cannot successfully break Akelarre. The bit brute force attack is the main non-brute force attack that we use. This is the attack that is benchmarked and graphed in the above sections. The brute force attack is, unsurprisingly, the simple brute force attack that tries every possible key. There are helper functions in this class to run each of our Akelarre attacks. For example, the helper function AkelarreAttacks.bruteforceKeyAttack() will run the brute force attack. BacktrackAttack Class This class is contained in the BacktrackAttack.java file. This is a failed attempt at a non-brute force attack, and we include it for reference purposes only, as it cannot successfully break Akelarre. This class contains all of the functions relevant to our backtrack attack on Akelarre. The main method of this class benchmarks the attack and displays whether or not the key was found successfully and the total running time. This attack works on a satisfiable equation, and tries one bit of every unknown at a time checking to see if that bit will be able to satisfy the equation (taken from one of our papers). As it works through all of the bits, it accumulates all of the possible values that satisfy the equation. The most crucial function in this class is the BacktrackAttack.testWithCarry function that will test to see if a choice of values satisfies the equation. BitAttack Class This class is contained in the BitAttack.java file. This is an implementation of our successful better-than-brute-force attack. This attack works the same in principle as the backtrack attack, except that it excludes the backtracking and carry portion. Like the backtrack attack, this attack works on a satisfiable equation, and tries one bit of every unknown at a time checking to see if that bit will be able to satisfy the equation (taken from one of our papers). As it works through all of the bits, it accumulates all of the possible values that satisfy the equation. This attack is similar in theory as the backtrack attack but it is implemented differently. BruteforceAttack Class This class is contained in the BruteforceAttack.java file. This is a very simple implementation of a brute force attack against Akelarre with one known plaintext to check against. The attack works by starting with a key of 0, and checking if the plaintext encrypted with that key is equal to the ciphertext. It continues this in a loop, incrementing the key by one each time, until the key becomes 0 again by integer overflow. If at any point the plaintext encrypted with the key we are testing is equal to the ciphertext, the attack stops and we have found our key. The important pieces of this class are the constructors, and the BruteforceAttack.attack() function. The constructors take a plaintext and a ciphertext as parameters, and set up the brute force attack. The attack() function actually runs the attack.

AkelarreTest Class This class is contained in the AkelarreTest.java file. It contains the JUnit tests for our implementation of the Akelarre algorithm which can be found in the Akelarre package. It tests encryption, decryption, and various helper functions in from the Akelarre class. AllTests Class This file is contained in the AllTests.java file. It initializes our JUnit test suite with the JUnit framework and kicks off the AkelarreTest test cases.

Compilation
We've created a custom build file called "build" and located in the root directory (at the same level as the Akelarre, Coconut, and Test folders.) This will automatically compile the Akelarre and Coconut packages. The Test package, however, cannot be built by this script because it depends on JUnit to build and run. In all likelihood, you won't need to run the JUnit tests, but if you do you will need to use a separate JUnit environment. To run the build script simply change to its directory (the root level) and run the command "bash build" without the quotation marks.

User Manual
There are only a few functions that our software can perform, and hence, the user interface is very simple. Our program allows you to encrypt or decrypt with our implementation of the Akelarre algorithm, and it allows you to run our attack implementations which includes displaying benchmarking information. To use the following examples you must build the source code by following the steps in the developer's guide above, and you must make sure that you are in the root directory of the project (the same level as the build script and the Akelarre, Coconut, and Test folders.)

Encrypt with Akelarre

To encrypt with Akelarre, the command is as follows: $ java Akelarre.Akelarre encrypt <text> [key] The key is optional for encrypting, but the message text is not. If you do not pass a key, the program will automatically generate a random key and use that instead. When encryption is finished it will print the key and the encrypted message to the command line.

Some examples of encrypting follow. Encrypt (random key): $ java Akelarre.Akelarre encrypt 12345678123456781234567812345678 key: output: AED5DC6C E39DBF3F 96B300F1 903C39A7 C61410B9 B3934CC7 A8D03F7F 84044082

Encrypt with key: $ java Akelarre.Akelarre encrypt 12345678123456781234567812345678 1234567812345678 key: output: 12345678 12345678 98EB2000 D212A711 2B263EF0 DC9C1711

Decrypt with Akelarre

To decrypt with Akelarre, the command is as follows: $ java Akelarre.Akelarre decrypt <text> <key> The key and the message text are both required for decrypting. When decryption is finished it will print the key and the decrypted message to the command line. An example of decrypting follows. Decrypt: $ java Akelarre.Akelarre decrypt 98EB2000D212A7112B263EF0DC9C1711 1234567812345678 key: output: 12345678 12345678 12345678 12345678 12345678 12345678

Attacks & Benchmarks

To run the attacks and benchmarks, the command is as follows: $ java Coconut.AkelarreAttacks <number of times to run> <key size>

The 'number of times to run' parameter tells the program how many times to run each attack. For the benchmark results the program outputs the average running time over all the runs which is much more accurate than if it were only to do a single run. Therefore, the higher 'number of times to run' is, the more stable and accurate the benchmark results are (but it will take longer to complete.) The 'key size' parameter represents the key size in bits to run the attack on. The bigger the key size, the longer the attacks will take. For the brute force attack this is an exponential relationship. An example of attacks and benchmarks follows. Attacks and benchmarks run 100 times with a key size of 8 bits: $ java Coconut.AkelarreAttacks 100 8 Bruteforce Key (8 bits) Total time (ms): 88 Time - Key Gen Time (ms): 84 Time / run (ms): 0.84 Bit Bruteforce (8 bits) Total time (ms): 201 Time - Key Gen Time (ms):199 Time / run (ms): 1.99

What We Learned
Our group learned a large amount during the course of the project. When we were implementing the algorithm we gained a fuller understanding of how everything worked than we otherwise would have. This was because getting the implementation details required reading through numerous papers and trying to interpret what was meant by each. It was a challenge and everyone on the team will at some point have to overcome this challenge in their future careers. During the attack phase we learned a lot about why the authors of the cipher did what they did. It also reinforced the concepts we had previously learned in class and overall made us stronger and more security focused developers.

Future Work
There are a couple of things that our group wanted to accomplish but were unable to given the time constraints of the course. The first thing is that we would have liked to have made the encryption program more useful by adding a mode so that we can encrypt more than individual 128 bit blocks. The second thing that our team would have liked to accomplish is a full strength attack on the cipher. We know from our research papers and the Applied Cryptanalysis book by Mark Stamp that it is possible to get a full strength attack, but with the short amount of time in the course and the difficulty that Mark Stamp himself said was involved in creating a real world attack we were unable to finish it.

Bibliography
Alvarez, Gonzalo, Dolores De la Guia, and Fausto Montoya. "Akelarre: a new Block Cipher Algorithm." Web. De Freitas, D.S., and J.N. "Cryptanalysis of Ake98." Progress in cryptology. Web. Knudsen, Lars, and Vincent Rijmen. "Ciphertext-Only Attack on Akelarre" Cryptologia (2001). Web. Knudsen, Lars, and Vincent Rijmen. "Two rights sometimes make a wrong." Workshop on Selected Areas in Cryptography (SAC'97). Web. Schneier, B., and N. Ferguson. "Cryptanalysis of Akelarre." Workshop on Selected Areas in Cryptography (SAC'97) Workshop Record (1997). Web. Schneier, Bruce. Applied Cryptography Protocols, Algorithms, and Source Code in C, Second Edition. New York: Wiley, 1995. Print. Stamp, Mark, and Richard M. Low. Applied Cryptanalysis Breaking Ciphers in the Real World. New York: WileyIEEE, 2007. Print.