Document Version 4.0 (19/11/2000)
Document based on my BSc Project in Computer Science at TEESSIDE (UK, March 1998)
BUGS DYNAMIC CRYPTOGRAPHY ALGORITHM
30 RUE GEORGES-BRASSENS
42650 SAINT JEAN BONNEFONDS
This document is part of the BUGS Cryptography project documentation.
It is based on the report of my final year project in Computer Science at the
University of TEESSIDE (UK) which consisted of finding information a
cryptography, creating my own cryptography algorithm and creating a Windows 95
This project started as a personal project back in 1995, became my Bsc
project in 1998. In 2000, I have created a new algorithm based on the original one.
BUGS is now a personal project again.
Each chapter's contents is divided into several parts which should help the
reader to easily find what he is looking for. Most of the chapters and sections
have an introduction to help their understanding and to give a quick overview
of their content.
As a background in cryptography is needed to evaluate the work done, the
introduction to cryptography document should help the reader to appreciate the work done
in this BUGS cryptography project.
The reader does not require any special computer skills to understand this
report, but a previous knowledge of computer programming would be helpful.
Finally, a lot of people asked me: "Why creating another Symetric Cryptography Algorithm" especially
since AES is now available. This project is an amateur one, it is Open Source, free, for developpers and
it is not just a cryptography library but also a suit of cryptography softwares. I do not pretend to
have created something better than DES, AES, nor whatever_ES but just something I hope is secure enough to
protect personal data. The security level of this algorithm is currently being tested on the Internet,
and the feedback is very good so far.
V 4.0: Update of the documentation with the new features and contest of BUGS v4.0.0
V 3.0: This version corrects many grammar mistakes and there is more information about how the algorithm works. References Links have been updated
I would like to thanks Trevor Tippins and Simon Huot who highlighted many weaknesses in my
previous algorithm and then pushed me to improve it. I would especially like to
thank Joanne ELLIS who corrected the first version of this report in 1998. I
would like to thanks the University of TEESSIDE to let me do the previous
version of this algorithm as my Bsc project. The GNU, Linux and KDE team who
provide a lot of free development software. All the people around the world
who tested my applications and sent me feedback emails. My parents who support
me in my choices. My Brother Florent for the different BUGS logos. Finally my
other brother Thierry Martinez, 16 years old, who pushed me to get into the cryptography world
in 1995 by asking a simple question: "Do you cryptography is something difficult ?" and always
pushed me to do my best by being unusually good at computing at his age.
- BUGS PROJECT -
The object of this project is to make a free and
easy to use cryptography algorithm. This is to give programmers an easy way
to use strong cryptography functions/library in their own application.
It should also be designed in a portability focus, in other words, it should compile
on every kind of hardwareor operating system.
The strength of the algorithm has to meet high standard and even if I haven't
the pretension of creating something as strong as a military algorithm, it
should be really near this "security level".
The keywords are then:
Security, Efficiency, Portability, Open Source and Easy.
This project has been one of my
first interests since 1995. Even if I stopped working on it for some times (never
more than 6 months in the last 5 years) I have been working constantly on it.
This is really time and "gray matter" consuming ! With the latest version, in
2000, I have been working on it for more than 10 months, every day. I am not
sure I'll do it again, not soon anyway! I think this project has reached its
maturity, even if I am sure I will carry on debugging it and maybe including
new small features, I don't think I am going to re-write a brand new algorithm.
Unless someone "easily" breaks this algorithm.
This project is not the end of my work in computer security, I have done it to
This is only the beginning...
This project is
especially interesting for me because cryptography has been one of my main
interests since 1995. In 1996, at the French University I started to get
information and make a cryptography algorithm but my professors stopped me.
This is because French cryptography laws are really strict and everybody is
afraid about a science considered like a second-class weapon by the government!
When I came to England for my studies, I had the chance to take this project as my
final year BSc project. This has been a success. Despite the fact that because
of it I didn't really spend much times on my other studies it was worth it! The
last month exams were a bit of a nightmare, but somehow, I managed to get
I am nowworking full-time, and from November 1999 to September 2000 (10 months)
I have been working every night on
this new algorithm. It has been really tiring and stressful but I knew I had
to do it because this new version was much better than the old one. I think
this new algorithm can compete with many existing ones, and even if it is maybe
not the strongest one (time will tell us), it has some interesting new features
that no other one has or at least not all of them in a single algorithm:
- Dynamic algorithm
- Option to make it architecture dependant (if you use 16, 32, 64 or 128 bits
- 2 different way to make the algorithm works: direct access to the disk (slow
but not a lot of memory needed) or memory cache access (quick but needs loads
of memory when crypting very big files)
- Strong key generator
This project has also been really useful to me about: learning different languages,
using different operating systems. It was done in a really professional way
because of the fact that the programming was very strict and the graphical user
interface was designed over a long period of time. This included looking at a
lot of professional project specifications from books, in the LINUX operating
system and in the GNU association which both provide very important project
source codes and specifications.
I.2.2 The analysis
I decided to make an algorithm on my own. This is
why I spent a lot of time thinking about the problems of making a secure
algorithm. This was very useful, because understanding the existing algorithms
were made easier after. Actually I found by myself most of the existing
principles, and that is the best way to understand them. Of course, I did not
find a lot of the complex mathematical formulas, but most of the principal
cryptography rules and functions.
People could argue that there is no point of
"reinventing the wheel" and that one person alone can't compete with
a team of professional working full time on a cryptography algorithm. I agree
with that. However, this project just started as a hobby. Because now the algorithm
I've created seems to be better than first expected 5 years ago I have decided
to put more effort into it. Yes, it is like a challenge for me. I want to
create a strong, free and easy to use cryptography library.
I searched for some information about cryptography
and read a lot of documentation. I tried to understand how the main cryptography
algorithms worked and I looked for all the problems that they had. Nearly all
the information has been found in the excellent book of Bruce Schneier 
which is the reference book for everybody interested in cryptography. I also
found a lot of documentation on the Internet.
When I made my algorithm I always tried to avoid
the weak points that could break its security by trying to break all the new
functions that were implemented. Therefore I started to imagine a perfect
algorithm without thinking of the programming problems. When I finished the
algorithm specifications, I implemented it in a C application on a LINUX
operating system, I then spoke to a lot of people about this algorithm and kept
improving it over many months. For the previous algorithm version, Dr Oswald from
the university of Teesside gave me a lot of ideas for improvement. For the new
version, Trevor Tippins gave me some good reasons to improve the existing algorithm
I chose to first do a LINUX C application because
it was the language I was the most familiar with. Even if I first did a Windows
version using DELPHI, I am now using C++ Builder.
The advantages of this solution are enormous:
The main part is in C. As this language is the most
commonly used in computing, I can compile my application on all existing
operating systems, thus on any kind of computer.
I did the main part of it on LINUX in C, I did a
Windows 9X/2000 adaptation by using C++ Builder. Therefore I had to be able to
use all these different environments.
As my application can be used on different operating
systems, I can really be sure that there is no problem, indeed, some errors may
not be detected on some operating systems that are not strict (e.g. sharing the
memory) or with some compilers that are less strict than others.
Because the application should run on different
operating systems, the source code has been made as generic as possible. This
means that it should not need any
modifications to be compiled on any operating
system. The reason for this choice is easier and quicker application
maintenance. Thus the main work could be on the content of the algorithm and
not on the portability part.
I have also tried to look at everything that has
been done in cryptography and all the available applications. I realised that
there were not a lot of applications and none of them were easy to use or were
too old to be really secure. The project application therefore became an
application that could be very useful for everybody who wanted to use
cryptography. I have done my specifications by thinking about all a users
possible requirements, I asked a lot of people about what they would like to
find in this kind of application. I also looked at all the enquiries about this
subject on the Internet.
I.2.3 Work done
I have made my own cryptography algorithm. I found some logical operations that
are not used in other algorithms. The algorithm is dynamic, i.e. the user can change
the way it behaves just by changing some parameters.
The C implementation of this algorithm has been
very difficult especially because I always had to think about using my C code on
another machine. This is why I had to respect all the specifications of the
ANSI C , which is the universal C standard. I also created my algorithm in a
C library rather than a whole C application and I have done all the sample
applications separately. As a result to this it has been easier to adapt my
algorithm to other systems because the main part of it, aka the C library, was
the same. I have created a full package that works on all UNIX systems, but
there is no graphical user interface for this version yet. The library itself
contains about 7600 lines of C code, which is quite a lot for a single
algorithm. The Unix package consists of a password generator with a password
a login sample application, and a crypt file application.
I have done two different algorithms for the last application; the new one uses
random numbers to crypt and is therefore more powerful. My application could
easily replace the Unix standard login and is much more powerful, I wrote a
help file for each function (see Appendix B,
Developer Help Functions) and explained in detail all my algorithm
specifications. The more people that understand it the more sure I will be that
my algorithm is powerful.
One of the most difficult part of the new
algorithm was to handle 2 different ways the algorithm could work:
- Using direct disk access with a small memory buffer:
This is useful if you want to crypt really big files and haven't got a lot of
- Using memory buffer only:
You load the whole file into memory. This provides a really fast crypting rate
but you could run out of memory if you crypt really big files.
I could only have done the memory method as if you are going to crypt a 1 Gig
file you must have a really powerful computer and therefore you could have 1 Gig
But I was thinking about portability, I will eventually port the application on
Palm devices, and there isn't a difference between memory/hardisk.
Also, I wanted to let the user crypt any kind of files even on a really old
computer. This has been useful as I managed to find a lot of different bugs
because I had to achieve to same result using 2 different methods. On one hand
I was using memory arrays with memory access optimisation (such as really large
integer which allows me to store many characters in one integer) and on the
other hand a disk block access in a virtual disk array.
Then, I compiled the library on Windows
9x/2000/NT and created a standard windows application that uses all the
features contain in this cryptography library. In the previous version I've
also done an enhanced version using non-standard graphical functions, I have
decided to drop this enhanced version in the new algorithm. Basically for time
reason and also because I think other programmers could do it by using my
cryptography algorithm. The Windows 9x/2000/NT library has been done in a way
that any application should be able to access thecryptography functions,
it could be DELPHI, VISUAL BASIC, BORLAND C++, WORD,etc.
I had a lot of problem caused by the fact that I
used 3 different compilers and languages (GCC, Solaris CC, C++ Builder), and 4
different operating systems (SunOS, Silicon graphics, LINUX, Windows 2K/NT) to do
the application and the tests.
I.2.4 Main problems
As the cryptography algorithm source code has been designed to be compile
on any kind of operating system without any modification and with any C compiler,
the programming part has been very difficult: A windows C compiler can use different
functions than a Unix compiler. The same problem can happen between two Unix C compilers,
(e.g., Unix SunOS C compiler and Linux C compiler). This is why some standard functions had
to be rewritten to be portable on any kind of Operating System. It was maybe more difficult than
doing just a Windows application, but doing that increased my knowledge in a
lot of different areas, this was really interesting and exciting, even if it
was sometimes really tiring! But I am convinced it was worth it.
Three main problems have been encountered. First
it was sometimes difficult to find a solution to all the way the algorithm
could have been "broken". For an amount of time spent on security
improvement part, twice of this time has been spent trying to find a weak
point, with always the same idea in mind: doing an algorithm as strong and
secure as it could be. As the algorithm and applications tests will take place
on the Internet, it was really important to provide a strong algorithm that
will not be broken in a very short time and could then beyond attack its
The other main problem was directly dependent of
the Windows environment, this operating system has the reputation to be full of
"bugs", and it is unfortunately true. A lot of time the application
development has been slown down by an unknown and illogical problem of
compilation or execution. An extra execution monitor had to be done to identify
these Windows problems.
The last problem was the time, as I am working
full time and this project is just a "hobby". Part of that was also the fact
I decided to have 2 different way of running the algorithm (Disk or Memory access).
Despite the fact this improve the protability part of the algorithm it has been really
time consuming. This allowed me to find and correct a lot of bugs as if 2 implementations
of the same algorithm are really different and they give the same result you can be pretty certain
the algorithm is good.
I.3 ALGORITHM ANALYSIS
The perfect cryptography algorithm should resists
to attacks even if the attackers know how it works, so the algorithm should be
like a one-way function, you can crypt but not decrypt. That could seem useless
to create a cryptography application if you cannot decrypt your messages after,
but first we will consider that our application is only used to create cipher
passwords. A cipher password does not need to be decrypted,
to know if you typed the right clear password you just have to compare the two
cipher passwords, the one that has just been generated with the one stored in
the password database (As explained in II.4.2 Login
A good cipher password generator is really useful
and crucial in cryptography because to crypt a file you use cipher passwords
that are usually called keys in this kind of application. This is why at
the beginning of this project, the main task was to build a really strong key
Another crucial point in cryptography is that the
keys must not give away any information about how they have been generated. That
means if you generate a key from the following password "abcd", if
your key is "1234" you can first deduce that the password had 4
letters, and then easily found that 1 = a, 2 = b, etc. So a better key would
have been something like "*##1g%$6fd" because you cannot deduce the
length or the nature of the password. A good cryptography algorithm can be
resumed to the fact that the more possible solutions corresponding to the key
generated there are, slower will be the analysis and then the way to
"break" the algorithm. If there is only 100 passwords to try to find
a key, then a computer can do that really quickly. If there are billions of
billions possibilities then it will be much more difficult. Indeed, if to
generate a key a computer needs 1 seconds, to generate 100 keys the computer
will only need 100 seconds, but if there are billions of billions keys to generate
the computer will need billions of billions of seconds to do it.
I.3.2 The cryptography algorithm
I.3.2.1 The key generator
The key generator is not based on a
"static" mathematical function (e.g. k = x + 1), but on the password
itself. That means the way a key is generated is function of the password used.
Thanks to that, it is not possible to easily create other mathematical
functions to decrypt a key (e.g. x = k - 1). The reason why no
"static" mathematical functions have been used is because many
existing cryptography algorithm are based on mathematics (e.g. RSA with
factorial) and then create an algorithm based on logic was more original and
was a different approach of the actual state of cryptography.
A new feature not present yet in any other cryptography algorithm is that the
BUGS cryptography algorithm is a dynamic algorithm. This means you can change
the way the algorithm operates just by changing its parameters.
Even if the same password is used to generate the
key, the key is always different, like that an attacker cannot constitute a
"key dictionary" by just generate all the keys possible and then
compare his dictionary with the key he wants to break. Another important point
is that the key generated does not give any information about the password
With the new algorithm you can now even specify
the key generation's round you want to use. With a higher round the
algorithm will operate many more operations. The BUGS v 4.0.0 introduces a
dynamic key poll giving dependacy to the previous key when a new key is
I.3.2.2 Crypt a file
To crypt a file, We've got different powerslevels:
- Power 0: Seed the file (one pad seed)
We use a "mask" that will be added to the file by an EXCLUSIIE OR
(XOR), it is a binary operation that respect the following rules 1 XOR 0 = 1, 1
XOR 1 = 0 and 0 XOR 0 = 0. The reason of using this binary operation is because
if you apply the mask again, in fact y
ou remove it, Figure
3.1 shows this process.
- Power 1: Seed the file using a random number
This is really similar to the previous power level but here I will use what
I called a "Random method", I am going to use a random number
when I create a "mask", this random number will then be crypted and
inserted in a pseudo random position in the cipher text. This is a better way
of crypting as if you crypt the same text with the same password, the cipher
text will always be different.
- Power 2: Shuffle
I take the cipher text and mix 2 pseudo random file's blocks together,
store this "mask" and use it by doing a XOR with another pseudo
random file's block. When a block is crypted it cannot be used to generate a
"mask". I make sure that 2 same blocks won't be use more than once to
generate a "mask" and that all the file's block will be crypted this
way, except f
or 2 blocks, as when I mix 2 blocks I don't use the mask generated
to crypt one of the block used. This is why the last 2 blocks have to be
crypted by only doing a seed.
I guess this is the weak point of this method, an attacker should then try to
find these last 2 blocks used to create a "mask". But they would have
to crack the one pad seed and even with the 2 clear text blocks the attacker
wouldn't know which logical operation has been used to generate the mask and
where it has been used.
To make this method efficient, at least 2/3 of the file should have a mask
added to it.
- Power 3: Shuffle and seed
Regarding the potential last security issue, there is this power level.
Because here decrypting the last 2 blocks used to generate the mask would be
much more difficult as a 2 pad seed has been used!
- Power 4: Shuffle and Random seed
This is the most powerful level, using random number to generate the seed
doing a shuffle. This is the one used by default
On the top of that, the user can dynamically configure the way the algorithm
operates by using 2 parameters:
- Crypt's block:
You can specify the length of the block you want to use to crypt the file.
This means that if you use the Power level 4 with a Crypt's block equal to 128
then the algorithm will work with the first 128 bytes of the file, seed and
shuffle it, then starts again with the next 128 bytes.
If you are not using a custom crypt's block you crypt the file as only one
This is maybe confusing (as well as my English) but this is really powerful,
For example, when I seed a file using a 512 bits key length I take 512 bits
block at a pseudo random position within in the whole file. If I use a custom
crypt's block then the algorithm will work only within the size of the custom
crypt's block and then start again with the next custom crypt's block. This
tally change the algorithm is operating!
The only restriction to this is that the crypt's block has to be at least as
big as the key length being used to crypt the file.
- Shuffle's block:
When doing a shuffle, by default the length of the block used to generate a
mask is the length of the type of int you are using (called TYPE_INT), which is
4 bytes on a Linux PC system. You can change this to whatever length you want
as long as it is a multiple of TYPE_INT.
Again, by changing this parameter you change the way the algorithm will work.
With BUGS, To crack a cipher text, not only you need to know which
cryptography algorithm someone have been using but you also need to know which
method has been used (power level) and what was the value of the parameters
(default or custom crypt and shuffle's blocks.)
Figure 3.1 EXCLUSIVE OR operation.
This cryptography algorithm has been created with
gradual goals, the first goal was to generate a key from a password, i.e., to
crypt a small string length of text. When this was done and its security
tested, a way to use this function to crypt a file, i.e., really long text, was
found by using of a seed and a shuffle function. Then I have introduced the
dynamical options of the algorithm (by allowing the use of parameters).
Choosing to use gradual goals was very useful, because in this way each part of
the algorithm could be studied and improved. When you have to resolve a really
difficult problem, it is better to split it up and then find a solution as it
makes it easier to understand.
I.4 ALGORITHM CONCEPTION
The algorithm created for this project is called BUGS
for Big and Useful Great Security, it is a private
key block cipher algorithm. This algorithm is composed of a key generator that
is used in the crypt file function. The algorithm has been created in the C
language, first on the Linux operating system. It is a library, this means that
any application can access the cryptography functions. This part of the report
is the most difficult to understand. This is why the explanations are not
deeply detailed. For more detailed explanations please look at the source code
of the BUGS library.
I.4.2 Key generator
The key lengths that are generated are powers of
two (e.g. 2^x, 128 bits, 256, 512, 1024, etc). To generate a key there are two different
methods: randomly or pseudo-randomly. For the random method, 16 random
characters are generated and stored in the memory. For the pseudo-random
method, the user is asked to type some characters that are then stored in the
memory, the maximum number of characters that can be entered is 16. 16
characters correspond to a key length of 128 bits, this is because one
character is represented by 8 bits on a computer, therefore 16 characters
represent 128 bits (16 * 8 = 128), 32 characters represent 256 bits (32 * 8 =
256) and so on. Then several functions are used to generate a key, using these
characters which are stored in the memory like a password, this string of
characters is called: "pass_clear".
The number of different combinations is higher with the Random method (2**128)
than with the Pseudo-Random method (72**16 i.e. approximately 2**99). This is
because the user has to type some characters and there are only around 72
symbols readily available on a standard keyboard. If only unshifted alphanumeric
is used then the round falls to around 2**83 combinations.
I.4.2.1 Test length function
It is important that the key's length is always
the same, so if the length of the "pass_clear" string is inferior to
the key's length, some characters are then added to the string. The number of
characters the user has to type must be at least half the number of characters
in the key. Each new added characters is the result of an AND logical operation
between two characters randomly picked up in the "pass_clear" string
of characters. Now, if the key to be generated is 128 bits (which correspond to
16 characters) the new "pass_clear" length is 16 characters.
When generating a key of more than 128 bits,
first a 128 bit key length is generated and used to generate a 256 bit key
length, and so on. This is possible because the first key has got the minimum
number of characters required to generate the following key (128 bits = 16
characters, 256 bits = 32 characters, 512 bits = 64 characters, etc). The key
erated then becomes the password for the following key. Illustrated by Figure 3.2, the different steps during a 512 bits key
length generation are:
1- The user types 16 characters as a password.
2- If less than 16 characters are typed, some new characters are generated to reach the 16
3- A key (A1) of 128 bits is generated from the password typed at the step 1.
4- The key (A1) is used to generate another key.
5- The key (A2) of 256 bits is then generated from the Key (A1).
6- Because the key (A1) is twice inferior to the key (A2), the same process
used at the step 2 has to be done, but this time, we check if there are at least 32
characters (256 bits) in (A1).
7- The key (A2) is used to generate another key.
8- We repeat the same process that happenned at the step 6 but this time with (A2).
9- The final key (A3) is a 512 key length.
Figure 3.2, Long key generation process.
I.4.2.2 Transcription function
The string of character "pass_clear" is
converted into a string of numbers called "pass_code", these numbers
are the ASCII code of each character contained in the "pass_clear"
I.4.2.3 Additional function
It is better not to directly manipulate the ASCII
code contained in the "pass_code" string. This is why a number will
be added to each number contained in this string by an Exclusive OR operation.
This number is generated in function of the password itself. To make it safer,
each time the number is added it is different I do this by using a circular bit
I.4.2.4 Swapping function
This is the main part of the algorithm, all the
numbers contained in the "pass_code" string are considered to be only
one long string of bits. First, the bits are swapped with each other, each swap
takes place between two bits that have a distance of X bits.
The cipher password is a long string of integer,
each integer of this string will be assigned to X. Because while doing this bit swapping
processs the cipher password will be consistantely changing so will the string of integer
and therefore the value of X. X should never have the same value.
The swap starts from the bit B1 at the position 0 with the bit at the position B1 + X1.
After, from the bit B2 at the end of the string with the bit at the position B2 - X2.
This continues with the second bit of the string B3 and the bit B3 + X3, and
with the next to last bit B4 with the bit B4 - X4,
and so on. In fact, as shown in Figure 3.3, the
following rule is respected:
Swap bit I with bit I + X1
Swap bit 'endofstring' - I with bit
'endofstring' - X2
This starts again with I = I + 1 and a different
X from the "swap_length" array.
Figure 3.3, Bits swapping process.
This is called bilateral bit swapping, with this function all the bits will be
The second part of this swapping function is the
same process, but this time instead of swapping bits around, a pseudo-random
binary operation, function of the password itself, will be generated. There are 5
different types of binary operations: Exclusive OR, NAND, NOR, OR, AND.
The way the new algorithm works is that it alternates a swap and a logical
operation each time.
The algorithm do this in a loop until all the bits have been used (in a swap or
a logical operation), you can change the "round" of this loop with a
parameter, it is the number of loop you want the algorithm to perform.
By default it is 2 (which is also the minimum) as with this value we are sure that
ALL the bits have been used in a swap AND a logical operation.
By changing the value of the round you are changing the result generated!!
Also, in function of the password itself the algorithm will:
- Starts from the right or the left of the bits string
- Starts by a swap or a logical operation
When this is finished there is a new
"pass_code" string, which contain numbers totally different from the
Before when I was detecting a 0 in the KEY's array I was replacing it by mixing different
element of the KEY. Now if one of the element of the KEY's array is equal to 0 I do not
I.4.2.5 Coding function
To make this crypt algorithm more efficient, a
final part has been created.
A random number is added to each number of the "pass_code" string.
This random number is initialised at the beginning of the function. Each time
this random number is added, its bits are shifted to the left, the value of this
shift is a number generated in function of the character contained in the
"pass_clear" string. Therefore,
each time the random number is added, it is different. Thanks to this random
number, even if you type the same password to generate the key, you can have
2^31 different keys (if I use a long random number = 4 bytes = 32 bits).
The random number will be hidden in the key at a
position that will depend on the cipher string, because when a user types his
password again we need to recover it. The key generation will then follow the
same process as the first time it was done. To recover this random number, if
the password is right the algorithm will know its position. Otherwise, the
position will be wrong as will the random number used in the coding function
and the key generated will be different.
You can choose 2 ways to generate a random
number: using the standard C function or use the ISAAC algorithm created by Bob
Jenkins. The default RNG is ISAAC. The initial seed will be initialised by the
/dev/random or /dev/urandom device if present on your system, otherwise it
would be the result of “time() + clock()”. I am aware that the second method
hasn’t got a big entropy for the pool of numbers, therefore you can overwrite
the seed value in your application really easily (for example: after your
binit() call just add the line: varinit->SEED = 666, to set the SEED to 666).
I.4.3 Crypt file
The crypt algorithm provides two methods to crypt files:
Crypting a file from a password typed by the user that will be
transformed into a key, or from a key that has already been generated with the
Key generator function, described in I.4.2, Key
generator. If you want to use a very long key length, such as 2048
bits, as it is not really possible to remember a long password, you will have to
generate a key and store it in a secure area, this key will become your
password. You can also choose to crypt a file without a password or a key
generated with the key generator function. You can simply choose an existing
file, and the key will be some of the data contained in this file (most of the time in the
middle of the file). This could be really useful if you do not want to store a
There are 5 different power levels to crypt a file.
I.4.3.1 Seed function
First, a "file array" is defined, if you use a 12
8 bit key length, the algorithm will calculate how many blocks of
128 bits there are in the file that is going to be crypted. The "file
array" will have as many indexes as there are blocks of 128 bits in the
file. Each block will match one of the indexes of the "file array".
There are only two values that can be found in this array, '0' when the block
has not already been crypted, and '1' when the block has been crypted.
There is a new feature in BUGS 4.0.0:
Many keys will be generated and stored in a buffer. By default, 16 keys are generated.
Then the 2 keys will be pseudo randomly selected, mixed together
will be used as a filter by doing a Exclusive OR between the data contained in
the file and the key. The position of the block file's data (where the filter
will be added) is in function of the "pass_clear" string. This is why
when you crypt a file the blocks sequence and the blocks length that is going
to be crypted depends on the password used to crypt the file. Each time a
filter is added, the "file array" is updated to be sure that a filter
will not be added twice at the same position.
When a filter is used, a new key is generated as
shown in Figure 3.4, Crypt file key generation .
As a result, the key used as a filter is always different and always in
function of the previous key that has been generated.
To decrypt a file, because a Exclusive OR has
been used to crypt the file, you simply crypt the cipher file with the same
password again to remove the filters.
Something important is that when the keys are
generated it is not possible to add a random number, as described in
I.4.2.5 Coding function, because it is not
possible to find it again, once the key has been added to some data.
It is why with this algorithm, with one password,
or key, you only have one cipher text.
Figure 3.4, Crypt file key generation.
I.4.3.2 Random Seed function
The idea was to be able to have more than one cipher
text when the same clear text was crypted with the same password . This can
be achieved by using a random number in the key generation process. This algorithm
is nearly the same as the standard one, but this time ONE random number is
generated and crypted using the same password used to crypt the clear text.
It is then inserted in the cipher text, still at a position function of
the "pass_clear" string. After, this random number is used in the key
generation. Therefore, with this algorithm for ONE password and ONE clear text
there are MANY cipher texts.
To decrypt the cipher text, the random number is
extracted from the cipher text first and the cipher text is crypted again with
the password typed by the user and this random number. If it is the right
password, the right random number will be extracted, the right keys will be
then generated and the algorithm will generate the right clear text.
This algorithm is much stronger than the standard
one, indeed if someone tries to decrypt a cipher file, he will never be sure
that he has found the right clear file.
I.4.3.3 Shuffle function
As for the file_seed function I divide the file
into blocks (by default block's length = Default integer width = 4 bytes on Linux)
From the last cipher password generated I am going to extract pseudo-random
numbers to find 3 files locations:
- position to crypt (pos_crypt) (I always start with the last block, see below)
- position A used in the crypting process (posa)
- position B used in the crypting process (posb)
I take the blocks at the position A and B and I do a logical operation between
them (in function of the cipher password): OR, NOR, NAND.
I then add the result (MASK) with an Exclusive OR to the block at the position pos_crypt.
Then, one of the blocks used to crypt (A or B) will become the new position to crypt.
The choice between A and B is done by checking if the position that has just been crypted (pos_crypt)
is an odd number or not. If it is then the new crypt position will be pos A otherwise it
will be pos B.
I do this to prevent 2 blocks to be used together more than once to crypt an other block!!
I end up with 2 blocks uncrypted (well, in fact they've been "seeded"
before!) so I generate 2 new cipher passwords from the one sent as a parameter
to this function and I add them to the block with an Exclusive OR.
I also start this function by crypting the last block of the file this is
because of the way I divide the file into blocks:
if the key's length is 128 bits and the file's length is 260 bits then I have got
3 blocks of of 128 bits, but the last block only have 4 bits from the file. If
I was using this block in the "shuffle" process this would be weak.
Therefore I don't use it and I crypt it at the start of this function.
The way I decide which block is going to be crypted and which blocks are going
to be used to generate the MASK is function of the password itself. I use the
value of the password (A) in a LINEAR FEEDBACK SHIFT REGISTER FUNCTION (LFSR). This
enables the algorithm to generate many different numbers (B) from (A). An LFSR
is really useful to generate a sequence of pseudo random numbers that are
always the same if generated from the same initial number.
This function has been taken from the excellent book from Bruce Schneier
Applied cryptography Second Edition. I have just changed it a bit, in order to
do not initialise the function from a static variable. Instead, I initialise
the LFSR with the password itself. I also use a different primitive polynomial
modulo 2 in function of the length of the "shift register" you are
using (16, 32 or 64 bits).
This part is really important as the file is then crypted with its own content.
If I use the seed and shuffle function to crypt a file, to decrypt I first need
to "unshuffle" and then "unseed" the crypted file.
I.4.3.4 UNShuffle function
I first do the same think as in the file shuffle function except that I do not
make any changes on the file at first. I store the different crypt positions
and blocks that are used to create the masks.
I then have 3 arrays:
position = position of the block which will be crypted
crypta, cryptb = position of the 2 blocks used to create the mask
position = 500
crypta = 232
cryptb = 1300
This mean that the 6th block to be crypted was the block number 500 using the blocks
232 and 1300 to generate the mask !
When I have filled up these 3 arrays, I then decrypt the last 2 blocks and I
start from the end of the array to the beginning to un-shuffle the file .
You can compare that to a "cards castle" once you've done your castle
if you want to remove the cards without breaking the castle you need to take
out the last card (on the top) and then the next one, etc in a reverse order.
I.4.3.5 Dynamic Variables
This is one of the main new feature of BUGS 4.0.0
The following variables:
BUFFER KEY (used in the seed function,
and tells the algorithm how many keys must be stored in the buffer)
MODULO SWAP (which is used in the swap functions and tells the
algorithm how big or small can the bits swap process be
These variables can be set to be dynamic or not (default = yes).
If set to dynamic, the algorithm will change their value in fonction of the
password entered. The minimum value is the default value entered
for these parameters, and the maximum is double the default value.
if ROUND = 2, then with the dynamic option ROUND could be a value
between 2 and 4. If ROUND was equal to 10, then it could be a
value between 10 and 20.
The MODULO SWAP changes at each round.
All the others Dynamic variables changes at each block you crypt.
By default you crypt a file as one big block, so these values will
change only once.
This is a new feature in BUGS 4.0.0 and stands for:
Bugs Security Sandard Level
The BSSL lets you choose easily different preset values for all
the different parameters in BUGS.
Click here to see the current BSSL available
The main problem in this algorithm conception was
that it was necessary to always have in mind the following words: security,
efficiency and portability. Everything has been done to respect these keywords, the
source code is well documented and well formatted, and should therefore be easy
To conclude, here is a summary of the algorithm
- Private key algorithm.
- The source code can be public without making
the algorithm weak.
- Dynamic Algorithm
- Pseudo Random numbers generated using a Linear
Feedback Shift Register and ISAAC algorithm
- Direct disk access or Memory buffer method in order to run on low spec computer and Palm devices
- Stream encryption option
- Block encryption option
- Key generator: Bits manipulations, bilateral
bits swapping and logical bits operations, random generator.
- Crypt file (using the key generator): Variable
length cipher block algorithm.
- 5 Power levels: Seed, Random Seed,
Shuffle, Seed + Shuffle, Random Seed + Shuffle.
- Key length unlimited (as big as your integer
type can take).
To demonstrate the use of the project
cryptography algorithm, some applications have been created. These applications
except for the crypt's file ones should be taken as example only. The reason
for this is that I did not test them as much as the crypt's file applications.
I.5.2 UNIX Applications design
The applications using the cryptography algorithm
created for the project were first created for UNIX (such as Linux, SunOS,
Silicon Graphics, HPUX, etc.). The reasons for this choice were because this
system is the most used in the computer world. Also, because no graphical user
interface needed to be created, these applications could be created faster
These applications have been created using the C language.
They all use a library which contains all the cryptography functions
created for this project and only consist of a user interface for the use of
this library. Particular attention has been given to the error check in these
applications. Even if they are badly used, an understandable error message is displayed.
There are 6 different applications:
Bcrypt: Crypt/Decrypt file application.
This application, which is illustrated by Figure 3.5, is used to crypt or decrypt a file. Some
parameters have to be set by the user which are the password, the file to
crypt/decrypt, the destination file, the length of the key, the crypting power
method, the round of the key generator used. The user can even specify a
custom crypt's block length and a custom shuffle's block length. There is also an interactive
mode where the application is prompting you for each parameter required. This is a security enhancement
if you don't want someone doing a 'ps' looking at your parameters
Bchat: Secure chat, similar to the 'talk' UNIX
This application can be used to have a secure
conversation other a network (Internet for instance). It uses a stream
encryption method. It is still an early beta version that should be used
carefully, however it is stable. I may create a better version in the futur.
This application also offers an interactive mode.
Bkey: Key generator application.
This application, which is illustrated by Figure 3.6, is used to generate a key which will be
stored in a file. Some parameters have to be set by the user which are the
password or the random generation flag, the destination file and the key length
to be generated.
Blogin: Login application similar to the
existing one on the Unix system.
This application, which is illustrated
by Figure 3.7, is used when a user wants to log onto the
system. Parameters must be set by the user such as his password and the
location of the password database which contains his cipher password.
Bpass: Password management application.
This application is quite similar to the Bkey
application but the key generated is stored into a password database with the
user login name. Some parameters have to be set by the user which are the user
name and his new password. If the user already has a cipher password stored
into the password database, he will have to re-type his old password to be able
to change it with the new one.
Bhide: Hide/Extract engine application.
This application is used to hide a file in
another file or to extract a previously hidden file. You can choose to hide a
file at the beginning or at the end of another file. This is a completely
separate part of the cryptography called steganography. It would have been too
long to create a strong steganography algorithm so this is why it is only a
simple algorithm (Added to the beginning or at the end of a file). This part
was done, because even if the algorithm is simple, it could be useful. This is
because, with this algorithm, if you hide a file into a picture, video or sound
file, it becomes invisible. As it is only a small part of this project, it will
not be developed further.
Figure 3.5, Bcrypt application design.
Figure 3.6, Bkey application design.
Figure 3.7, Blogin application design.
These applications are provided with an
installation utility and a lot of documentation and comments in their source
The user can have a look at the applications
source code and modify them if he wants to implement additional functions However,
a lot of time has been taken over these applications so no changes should be
needed. Figure 3.8 is a screen shot of the Unix
Figure 3.8, Screen shot of the Unix
I.5.3 WINDOWS 9x/2K/NT Application design
I used in the past "Delphi 3" to
develop my Windows application, Noe I have decided to create the new
applications using Borland C++ Builder.
I.5.3.2 Application design
The cryptography library has been compiled on Windows using the Borland C compiler.
A lot of compatibility options have been respected and only few changes needed to
be made. Therefore, no problems occurred with the library Windows adaptation.
Although in the Unix version there were 6 different applications created,
in the Windows version only one application was created containing most of the features
provided in the different Unix applications.
The Windows application uses the library functions by calling them as
"external functions". This means it is like if the functions
contained in the library were part of the application. The difference however
is that these functions are only loaded onto the computer memory when they are
The windows application is multitask. This means
that even when an action is being performed (crypting, generating a key, etc)
the user still has access to the other actions provided in the application.
A log file can be generated, while the application is running, and tell you
all the different step done by the application. This is useful in order
to find a "bug" or to check what is has actually been done, Figure 3.9 is a sample of the log that could
The application is divided into 3 different parts:
INFORMATION: this part displays all the
information regarding the application. The action that has been chosen
(Crypt/decrypt, generate a key, hide/extract data), the key's length, the power
level used, the minimum and maximum length of the
password required and whether or not a log file is going to
ACTION, illustrated by Figure
3.10: This is the main part of the application. You can choose the
action to be done, to crypt or decrypt a file, to generate a key or to hide or
extract data. Two extra options which are not using the cryptography
library are also provided. The first one allows the user to display the
contents of a file, for example a text file. He can then check if a file has
really been crypted. The user can also display a picture if he wants to check
if hiding data did not damage or modify a picture. The other choice is a
small text editor that can be used to quickly and easily create a text file. As
a result of these options everything is provided in the application. The user
does not need to use another application to create a text file he wants to
crypt, to display a picture or to check what the application has done. The
parameters that have to be set for each action are the same as those used in
the Unix applications.
From this main part of the application you can also access the options and information
LOG: this part gives real time information on
what the application is doing, and provides useful and understandable error
information. This way the user is constantly helped to use the application.
The arrangement of the different items on the screen
have been thought carefully. The information part are
on the left as the common way to read text is from left to right. The action
and main part is in the centre, and the log part is on the right. Figure 3.11 shows the application design.
Documentation has been created and included in the application package to
explain how to use this application.
Figure 3.9, Log file sample.
Figure 3.10, The action design.
Figure 3.11, The application design.
I.5.3.3 Main problems
The windows application was quite difficult to create because I never used Borland C++ Builder.
Even if the code editor is pretty good, the documentation is not. And lot of time has been spent
on the internet, web site, news group to find answers. In the past, when I was developing the
Windows application in Delphi 3 I used some books . However this time I didn't use any as
the Internet resources were really good.
I.5.3.4 Graphical User Interfaces
For this new version I have only created a standard interface. In the the previous version I
also created an "enhanced" version and used a function written by Andreas Heckel found on the
Internet. This was not really easy to use but provided features like transparent
and free style windows. To explain how the enhanced version was created would
take too long and it is only an extra part of this project, it is not
necessary as I have decided to stop developping it.
The standard application available on Windows has been carefully tought and tested, it provides almost all
the features that can be found in the Unix Package and also fully compatible with the UNIX cryptography library.
The Windows version was not really my main goal as I am more interested in developping a cryptography algorithm rather
than a full suit of software. I did it for 2 reasons: to learn windows programmation and to show the public it was
easy to use the BUGS library on any kind of OS, Unix, but also Windows.
Different steps were undertaken in order to test
the quality of the algorithm and the applications, personal tests, multiple
operating system tests, friends' tests and Internet tests. These tests were
really important to create high quality, professional applications.
I.6.2 Personal tests
First, each new cryptography function implemented
was tested carefully to try to generate all possible errors, even those
previously not thought possible. For these tests, the log file that can be
generated to describe everything done in the algorithm was very useful as it
was possible to "trace" the running process.
I.6.3 Multiple Operating System tests
project applications were tested on many different operating systems (OS):
Windows 9x, Windows NT, Unix (Linux, HPUX, Silicon Graphics, and Solaris).
Because each operating system is different (memory management, permission rights,
variable management, etc) these tests were very important. For example, a
problem regarding the way the password was stored in the memory happened once.
No errors were generated when the application was running on Linux,
but on the Silicon graphics OS an error was generated. This was because on
Linux the memory management is less strict than on Silicon Graphics (or at least at the time
on the Linux OS there were not as many users as there were on SGI). Therefore,
sometimes the application worked fine on the Silicon graphics and Windows but
not on the SunOS because these first two OS were more compliant in certain
These tests were really long and difficult to do
but also useful to create a really strong and professional application and to
remove many "bugs".
I.6.4 Friends tests
When the previous step was done, this application
was tested by a lot of friends. This was useful as it not possible for one
person to guess everything that a user could do, even the most simple.
Working in a computer science environment I manged to have this algorithm tested
by many professional, most of them only had basic cryptography knowledge but some
of them were experienced in this field.
I.6.5 Internet tests
After the previous tests, the quality of the
algorithm and the different applications were stronger. The tests could then
take place over the Internet. If a lot of time passed before starting these
tests on the Internet this was for a good reason. If a lot of bugs were still
present in the application or in the algorithm conception, this project could
have then lost credibility and stopped people testing it. On the Internet, it
is not just 4 or 5 people that could test an application, it could be hundreds.
This is why a good documentation has been written, the application source code
modified and checked to respect all the standard rules of programming and
professional attention has been given to the different packages which were
going to be publicly available on the internet.
A Web site has been designed and created at where
a summary of the specification and the different applications can be found
When everything was available on the Internet,
different Internet search engine sites were contacted [12,13,14] and the
Official BUGS project web site indexed in those Internet search engines.
This means that each time someone searches for cryptography on the Internet he
will find the BUGS Web Site.
The applications have also been put on two other
Internet sites. The first one is the biggest shareware/freeware Internet WEB
site . The second one is the biggest Unix application FTP site [16,17]. The
fact that the project applications have been accepted on the FTP site is proof
of quality as this site is the SUN company Internet site (one of the
most important computer company). Now, the project applications will be
available on CD-ROM, indeed, the free operating system LINUX is always
available on CD-ROM with a copy of the SUN ftp site. Moreover, the SUN ftp site
is not only located at one place, but thousands of mirrors of it can be found
all over the Internet. The project applications are stored on the SUN Internet
site at a location where only two other programs can be found: PGP and MD5
(which is another cryptography standard, for the Internet).
Also, some emails have been posted on different
newsgroups and mailing lists. The most important mailing list where information
has been posted is the cypherpunks mailing list , however only the previous version
of the algorithm has been announced on this mailing list as it seems this mailing list
does not exist anymore. This is a private mailing list where only people with strong
knowledge or interest about cryptography are participating.
The project specifications have also been sent to a French computer
newspaper which also publishes an electronic version . This electronic version
consists of a fortnightly review of computer world events sent by email to more than 10 000
people. In the newspaper fortnight number 102 (26 March 1998) and in the new
edition number 39 (June 2000), an article about my project was written by a
journalist. The next day I had 200 visits more to my home page.
On the 19th of October 2000, after 4 months the new algorithm has been published on the internet
about 5000 People went to the web site and about 2000 Downloaded the BUGS applications and algorithm.
. I found some
interesting addresses from the project applications that have been downloaded :
navy.mil, .ibm.com, .bt.com, nasa.gov, pentagon, etc. I received
many email from all over the workd (German, American, English, French, Russian, Spanish, etc)
telling me that they were interested in my applications and were testing them.
Because the project applications are present on famous Internet sites, many
other people may have taken them but I have no access to these statistics.
After 4 months, no problems have been found in my applications and nobody has
yet succeeded in breaking my new cryptography algorithm, the tests continue.
I.6.6 Cryptography Contest
There are 2 contests about BUGS.
Each of the contest offers 50 English pounds to the winner.
To test the strenght of this algorithm, I've decided to run a contest.
Because this is a free software and I created it during my free time,
I can't offer a lot of money. However I hope that this will push more
people to try to crack my algorithm.
As I am very confident about the strengh of the BUGS v4.0.0,
I give away much more information for the contest #3.
Both contests will be running for a year. Here are the information for
CONTEST #2, Based on BUGSv3.x
CONTEST #3, Based on BUGSv4.x
II.1 PROJECT CONCLUSION
This project has been really interesting for me
and I spent a lot of time on it. Seeing now that everything is finished and my
work starts to be recognised by many people is something fulfilling. I have realised how
useful the Internet could be for finding information and people who have the
same interest as you, even in a very restricted area. Moreover this project has
given me a lot of knowledge and strictness. I feel more confident in my
This is the second time that I have started a
project by thinking that all the specification problems have a solution. I really
think it is worth it, because you then have to give your best. You also have to
be careful to not undervalue the difficulty of a project, specify what you want
to do and know what you can do is something important.
Even if this project is finished, I will continue
to provide support to the applications and the BUGS algorithm. I have
realised how much computer security interests me and companies (Hewlett/Packard
France, Motorola, etc) have already contacted me. This project is therefore a
springboard for my professional career.
II.2 PERSONAL BENEFITS
II.2.1 The technical skills
During this project I became really confident in
the use of DELPHI 3, C++ Builder and of the language C, as the applications
that have been created in these languages are quite complex. I have also improved
my skills in graphical user interface design and am now able to run an important
project in a Windows environment. Most importantly I have increased my knowledge of
cryptography (protocols, algorithms, laws, possible applications). It was
necessary to understand complex mathematical formulas as the mathematical
aspect was quite difficult. I also had to find a lot of documentation in order
to understand the cryptography algorithms like DES, RSA and more recently AES.
However, mathematics is something I need to increase my knowledge in if I want
to continue in cryptography. As the applications have to work on many different
operating systems I had to become familiar with them. I have never worked on a Silicon
Graphics computer before for instance.
II.2.2 The personal skills
This project really showed me how involved I
could get in a project that really interested me. I realised that I could get
maybe too involved with it!
I also realised that cryptography represents
different way of thinking. Indeed, if you ask someone how he would create a
cryptography algorithm he may have a totally different approach to the problem
than someone else. Cryptography allows you to demonstrate your own logical way
of looking at things. Finally, in this project I learnt to manage a very
important project, to plan it and respect this plan and to know what I was and
was not able to do.
Since I have started this project, back in 1995,
a lot of things have changed. This project became a University project and
since people found some weaknesses in the original algorithm I have worked again
really hard to create a new stronger version. This has been my biggest project
ever, I have been working on it nearly every day for 10 months, for more
information take a look at the Appendix C, Library
I don't know if I will work again so hard on this algorithm, I think I have
made my point: being able to create a strong cryptography library and showing I
am not too bad at programming.
- I have learnt a lot in this project with all the different OS and programming
- I have been stressed in this project when I was not really sleeping for days
and only thinking about the problems I had to resolve.
- I have been depressed in this project when after 4 months of hard work there
were still so much to do, so many problems to resolve, so many think I wanted
to add, so much more sleep I should take!
- I have been helped in this project when I received some emails of support
from the Internet and pushed me to carry on!
- I have been happy in this project when everything was working fine, as
expected, when I first snoop a network transmission of bchat, and everything
was encrypted. Also when I eventually try to use customised crypt's and shuffle
block and things worked as planned!!
In fact, it's sees I didn't have much of a life for the last 10 months! it was worth
it, now let's finished this document and take some holidays !
Sorry, if you know me well, I should say, to be continued...
 Davies D W , Price W L
Security for Computer Networks, John Wiley
& Sons, 1989
IBM and DES informations, http://www.ibm.com
RSA informations, http://www.rsa.com
 Diffie W
Contemporary Cryptology: The Science of
Information Integrity, IEEE Press, 1992
 Zimmermann P
PGP User's Guide, 1992
 Schneier B
Applied Cryptography, Protocols, Algorithms,
and Source Code in C first edition, John Wiley & Sons, 1994, 5-8
 Schneier B
Applied Cryptography, Protocols, Algorithms,
and Source Code in C first edition, John Wiley & Sons, 1994
 Kernighan B W, Ritchie D M
The C PROGRAMMING LANGUAGE Second edition,
Bell Telephone Laboratories, 1988
 Blum M, Micali S
Advances in Cryptology, Springer-Verlag,
 Deutsch G et al
Delphi 3, Micro Application, 1997
 Martinez S
Official project home page, http://www.bcrypt.com
Company home page, http://www.encryptsolutions.com
Search engine, http://www.hotbot.com
Search engine, http://www.altavista.com
Search engine, http://www.yahoo.co.uk
Windows shareware and freeware WEB site, BCRYPT
Unix FTP application archives, bugs
Unix WEB application archives, bugs
Cypherpunks mailing list,firstname.lastname@example.org
Electronic french newspaper LMB,http://www.lmb.cnrs.fr/Webdo.html
 Martinez S
Personal home page, http://www.asi.fr/~martinez
Company home page, http://www.encryptsolutionscom