Google

Sylvain MARTINEZ

martinez@encryptsolutions.com
bugs@bcrypt.com
sylvain.martinez@netcourrier.com
martinez@asi.fr

UNIX Administrator

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
TECHNICAL DOCUMENTATION


Contact Address:
SYLVAIN MARTINEZ
30 RUE GEORGES-BRASSENS
42650 SAINT JEAN BONNEFONDS
FRANCE





ABSTRACT

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 bout cryptography, creating my own cryptography algorithm and creating a Windows 95 cryptography application.

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.


DOCUMENT HISTORY

  • 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



  • ACKNOWLEDGMENTS

    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.




    CHAPTER I
    - BUGS PROJECT -

    I.1 INTRODUCTION

    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 open doors.
    This is only the beginning...

    I.2PROJECT ANALYSIS

    I.2.1 History

    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 through it!

    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
    - Multiplateform
    - Option to make it architecture dependant (if you use 16, 32, 64 or 128 bits integer)
    - 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 [7] 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 [8], 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 database management, 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 memory.
    - 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 of memory!
    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 performance.

    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

    I.3.1 Introduction

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

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

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

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

    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 and 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 block.

    This is maybe confusing (as well as my English) but this is really powerful, indeed:
    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 to 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.

    I.3.3 Conclusion

    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

    I.4.1 Introduction

    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 gen 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 characters needed.
  • 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" string.

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

    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 swapped around.

    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 start.
    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 change it.

    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 key file.

    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 The key 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 [9]. 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

    For example:
    position[5] = 500
    crypta[5] = 232
    cryptb[5] = 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:
  • ROUND
  • BLOCK SHUFFLE
  • 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.
    for example:

    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.

    I.4.3.6 BSSL

    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


    I.4.4 Conclusion

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

    To conclude, here is a summary of the algorithm specifications:

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

    I.5 APPLICATIONS

    I.5.1 Introduction

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

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

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

    Figure 3.8, Screen shot of the Unix application interface.

    I.5.3 WINDOWS 9x/2K/NT Application design

    I.5.3.1 Introduction

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

    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 be generated.

    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 be generated.

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

    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 [10]. 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.


    I.5.4 Conclusion

    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.

    I.6 TESTS

    I.6.1 Introduction

    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

    The 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 areas.

    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 [11].

    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 [15]. 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 [18], 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 [19]. 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. [20]. 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 each contest:

  • CONTEST #2, Based on BUGSv3.x
  • CONTEST #3, Based on BUGSv4.x



  • CHAPTER II
    -CONCLUSION-

    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 computer abilities.

    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.

    II.3 CONCLUSION

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

    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 language used
    - 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 !

    The END.
    Sorry, if you know me well, I should say, to be continued...


    REFERENCES



    [1] Davies D W , Price W L

    Security for Computer Networks, John Wiley & Sons, 1989


    [2] -

    IBM and DES informations, http://www.ibm.com


    [3] -

    RSA informations, http://www.rsa.com


    [4] Diffie W

    Contemporary Cryptology: The Science of Information Integrity, IEEE Press, 1992


    [5] Zimmermann P

    PGP User's Guide, 1992


    [6] Schneier B

    Applied Cryptography, Protocols, Algorithms, and Source Code in C first edition, John Wiley & Sons, 1994, 5-8


    [7] Schneier B

    Applied Cryptography, Protocols, Algorithms, and Source Code in C first edition, John Wiley & Sons, 1994


    [8] Kernighan B W, Ritchie D M

    The C PROGRAMMING LANGUAGE Second edition, Bell Telephone Laboratories, 1988


    [9] Blum M, Micali S

    Advances in Cryptology, Springer-Verlag, 1985


    [10] Deutsch G et al

    Delphi 3, Micro Application, 1997


    [11] Martinez S

    Official project home page, http://www.bcrypt.com

    Company home page, http://www.encryptsolutions.com


    [12] -

    Search engine, http://www.hotbot.com


    [13] -

    Search engine, http://www.altavista.com


    [14] -

    Search engine, http://www.yahoo.co.uk


    [15] -

    Windows shareware and freeware WEB site, BCRYPT application. http://www.winfiles.com/apps/encrypt-file.html


    [16] SUN

    Unix FTP application archives, bugs algorithm. ftp.sunsite.unc.edu/pub/Linux/apps/crypto/


    [17] SUN

    Unix WEB application archives, bugs algorithm.http://www.sunsite.unc.edu/pub/Linux/apps/crypto/


    [18] -

    Cypherpunks mailing list,cypherpunks-request@toaq.com


    [19] CNRS

    Electronic french newspaper LMB,http://www.lmb.cnrs.fr/Webdo.html


    [20] Martinez S

    Personal home page, http://www.asi.fr/~martinez

    Company home page, http://www.encryptsolutionscom