You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.
Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.
And thx for the link Alvaro.
Here's the examples pics i was talking about:
This is the original image
This is the encrypted image using my old code (this is the best i could get before, and the first version was wayyy worst)
And this is the encrypted one using the new algo descripted above
hehe you could see the patern in the old code pretty well, at the time i tough it was fine... until i checked it out this way.
Still pretty good for something home made i guess.