{elysiumsecurity}

BUGS HISTORY - LIBRARY CHANGELOG

Below are the changes history for the BUGS cryptography library

— V 4.1.0 —

26/07/2002: – Added an extra check in misc.c to know what fpos_t
type the system is using. It can be a an integer
with glibc inferior to 2.2 and a structure with glibc superior to 2.2
I have also added an extra header “fpos_t.h”

— V 4.0.0 —

19/11/2000: – mem_seed() and file_seed() do not use the
first cipher key as it can be used by the shuffle
functions.
I was already doing that with the prob_seed fuctions
so there were no reasons why I shouldn’t do the
same with the standard seed functions.
– I’ve corrected the most stupid and annoying bug !!!
I don’t know how, but somehow I must have deleted
a variable initialisation (i=0) in bstream()
just before calling prob_mem_seed() this was giving random
errors as ‘i’ was not initialised !! I’ve spent all
sunday morning + afternoon fixing this problem !!!
do you know a better way of spending a sunday ?
hum… let me think… no ! I can’t see anything
better to do !!!!! grrrrr…

18/11/2000: – Corrected a stupid problem with power = 1
I was using pos_crypt and not pos_crypt_write to
write the cipher data ! This bug was also in v3.x …
This was only happening if you were using a custom
block crypt and power = 1, stupid…

17/11/2000: – Tried all day to change the way I handle the prob_mem_seed
I think I should allow block crypt to be smaller than
the varinit->NB_CHAR
But during my testing I had some segmentation fault :O(

16/11/2000: – It seems there is a problem in prob_mem_seed()

15/11/2000: – Optimised code
– Corrected minor bugs

14/11/2000: – Optimised code
– Removed the “bits” parameter from long_rand() and lfsr()
as it is now in GLOBALVAR: varinit->NB_BITS
– added the SHIFT division used only in bcrypt_swap() to
GLOBALVAR: varinit->NB_SHIFT

13/11/2000: – Finished to clean up the code, it took more than 4 hours
tonight !!!

12/11/2000: – Replaced the circular shift in code() and add() by
long_rand() instead.
– Carried on cleaning up the code.

11/11/2000: – Added bssl()
– Tuning

10/11/2000: – Corrected a bug in brand()
When using varinit->RANDOM = 0 the SEED never changed
and the random number generated was always the same.
I am now using the long_rand() to change the SEED.

09/11/2000: – Added a new parameter to bstream() : PARAM_KEYFILE
you can now sent a keyfile as a parameter for this function
the same way you do with bfile()

08/11/2000: – Updated the ASCII_MODE to v04.
This version will ignore any character different from
0 -> 9
A -> F
This brings a much more robust ASCII MODe, as noe even
if you do a forward of an ASCII encrypted email and
your mail program automatically adds “>” it will
still be possible to uncrypt such a message !
– Created different MASK in bstandard.h to use with
globalvar->MISC in order to enable or not the dynamic
round, modulo swap, shuffle, key buffer.
This algorithm is REALLY dynamic now !!!
PLEASE NOTE that now, to stop the algorithm you need
to do: globalvar->MISC=1; and not anymore =666
– Renamed globalvar->STOP to globalvar->MISC as you can
now specify much more options within this signle variable
– Added a Dynamic Key Buffer options
– Added a new variable to globalvar:
globalvar->KEY_BUFFER
where you can specify the number of KEYS you want to
store in the seed() key buffer.
– Changed the way I was initialising the **pass_buffer in
seed()

07/11/2000: – spent all day trying to compile the library on windows…
it eventually worked at 3am…
I can’t stand windows programming !!!!

06/11/2000: – The new library does not compile on Windows !
(what a surprise)
I spent hours to figure out why…
I think I found the problem.

05/11/2000: – Key dependancy in the seed functions finished !
Now, 32 keys are generated at the beginning of these
functions and stored into a buffer. Then 2 keys will be
pseudo randomly selected from the buffer, XOR, and the
result will be used to seed the file/mem. Then the
key which just have been used will replaced one of the
2 keys used to generate it. Then 2 more keys will be
selected (it can’t be the last key added to the buffer)
to generate a new key, and the process starts again.
That, is powerful :O)

04/11/2000: – Started to program a key dependancy in the seed functions

03/11/2000: – Bits operation affect both bits (Left and Right). Before
I was only doing a logical operation on the “left” bit.
– Dynamic modulo: The modulo for the swap window in
bcrypt_swap() changes in function of the key generated.
– Dynamic number of round: now the number of round can be
100% higher than the number of round sent as a parameter.
By default, round = 2, so the algorithm could double this
value, depending of the key generated. 2 <= round <= 4
If you specify round = 5, then 5 <= round <= 10.
– Renamed the “complexity” variable to “round”

02/11/2000: – Splited up the library code into 6 .c files, it is now much easier to read !

— V 3.5.3 —

24/10/2000: – Added a stop option in the bcrypt_add()
When generating a big key a lot of number are generated
and without this “stop option” you could wait a long time
before the function stops. Now if you set varinit->STOP = 666, the bcrypt_add() will stop.

23/10/2000: – Major change in the ASCII MODE !
I am now using Hexadecimal numbers, the cipher files are
therefore much smaller than before.

– Changed the Keyword in the ASCII MODE.
I am not using the lib_version anymore as this caused
compatibility problem when updating the library.

– Added Error warning in bkey_generator()

— V 3.5.2 —

21/10/2000: – Removed many compilation warnings:
. binit(): random file initialisation
. varinit was never initialised, it was not needed but it
was generating annoying warnings.
. Wrong information displayed in the bcrypt_add()

– Added Error check in bcrypt_read_hide()

— V 3.5.1 —

02/10/2000: – Fixed a Windows compatibility problem with the ASCII mode.
When you send an email with very long lines
(at least with outlook express)
each line is broken up to a certain length and some
hidden characters are added at the end of the line: ‘\par’
I haven’t got a clue why on earth outlook does that !?
It took me some time to find out this problem and it
is now fixed.

– Changed the starting FLAG for the ASCII mode and replaced
spaces by underscores: [BUGS_v351_ASCII_MODE_STARTED]

— V 3.5.0 —

01/10/2000: – Fixed a problem with power=3. I was always working as
if I was using a probability seed ! therefore couldn’t
decrypt any file which were crypted with this power !
This was a stupid bug, but I only did a lot of test with
the maximum power (4). Adding the ASCII mode made me
discover this bug as I had to test all the power level !

– Added an extra option in bfile, this allows you to generate
an ASCII output.
If choice = 2: the crypted result will be converted in
numbers.
If choice = 3: you can decrypt a file which as previsouly
been crypted with choice = 2
I’ve done this option because the crypted result is
by default an unsigned char, you can’t send by email
unsigned char as they are going to be automatically
converted to SIGNED char. Therefore with this ASCII mode
the crypted result will be converted into numbers. You can
send this ASCII result by mail !

— V 3.4.1 —

26/09/2000: – Fixed problem in bfile() where I am doing 2 tests for
closing or not the files used by the library. The test
was ignored and the files were always closed.
This could have potentialy be a problem if the source
file = destination file.

– Removed useless variable initialisation in bstream,
bcrypt_test, bcrypt_add.

— V 3.4.0 —

17/09/2000: – First attempt to do a progression percentage of the
library work. This is really basic and the varinit->PROGRESS
could even be sometimes >100 but at least that should
give you an indication that the library is still
working and is not frozen.

– There is a new parameter in binit(), its a string used
to specify the error log file. If you send an empty string
the error log file will be automatically set to bugslib.log

– I now initialise the varinit->STOP to 0 in binit()

– Added a flag to the library: _LIBCRYPTDLL
this is for windows compatibility.
in libcrypt.h I check if I am using the header to compile
the library (if the _LIBCRYPTDLL flag is defined) or not.
if not the RETURN_TYPE will be (dllimport) rather than
(dllexport). Well… only windows programmer can
understand this !

— V 3.3.2 —

07/09/2000: – Corrected typos when checking if BCRYPTLOG != stderr.
I used Kedit to replace this statement by the new one
and sometimes it repeated the statement 3 times !
It was not really a big problem but not very “clean code”.

– Added Errors check for missing files in write_hide()

– Added ‘\0′ when I was backing up a file on write_hide()
as it could result in a wrong filename otherwise.

– Added Errors check in bkey_gnerator()

— V 3.3.1 —

02/08/2000: – Changed the default TYPE_INT from long to int
this is because on some 64 bits system, long are
64 bits.

— V 3.3.0 —

30/07/2000: #8211; Major change in bstream() to make it compatible with bfile()
bfile() read data from a file and reverse the characters,
for example the following data file “abcd” would be stored
as follow: dcba. This is true with “Little Endian” system
which is the default mode I choosen for BUGS. Therefore
I had to reverse the string sent to bstream() to make it
compatible with bfile(). Why on earth someone has invented
Little and Big endian !?!?!? ;o)

– Minor change in bstream(), cleanup redondant code

— V 3.2.1 —

29/07/2000: – Noticed that there is maybe a difference in the way the
encryption is done between bstream() and bfile()

28/07/2000: – Minor change in bfile(), cleanup redondant code

25/07/2000: – Renamed the BIGENDIAN variable to BCRYPT_ENDIAN as
windows didn’t seem to like this variable name.

– Added extra output information when using -v (mode = 2)

– Added comments

— V 3.2.0 —

20/07/2000: – Found why there was some incompatibility between crypting
on Solaris/SPARC and on Linux/x86. This was an “endian”
problem ! It took me a long time to find out this
problem ! it was because I never heard about this kind of
problem before. It is the way the computer stores data,
if it pushes bytes from the left or from the right.
Thanks to comp.lang.c I have got a small test which
detects if the computer use “Big-endian” or “Little-endian”
I have modified the way I was doing a fread() and fwrite()

– Created 2 new functions: bcrypt_fread_int() and
bcrypt_fwrite_int()
I now call these function instead of the standard fread()
and fwrite() when I store data in integer.

– Minor modification in read_hide() and write_hide() to
be able to use the 2 new function described above.

– Removed the varinit->MAX_INT, I am now using a LOGICAL OR
rather than doing a multiplcation % MAX_INT. Therefore
the algorithm is not compatible with the previous version.
I think it is better this way !

– Added a new variable varinit->PROGRESS which should show
the progress while crypting/decrypting.

– Soon I may be able to sleep early and have a life ;o)

— V 3.1.1 —

19/07/2000: – Corrected an error in meme_seed_prob() when I was storing the
random number in the file. This problem should have raised
some segmentation fault as I was getting items in array at
indexes such as -1,-2,etc. Only in certain condition of
course. Nethertheless, neither Linux,SunOs,Windows reported
this error !!!! amazing…
I found this error by tring to find out why SunOS/Linux
encryption seems to be uncompatible !

– Removed useless information message regarding the
Maximum standard random number

18/07/2000: – Changed output message for the bstream()
as it was reporting the same messages than bfile()
(“Crypting File in progess” instead of “Crypting Stream”)

— V 3.1.0 —

16/07/2000: – Changed some errors messages in bfile
– New parameter in binit for the RNG selector
– Added a seed initialisation for the RNG using
/dev/urandom or /dev/random or time()+clock()
– Added a new parameter in globalvar: STOP
if you set this variable to 666 it will stop the library

15/07/2000: – Improved the buffer in isaac()

14/07/2000: – Added a new funtion brand() which handle the different
RNG functions.
– Added a buffer to isaac()
– Added a new variable in varinit: SEED
which will be used as the initial seed in the RNG

13/07/2000: – Added new random function: isaac()
– Added a new variable to varinit (RANDOM) to choose the
random number generator (RNG) that will be used during
the crypt process

03/07/2000: – Corrected minor errors detected with the Windows C++ compiler
– Added an extra function in order to create a Windows DLL

— V 3.0.0 —

18/05/2000: – Minor change in the errors output
– Added some parameter check regarding the KEYLENGTH

08/05/2000: – Finished to comment and tidy up the code.
This algorithm is ready for testing !!

07/05/2000: – Right… I’ve decided to do not change my algorithm
to be able to crypt/uncrypt the same data with
what ever width int type I was using.
The reason for this is that
1) it would need a lot more work than expected
2) it would make my algorithm weaker than it could
be when using really big int width (64,128, etc)
3) I think that it is, in fact, a good security
option to have a sort of plateform dependance !
In fact, my package is designed first to use 32 bits
integer variables. This would work fine on 32 bits
computer as well as 64, 128 ,etc bits computer !
It just won’t work the same on a 16 bits computer.
(unless you can simulate a 32 bits variable)
I am convinced this is a much better solution !

06/05/2000: – Minor changes in bcrypt_add()

05/05/2000: – Corrected an old bug in bcrypt_add, I was only adding
a numbers to the password when I was in mode=2 which
is the debugging mode… stupid bug !

04/05/2000: – Worked on a new bcrypt_add() to work on 16,32,64 bits

03/05/2000: – The new bcrypt_add() is still not working, I don’t know why!

02/05/2000: – Carried on the “good” work from yesterday, I need to
write a new bcrypt_add(), not only because I have
screwed it up yesterday, but because it is not
working with a multiple palteform system (16,32,64)

01/05/2000: – Well…. I worked on the algorithm just after I came back
from a night club. I may have done more damaged than good !
drinking or programming you have to choose ! ;o)

30/05/2000: – Changed the way I was calculating the biggest integer
I now have a new variable in varinit:
varinit->MAX_INT
which will receive the maximum value for a 16 bits int
The initialisation of this variable is done as usual
with the binit()

29/05/2000: – Corrected the bug in bcrypt_swapp() this was because when
I was calculating the biggest int value I was not
shifting the bits correctly when using 64 bits.
– Even if the algorithm is now working on a 64 bits
computer I realised that what you crypt/uncrypt is
dependant of the length of the int you are using.
This means if you crypt something on a 64 bits computer
you can only uncrypt is on a 64 bits computer.
If you crypt on a 32 bits computer, you can only uncrypt
on a 32 or 64 bits computer, not on a 16 bits computer.
This is due of the way I generate pseudo random
number and the way I add them to an element of the
pass_code[]
This could be seen as a security features, and then a good
point… but I want something “universal” !! which works
on any machines (amiga, PC, sparc… palm pilot ! ;o)
Argh ! I thought my algorithm was finished !!!!
grrrr…. I need to work on it again !
ok… let’s finished it !

28/05/2000: – Located where the 64 bits bug is: bcrypt_swapp()

27/05/2000: – Corrected minor bug in bfile()

26/05/2000: – The algorithm still doesn’t when using int long long
as the default int type (aka 64 bits)

25/05/2000: – Tuning and commenting the algorithm

24/04/2000: – Replaced fclose(BCRYPTLOG) by
if (BCRYPTLOG != stderr) fclose(BCRYPTLOG);
– Minor change in write_passwd()
– bstream() is finished ! as my cryptography algorithm !!
it was the last function to implement…
I now just need to tune my algorithm !
– Removed all %256 I was doing as I think it was useless
– Problem in bstream because I was not using UNSIGNED char

23/04/2000: – Discover a bug in bfile when using the memory method
and the probability seed, I was using tmp_block_crypt
instead of block_crypt when writing a block to a file.
– Major bug corrected: for the last block in bfile,
I wasn’t reseting the length_mem variable to
length_mem = block_crypt/varinit->NB_BYTE
I don’t really understand how this was working anyway !

22/04/2000: – Problem with bfile when using memory and prob_seed
– Discover a problem when doing an fclose(BCRYPTLOG)
when BCRYPTLOG=stderr and you are using the stderr
later in your program. I never done that before
so I never discovered this obvious bug…
I have to decide if in fact I never close the BCRYPTLOG
of if I test if its equal to stderr

21/04/2000: – Minor changes to bstream(), still doesn’t work !

20/04/2000: – Problem with the bstream function:
I was changing the pointer of the string sent in
the parameters to point to a string local to the
library and even if I was seting it as static
it was not working. This was not a good solution anyway !

19/04/2000: – First implementation of the bstream function
– Corrected minor bugs in the way I was setting up the
length_shuffle.
_ Tested on Linux and Solaris, every thing seems to work fine.
There is still a problem on Sparc when I try to use 64 bits
variables. I don’t think this is a big problem, I’ll
work on it later.

18/04/2000: – THAT’S IT !!!! EVERYTHING SEEMS TO WORK FINE !!!
is this the light at the end of the tunnel ?!?
I’ve worked like mad today ! I’ve changed the way I
was handling the block_crypt, it is much simpler now,
I have corrected few other bugs in the bfile function
(due to the fact it was too complicated !)
And I eventually finished the mem_seed function !!
I have done some testing with custom block crypt AND
block shuffle and everything seems to work fine !
It’s so great to crypt something using the Hard-Disk
method and decrypting it using the Memory method…
Well, the great thing is that it … actually works !!
;o))
And the fact I can customise the length of the blocks
I use in different functions is, I think, a little
revolution in cryptography !
I don’t know any algorithm you can customise so
much … in fact my algorithm is the first DYNAMIC
CRYPTOGRAPHY ALGORITHM !!!
Ok, calm down … it’s just working, that’s must be why :O)
well, let’s get some sleep, at last !!!

17/04/2000: – Corrected minor bugs in bfile, still working on the mem_seed
function. I am thinking of changing the way I handle
block_crypt in bfile as I do that in a really complicated
way at the moment…

16/04/2000: – That’s it ! it works now !!!! I found the last bug (hum…)
when I use a probability seed and a shuffle. The problem was
at the shuffle part when I was crypting a file, it was the
part which was re-calculating the length_shuffle in bfile()
This seems to work fine, I tried with different crypt’s block
and even with custum shuffle block !
I still need to convert this file_seed_prob to mem_seed_prob
as this would speed up the crypting process if the user
select the memory option.
I guess I will find new bugs…
Even if, at first, it seems a lot of hassle to do 2 similar
functions but one using only the memory and the other file
access, at least this allow me to find many bugs !

– After looking on the net and on the news to find a way of
reducing the length of a file without using a tempory file
It just seems that’s impossible. I therefore need to keep
using a tempory file. But before I delete it I fill this file
with 0. Thanks to the people from comp.lang.c for their
ideas.

– I think I will have to start again to write comments in my
source code as I’ve been adding so much stuff recently and I
just can’t be bothered to document… it seems I’ve got
more essential stuff to do first ! well… let’s finish
the algo !!

15/04/2000: – Changed the way I was handling the last block of a file in
bfile()

14/04/2000: – Fixed minor problem in the seed_prob()

13/04/2000: – The seed_prob and shuffle works fine ! but doesn’t when I
use a custom block_crypt. I am not happy in fact with
the way I solved the seed_prob and shuffle problem
as I am using a tempory file to fix the problem …
The problem is that if I don’t use a tempory file it
is much more complicated !!! I hate that !! why every
thing that should be simple HAS to be really complicated !?
Anyway, once this is done I’ll just have to convert the
seed_prob to the memory method (as I am using the HD method
now). After that the core engine of the library will be
finished !! (ok, I would also like to add a stream crypt
function, but it should be simple…hum! hum ! ;O)

12/04/2000: – The bcrypt_file_seed_prob() works ! … well… almost !
It works while crypting/uncrypting in power=1(seed_prob only)
It even works when using custom block_crypt ! (that was the
hard bit)
But I still have a problem when I use the seed_prob AND
the shuflle. I don’t think this is a really big problem…
But it’s 3 Am and I am working tomorrow, so I’ll finish it
another day !
– Corrected a bug in bfile when I was initialising length_seed
this would have caused a problem when I use custom block_crypt

11/04/2000: – The new seed_prob function doesn’t work when using custom
block_crypt.

02/04/2000: – Started the first implementation of bcrypt_file_seed_prob()

01/04/2000: – EVERYTHING IS FINISHED !!! THERE ARE NO MORE BUGS !!!
AND I AM GOING TO BED AT 10PM TONIGHT !!!!

31/03/2000: – Fixed a problem while decrypting using shuffle and seed. Now
everything should work fine !
– New function: bcrypt_mem_unshuffle, done in 3 minutes…
as it should be !!!!

30/03/2000: – Fixed problem with bcrypt_mem_shuffle, this was due to the
fact that at the end of a file, the algorithm was trying to
access an element out of the file_mem array.
– MAJOR ADD-ON, I now use the new pass_code generated in
bcrypt_shuffle when I am crypting a new block. Initially
I was always using the same pass_code for every block this
was due to the fact that I first designed this algorithm
without the block_crypt option in mind. Therefore it was a
VERY good thing that I had the previous problem (mem_shuffle)
as my testing to solve it made me discover this potential
security issue. In other words:
Before when crypting ->
start crypt block
generate password P1
seed / shuffle the file using P1
within these functions I generate more password
P2,P3,..,Px
Start crypt new block with P1 … AGAIN !!

NEW method ->
Same as above except that I use Px for every new block I
crypt.
– I start to wonder if I should write so much stuff in this
history, nobody will ever read all this ! and I am sure that
nobody will understand a word ! (I’m not even sure I will be
able if I read this in a week). Maybe I should not do that
at 3 AM … well I should maybe not do it at all !
Who cares !
I’m sure it will make me laught in few years time! ;o)

29/03/2000: – You can now use block_crypt and block_shuffle with
Bcrypt_shuffle. But there is still a problem with
bcrypt_MEM_shuffle : buffer overflow when using very
large block_crypt.

28/03/2000: – Fixed problem when using block_crypt parameter, this was due
to a bug in bfile and file_shuffle.
– Problem when using block_crypt and mem_shuffle.

27/03/2000: – Problem when using block_crypt and file_shuffle.

24/03/2000: – New bcrypt_shuffle_mem function finished
– the block shuffle parameter now has to be a multiple
of varinit->NB_BYTE this is because it would be
be too difficult/long to handle any block shuffle length
while using the memory method.
Indeed, if the varinit->NB_BYTE = 4 and the block_shuffle =21
then to get the data from the file_mem we would need to
to use binary shift. Maybe in the next version…

22/03/2000: – Changed the bcrypt_shuffle_mem function

21/03/2000: – Changed the bcrypt_shuffle_file function to use the new
parameters: block_crypt and block_shuffle

20/03/2000: – MAJOR changes in bcrypt_swap. At last I found the bug
that was randomly make my cryptography library give the wrong
result while decrypting. I was looking for this bug for over
a month now !!! The problem was in bcrypt_swap, I was not
initialising the tempa and tempb variables when I was
doing a logical operation. Because I was however doing the
initialisation when I was doing a swap this bug was function
of the password used to crypt. If the password was such that
first a “swap” was taking place then the variables were
initialised correctly and no bug happened.
Sometimes even if I was starting with a logical operation
there was no problem because the tempa and tempb were equal
to 0. But sometimes there were not. It’s why it was such a
a difficult bug to find as it seemed to be random ! and
never happened at the same time, same place. I first thought
it was a memory allocation problem and I lost a lot of time
tracking this. Well, at last I found the bug !
– New bcrypt_mem_seed function
– You can now specify a block length to crypt.
– Now there are 5 crypt power available:
0 = seed
1 = probability seed
2 = shuffle
3 = seed + shuffle
4 = probability seed + shuffle
– Minor changes in most of the functions. This is the result
of my “BIG BUGS” tracking (see above)

15/03/2000: – MAJOR changes in bcrypt_file_seed
– Minor changes in bcrypt_code
– Minor changes in test_length function.
I do a logical AND to generate new characters rather
than a XOR

14/03/2000: – Changed the bfile function, added 2 new parameters:
block_crypt and block_shuffle
You will now be able to specify if you want to crypt a file
in once or crypt it block by block
Needs to add new functions and change the seed and shuffle
function

03/02/2000: – Implemented the “disk crypt method”. Does not work properly.
Weird error which seems to happen in the file_seed()
when I generate new password ! this cannot be …
Must be a problem with a malloc or memory problem.

02/02/2000: – First attempt to make the “disk crypt method” option works
with the file_shuffle function.
– Changes in bfile(), now I open file_code with the w+b flag

31/01/2000: – Fixed the “2 bytes problem”. Now the last 2 blocks are
crypted at the beginning of the “file shuffle”. The last
2 blocks used to crypt a file’s block are now crypted
as well.
– The crypt/uncrypt file function is now working !!
(only in memory mode for now)

26/01/2000: – Fixed a problem in file_shuffle and file_unshuffle
(= instead of == and length_tab-3 instead of length_tab-1)
The new file shuffle almost work I just have a problem with 2
bytes which are not uncrypted. I think it’s because the
file_mem[] is bigger than the file’s length.

25/01/2000: – The first version of the new file crypt algorithm is working!
I just have a problem with the first 4 bytes when I uncrypt.
– Fixed a “segmentation fault” problem in bcrypt_file_shuffle()

24/01/2000: – The new way I do a malloc for file_mem[] solved the problem
I had on Solaris 2.6 to crypt a file. But it seems there is
a problem when I am using 64 bits variables, I am looking at
it now.

23/01/2000: – Started 2 new functions: file_shuffle and file_unshuffle

22/01/2000: – I renamed bcrypt_write_file() to bcrypt_file_seed()
The file_mem array is now initialised in bfile()
This is because I am going to write another crypt file
function which will also need the file_mem[]
I have also changed the way I do a malloc for file_mem[]
as I think it could have caused a problem.
– Fixed a bug in the crypt file function

20/01/2000: – The library works well on Linux but it has a weird behaviour
on Solaris. I think I found out what was the problem. It was
the new long_rand() function. I have fixed it and everything
seems to work fine.

18/01/2000: – Implemented the memory crypt option in bcrypt_write_file

17/01/2000: – Changed the logs (more useful)
– Changed the bcrypt_write_file function. Added a parameter :
int memory. This is if you want the file to be crypted in
memory rather than directly on the disk (slow).
But you still have the choice in case the file you want to
crypted is so big that you can’t load it all in the memory.

16/01/2000: – Removed 2 variables from the varinit var which were not
used anymore: NB_INDEX_DOUBLE and NB_CHAR_DOUBLE
– Fixed minor bug in the bcrypt_add function
– Added 2 new functions to generate a pseudo random number:
lfsr() and long_rand(). Lfsr() is a Linear Feeback Shift
Register.

09/01/2000: – Removed the library history from the library source
and put it in a seprate file.
– Minor changes in the write_file function.
– Minor changes in the comparison function.
– Changed the Read Key function to do not extract the random
number only from the index 0 of the cipher password.
– Changed the Code function. The circular shift on the random
number depends now of the cipher password and not anymore
of the clear password.
the first random number is added to a position which depends
of the password and not anymore at the index 0.
– MAJOR CHANGE. Changed the swap function. Here are the changes:
Start from left or the right of the bits string depends of the
password
.I alternate SWAP and Logical Operation (LO)
.The first operation (SWAP or LO) depends of the password
.Each new cycle of operation has a different
direction/operation from the previous one.
.A cycle of operation is a succession of SWAP and LO on
each bits of the password
.There is now a “complexity” parameter, this set the
number of series of cycle you want to do (default is 2)
.With a complexity = 2 each bits will be SWAPPED and had a LO
.Increasing the complexity may be more secure but it will
take more time, the choice is yours !
.Changed the way I handle “0”, when a “0” is found I replace
it by mixing 2 characters from the cipher password.
These characters are choosen pseudo-randomly
– Changed the add function. Much more efficient even
if it’s still a small part of my cryptography algorithm.
Now I do a “circular shift” every time I add the number.
– Changed the transcription function. I do not replace
“0” character with the pattern of bit “010101….” anylonger.
Indeed, this could have been a security hole with a
cryptanalyse of the cipher text.

08/01/2000: – Changed the test_length function, better way to generate new
characters, now I mix two pseudo-random characters from the
original “clear password”. I have fixed a bug in my
“insertion” algorithm, in the last for loop “i” was set to 0
when it should have been set to “xy”. This was removing some
orginal character from the “clear password”.It is also
a simpler algorithm.
– Added a new verbose mode: mode = 2, this will give more
debugging information
– Minor change to improve speed
– Added 2 “clean functions”: bclean_string and bclean_typeint
this clean the password from the memory
– After 2 months working on this new algorithm I start
programming again… at last ! Everything is on paper !

— V 2.0.0 —

31/10/1999: – I have just changed the library version which was still set
to 1.8.0

26/07/1999 : – I have tested this library for weeks now, it should be
stable. Therefore I start a new number version for this
library: 2.0.0

09/07/1999 : – Fixed minor error in read_password(). Now if there is
the last user in the password file named toto and
you try to logon as “t” then the function won’t be
confused anymore as I now compare the lenght of the
strings.

— V 1.8.0 —

18/02/1998 : – Made some modification in the swap function.
Now the bilateral swap is more powerful and faster !
– Corrected some minor bugs.

-– V 1.7.3 —-

16/02/1998 : – Corrected minor bugs in binit() function
– Added an option in binit() : mode = 2

15/02/1998 : – Made some modifications to bfile, added a parameter.
Now everything seems to work fine on Windows95, even
even with very large KEY.
– Cleaned the source code.
– Removed some useless log
– Corrected minor error in bkey_generator function.

14/02/1998 : – Made some modifications to several functions to make them
work with Windows95 :
binit(), bkey_generator(), bhide()

13/02/1998 : – Fixed a problem with Windows95 : you can not send in parameter
a string > 255 characters to a DLL !

— V 1.7.2 —

12/02/1998 : – Added the fflush() function after any fprintf
– I added a parameter to binit() : int mode
mode = 0 -> stderr
mode = 1 -> file
– I can now generate some log with Windows95
– Fixed minor bugs

11/02/1998 : – Fixed a BIG bug in test_length function :
Sometimes, with bkey_generator function I could have a
very small input text, 0 or 2 characters …
Because I sometimes had ‘/0′ in the string.
Now I have one more parameter the external functions :
int length, which is the length of the clear password sent
in parameter.
Thanks to that, your cipher password can contain ‘/0′

— V 1.7.1 —

07/02/1998 : – Cleaned the source code
– Changed the write hide algorithm to make it compatible
with Windows 95 DLL.
– Added a new global variable : LIB_VERSION

— V 1.7.0 —

03/02/1998 : – Added bpow function, a power function

29/01/1998 : – Small modification for compibility with Borland C++
Builder on Windows95

28/01/1998 : – Added the backup file in write_hide function

27/01/1998 : – Fixed some bugs in bkey_generator function
– Added a Check for 0 value in swap and code functions
– Added write_key_file and read_key_file functions
– Added write_hide and read_hide functions
– Added delete_passwd function

26/01/1998 : – Added the bkey_generator function, use it to generate long
key. (key = clear text that will be use to do a passwd)
You can initialise the key generation with a random
number or with 8 characters.

— V 1.6.3 —

20/01/1998 : – Fixed a bug in the bcrypt write function, when I had to
write at the end of a file some data, which the length was
inferior to varinit->NB_CHAR.

19/01/1998 : – Problem with a variable global : USER_LENGTH, I added it to
varinit, I had some problem with this variable and with
malloc
– Problem in write_passwd function, variable utilisation (pos)

17/01/1998 : – Minor problem in test passwd function, I used a type,
and I had a problem with that on Windows95, hum, hum …

–- V 1.6.2 —

16/01/1998 : – Resolved a bug in the probability crypt function
Problem with an array’s border :
j = 0 when it was suppose to be j = 1

15/01/1998 : – Minor changes to make my library works on a Silicon Graphics

14/01/1998 : – Resolved the problem with bpass parameter : passwd
when I wanted to use my DLL on Windows 95
(who said windows95 = error ??? ;o)
Now, I do not have a TYPE_INT type anymore,
So it is the program that call this library that
has to reserve memory for the passwd variable (malloc)
Maybe a bit less easy to use, but more compatible …

13/01/1998 : – Added Windows 95 DLL’s compatibility
with #if defined(__WIN32__)
– I also removed my global variables because it was a problem
when I tried to use my library on Windows95
so I have now a pointer in parameter of each function :
varinit, and a new type : globalvar

12/01/1998 : – write_passd and read_passwd functions:
windows 95 problem’s compatibility with typedef => resolved

11/01/1998 : – Bugs corrections in bfile and bcrypt_write_file_prob
Problem of aray initialisation and variable init :
pass_key and code_key
– Removed all extra functions (bcrypt_vol,etc)
– Started to do an HISTORY