my encryption algorithm. But is it secure?

I have devised an encryption algorithm, basically it goes like this:
The key is taken and SHA-1 hashed. this creates a 40 key long string.
this string is stored in an array with one character in each variable of the array. the first 40 characters of the message are stored in another array by the same method. each character in each variable of the array which was th e key is converted into it's ascii number using key(i) = asc(key(i)) and this is done to the first 40 text characters too.
the first character of the text and the first character of the hashed key are taken and their ascii numbers are added to get the ascii number of the first character of the encrypted text, this is similar to a one time pad. to prevent overflowing, the number goes back round to 0 if it gets above 255. e.g. 250 + 23 = 18. to decrypt you simply take away the key from the text.
this is done with the second character and the third and so on until the 40th, and then we have no more key characters left. so what we do is SHA-1 hash the key again! so basically we are SHA-1 hashing the SHA-1 hash of the key
and then we use the new 40 characters it gives us. when it gets to 80 we then SHA-1 hash the key again, so we are SHA-1 hashing the SHA-1 hash of the SHA-1 hash of the key :) and repeat this until we get to the end of the message.
I'm wondering whether this is secure though because we are basically using the same key over and over but just SHA-1 hashing it every time.

It probably was somewhat secure, until you posted it.

I suppose. But "the man" could decompile it anyway.
i still think it will be quite secure as they will have to brute force the first 40 key chars with the first 40 text chars to get the message. or will they? does this method have anything that makes it weak and easily crackable?

Echelon thanks you for your posting. Your encryption/decryption has been logged for future reference.

-_- ?

I would guess there's some small leak of information if you do what you propose, but probably not that much. Assuming you can generate a pseudo-random hash which reveals little to no information about the input string (I'm assuming SHA-1 fulfills this role), there are very few connections between segments of the message for information to combine and eliminate possible input keys.

At least, I haven't been able to think of a way to break it in the last few minutes :)


Why don't you use a more popular algorithm, though, instead of one of your own design?

I think things are only secure until someone cracks it and that seems to happen always. Encrption is like a lock on a door, it keeps honest people honest but if someone really wants to get in, a good lock wont stop everyone because they can break the door off the hinge

My 2 cents...

First of all, I'd reccomend using a different hashing algorithm, since the SHA1 has a collision problem (meaning there is a possibility that 2 different values will produce the same hash), which reduces security from 80 bits to approximately 69 bits. Also, adding e.g. one to the value of the previous hash will dramatically change the next hash, making it less obvious to anyone that you are rehashing the hash itself.

Second of all, suppose I feed a stream of empty bytes to your algorithm (empty in the sense of being &H00, comprised only of zeroes). This will almost instantly reveal your key's hash, which will enable me to reveal the entire message in a couple of seconds (the addition of 1 to the hash would slow me down for some time, but not prevent me from breaking it).

Finally, if you have a look at the linearity of simple addition, you will easily conclude that it is not too complex to break, given that the encryption of each byte only depends on one variable, which is the byte of the key. Perhaps a logical XOR would be preferable, since it is not that obvious (well not at first glance anyway). This is my reccomendation to you, instead of addition, put XOR, which would only require a minute portion of the code be changed.

A word of advice:
There is no such thing as an unbreakable or secure encryption. If the one trying to break it has enough resources and spare time at their disposal, the code will inevitably be broken. So one can only design an algorithm which is secure enough for a particular purpose. But the definition of that crucial enough is up to you.

Quote:

---

Originally Posted by obi1kenobi

First of all, I'd reccomend using a different hashing algorithm, since the SHA1 has a collision problem (meaning there is a possibility that 2 different values will produce the same hash), which reduces security from 80 bits to approximately 69 bits

---

But isn't the possibility of a clash very remote? 2^69 is still a very big number. (590295810358705651712) which translates as 536870912 petabytes!

how would I implement the XOR that you suggested? say I have 56 for the key and 34 for the text, how do I XOR 56 into 34? or do i have to convert the numbers into binary first and XOR each bit ?

The possibility is remote, but still reduces the security, and if the algorithm is supposed to have 80 bits of security, it mustn't have 69, or whatever other value other than 80.

You don't XOR 56 into 34, you XOR 34 against 56 and save the result. In order to decrypt the file, XOR the result against 56 and you get the original 34. You can simply write XOR in VB and it'll take care of it for you, no conversion is needed. Use this syntax:

Code:

---

34 XOR 56 'This gives 26 as a result - as you can see, XOR is not addition nor subtraction

---

Btw, I'll be away from home for the next couple of weeks or so, so I may not be able to post in the forums during that time. If you have any further questions, feel free to ask and I'll reply as soon as possible.

ok then i'll implement that. I'm also going to make some other changes because I'm paranoid that "the man" has looked on here and knows my encryption method.