VER 1.4 Revision II

JhashD takes a password, and padds each character between 8 randomly generated letters (modifiable in the source code),
each (randomly generated letter) of which is then randomly moved up a random ammount of times between 20 and the ascii
value of the current character being processed (and the length of the password (added in 1.1) ). The series of
random numbers generated is based on the ascii value of the first character encountered (added in 1.2, because both
"toad" and "doad" had the same hash). 1.3 doesn't make use of what 1.2 did. Instead, the series of random numbers is
based on the length of the password. 1.4 Blows everything out of the water by adding up all the ascii values of the
password, then generating a random set from there.

Another thing to take note of is that the random letters (based off of the srand(AsciiCount) function) themselves
are increased between 20 and the ascii value of the current character plus the length of the password, according
to another random variable (NumTimes variable).

1.2 didn't meet my standards, because based on the length (and the repetitiveness of the same letter) all of the
same letters had the same hash. The reason why it wasn't that secure (Vulnerabilities show, kind of like the 1.0
version) was because you could figure out a pattern with each hash. The reason for this (Yes, it is my fault!) was
because I was generating a new series of random letters with the ascii value of the current character. If the letter
"e" was passed through twice, they would have the same hash.

I tried a remedy earlier today (8/12/07) by allowing a new set of random letters by the ascii value of the current
character plus an incrementing variable that would increment everytime. It would create the hash just fine, but the brute
forcer would only brute force the password if it was between 1 to 2 characters long. I have no idea why, but I fixed it
now. Currently it doesn't generate a new series every pass through the hash function, but the srand() function takes the
length of the password, so as the password gets longer, the hash becomes that much harder to recognize.

NEAR MAXIMUM SECURITY (version 1.4): This version of JhashD totals up the ascii values of the current password, then
generates a new series of random numbers based on this total.

UPDATE 1.4: The password is hashed upper-case, so it is not case sensitive. If you entered "prAgmA" as a password, first
it would all be upper-cased, to "PRAGMA" then the ascii values are computed, then the generation of random letters takes
place from the ascii values of the upper-cased letters.

UPDATE 1.4 Revision I and II: The statement NumTimes was initially set with a value of 20 + rand() % int(charact).
Looking towards the end of the hash function, it was missing in one area, and in the other it was 1 + rand() %
int(charact). I have added the missing one, and corrected the other one. So, you get even more security.

As of right now, the hashed letter is padded on the left with 3 random letters, and padded on the right by 5 random
letters.

The character between the padded letters is itself moved up through the alphabet between 1 and it's ascii value plus
length of the password. This is changed between each letter.

Then, the resulting character hash is sent to a pointer array. This happens until the characters have all been processed.
Then the array is copied into a string, which is the resulting hash.

For example: the word "example" would have a hash of

YNXPALFGC IBPYDCAHK EGRIQYFET XJMUQCYWM SVCIHRAJS WKELNCMQP HRRSVSUAM

(This was the hash in version 1.0, without adding the length of the password)


SHRVUPLEI SLZBNRPXO LNYWXBYRD OADBHSOMI JMTXYUWAK MAUZDWEAX JTTJXFSEU

(this is the 1.1 hash of "example". Each character is padded with random letters not only based on the ascii equivalent
of the current character, but with the length of the password)


Now, with version 1.2, the hash would look like this:

KYRXMQQXF GVWLWBHBI FDLARDSQS QKROPYWJQ GPUSYQLLR XPJPZIDLE KYRXMQQXF

(1.2 wasn't that secure (even still), as you can still see that both "e"s (one at the beginning, and the one at the end)
have the same hash. I now have the program generate a new random set based on an incrementing static variable. The result
is this 1.3 hash below:

KYRXMQQXF XOUFCALJV TVVIAWYJC HQVZZNJSK EDTWEVSJO UEWKBEUKY XFCMCBWII

(this was the old 1.3 hash, but I could not run a brute force on it. I have changed methods since)


This is the new 1.3 hash:

VGLUCFPCP MRHOIFUXS NRTKFDSEK YQJOVZJDQ MTBQFKVHW CTTETYTEJ YPSSMOCPR


ver 1.4: after totalling up the sum of the ascii values, a new set of random numbers is generated based on the sum total
of values. This is the new 1.4 hash:

QAVLOTONN WEXFLOAWB RVBVFMTBS GGZPFRVRY TGUYCCZMR JEQEODHXH JDVBGMOFZ


UPDATE 1.4: the variable NumTimes = 1 + rand() % int(charact) should have been NumTimes = 20 + rand() % int(charact), so
it had to be updated yet again. This time it is a revision to the current update. The following hash is the 1.4 revision
I hash:

NDKJHWAHB UOWYTQZPF VEDJUMTFM YVORXRBGY EAKOLVTDI LBDCGALEW IGFLRZXQC

UPDATE 1.4 Revision II: A missing NumTimes = 20 + rand() % int(charact) was added back in. The new hash is as follows:

NHWJARQAH GWIZZJVVT IYWRBKKTC XPQKYYYEF GFQRYAMEC ZVRQZIIKZ MXLZRZDIS


Each hashed letter is separated by a space (for illustration, although the spaces don't show up in the real hash, except
if the hash containts spaces, which are shown)

With the added feature of the 1.1 version, the first character's hash will be different as the length of the password
gets longer. For example:

This is the hash of e:
QFPJSDFSQ


this is the hash of ee:
ODNPQLFGC IBPXDFTBK (notice how the first character hash is different)

With the 1.0 version, this is what the same hash would be

e:
YNXPALFGC

ee:
YNXPALFGC EXLFZDLTC


with the 1.4 version, you won't even be able to tell if a password of the same length has just one letter changed. For
example: Consider the hashes of "dummy", "dummx", "dumny", and "dunny"

dummy: NUJULTSYAXQDLXYQHECLRDEMNVNSAXPOCHQMCYOWJDESJ

dummx: FOXGGHRIKQRKSMUECDQJYNKADUSBKVACHJZILBTXVKPDC

dumny: IJJIBGAUYHZMMCWGBJMYBUTOWCQIKHHSSZXJGSNEUURRO

dunny: DWKNFVCTRXSVFCYCADEWQSMOFFQJBLEPOAFTXMEMEBNQV


UPDATE 1.1: The random letters are not only based off of the ascii value of the current character, but as well as the
length of the password.

UPDATE 1.2: For some reason, the passwords "toad" and "doad" along with the letters of the same length (D and T) had the
same hashes. To fix this, I had the hash algorithm generate a new random set of numbers, base on the ascii value of the
first character it encounters, so the odds that two passes would have the same hashes are reduced on a large scale, if
not indefinitely.

UPDATE 1.3: The hash algorithm has changed quite a ways from 1.0, and unlike 1.2, generates a new series of random
numbers based on the length of the password.

UPDATE 1.4: Before the password is generated, the sum total of each character's ascii value is made. Then a new series of
random numbers can be made.