8/12/2019 Cryptography Project
1/27
Cryptography Project4005-705-01
Ken Beck
Kevin Cheek
Jonathan Potter
2009-11-06
8/12/2019 Cryptography Project
2/27
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.......................................................................................................................20B. 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
8/12/2019 Cryptography Project
3/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 cryptographyresearchers. 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 plain-
text 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 270).
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.
8/12/2019 Cryptography Project
4/27
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.
8/12/2019 Cryptography Project
5/27
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 231possible values for the rest. He can then setup the
same equation for k1 and the find these sub-key bits in 232 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 248
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 241 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.
8/12/2019 Cryptography Project
6/27
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 ofvalues do not work, simply perform the attack again with the alternate set of values.
For the purpose of this attack, assume the values for are (1,3). The rest of the attack is apparently based on
the concept of Maximum Likelihood, and involves generating tables for every possible value of , where each
table "contains the distribution of ." These tables contain what are known as theoretical
distributions.
8/12/2019 Cryptography Project
7/27
After these distributions are created, the same thing is performed for and , producing a
table for every possible value of the three K's that contains the distributions of
. 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. Sinceboth 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:
8/12/2019 Cryptography Project
8/27
Known Plaintext Attack
This paper describes a known plaintext attack on Akelarre that works, surprisingly enough, forany key size andany
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 .
8/12/2019 Cryptography Project
9/27
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 and . When you find these, you can then carry out the attack from
the previous section.
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.
8/12/2019 Cryptography Project
10/27
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).
8/12/2019 Cryptography Project
11/27
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.
8/12/2019 Cryptography Project
12/27
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.
8/12/2019 Cryptography Project
13/27
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.
8/12/2019 Cryptography Project
14/27
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 sub-
keys 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 timingand 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.
8/12/2019 Cryptography Project
15/27
8/12/2019 Cryptography Project
16/27
key: 12345678 12345678
output: 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
. 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
8/12/2019 Cryptography Project
17/27
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) Non brute force attack (ms) Brute force attack (ms)
8 1.99 .84
16 4.47 29.49
24 12.65 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.
8/12/2019 Cryptography Project
18/27
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 itcan 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 (21 to
22 to 23.) The brute force attack goes from about 1 to 29 to 9000 which follows a much faster growing exponential
function (for example roughly 400 to 401 to 402).
Brute Force Comparison
The brute force method needs to try all of the 2npossible keys where 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
8/12/2019 Cryptography Project
19/27
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.
8/12/2019 Cryptography Project
20/27
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
8/12/2019 Cryptography Project
21/27
can use this method by "java AkelarreAttacks " 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, andchecking 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.
8/12/2019 Cryptography Project
22/27
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. Ourprogram 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 [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.
8/12/2019 Cryptography Project
23/27
Some examples of encrypting follow.
Encrypt (random key):
$ java Akelarre.Akelarre encrypt 12345678123456781234567812345678
key: AED5DC6C E39DBF3F 96B300F1 903C39A7output: C61410B9 B3934CC7 A8D03F7F 84044082
Encrypt with key:
$ java Akelarre.Akelarre encrypt 12345678123456781234567812345678
1234567812345678
key: 12345678 12345678
output: 98EB2000 D212A711 2B263EF0 DC9C1711
Decrypt with Akelarre
To decrypt with Akelarre, the command is as follows:
$ java Akelarre.Akelarre decrypt
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: 12345678 12345678
output: 12345678 12345678 12345678 12345678
Attacks & Benchmarks
To run the attacks and benchmarks, the command is as follows:
$ java Coconut.AkelarreAttacks
8/12/2019 Cryptography Project
24/27
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
8/12/2019 Cryptography Project
25/27
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 gettingthe 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.
8/12/2019 Cryptography Project
26/27
8/12/2019 Cryptography Project
27/27
Bibliography
lvarez, Gonzalo, Dolores De la Gua, 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: Wiley-
IEEE, 2007. Print.