mShred wrote:Why not just define two strings or two arrays even (or even one hash table).
I was actually thinking of doing something like that. It wasn't anything to type out because I used a script to generate the case statements. But I am working on switching it to two arrays now.
-Ninjex- wrote:Haven't bothered viewing the source code yet, but off the get go I notice:<br>If you are using a key which is longer than the text to encrypt, anything over the length of the text inside the key becomes pointless. For example:<br>
- Code: Select all
<br>Encrypting:<br>key = 12345678<br>text = 1234567<br>output = moqsuwy<br><br>Decrypting:<br>key = 1234567ajshdkjhsdiusd<br>text = mosqsuwy<br>output = 1234567
<br><br>I'll dive into the code and I'm sure I will find some more stuff.
That's an interesting issue...I have an idea on fixing it.
*EDIT: Yeah, that idea isn't going to work. Hrmmm...I'll have to think about this one. Let me know if you find any others.
-- Wed Jan 08, 2014 9:29 am --
Haven't bothered viewing the source code yet, but off the get go I notice:
If you are using a key which is longer than the text to encrypt, anything over the length of the text inside the key becomes pointless.
Fixed it and in doing so added another potential vulnerability (multiple correct keys) that I am still working out.