Cryptography Project

8/12/2019 Cryptography Project

1/27

Cryptography Project4005-705-01

Ken Beck

Kevin Cheek

Jonathan Potter

2009-11-06


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


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.


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.


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.


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.


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/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 .


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.


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).


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.


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.


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.


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.


15/27


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



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.


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


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.


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


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.


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.


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


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


Bit Bruteforce (8 bits)

Total time (ms): 201

Time - Key Gen Time (ms):199



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.


26/27


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.

Date post:	03-Jun-2018
Category:	Documents
Upload:	rajwec
View:	227 times
Download:	1 times

Cryptography Project

Documents