I found that typing all kinds of sequences did the trick. Typing ato z and copying it in a few times did the trick too. Then I backspaced to the '1' (Small L) and when replaced with other letters it was okay. Put the 'l' back and it reappeared. It seems to be the encoding process.
Sometimes you get garbage after deleting the text but pressing the delete key removes the hidden char in the input field and the output clears. I noticed in the Flash debugger that a letter 'a' turns up as "a/r" ie with a carraige return. Hope that helps. I am new to the game so can't help more. If the debugger gave you more support I might be able to help. John ----- Original Message ----- From: "ryanm" <[EMAIL PROTECTED]> To: <flashcoders@chattyfig.figleaf.com> Sent: Tuesday, July 25, 2006 7:37 AM Subject: [Flashcoders] Weird problem with encryption... > I'm working on some encryption classes, and I've run into an extremely > odd problem. Let me give you an example: > > http://www.horsefish.net/businesstools/sample.html > > Scroll to the bottom to the Encryption Test and type "asdf" in the clear > text string field. You'll notice that it breaks when you type the f. > However, if you change any character in the string or any character in the > key, it works fine. If you continue typing "asdf" repeatedly you'll see that > it breaks at predictable intervals. My first thought was that something must > be wrong with the characters being used to pad the strings, since it always > seems to break when you reach half a block. So I spent all kinds of time > going through the algorhithm and replacing the pad characters to see what I > was doing wrong, etc, but found nothing. Then I noticed something odd. If > you switch to XXTEA using the combobox in the top right corner, you can > produce the same error. Type "Hello, my name is " (including the space at > the end) and you'll see the same thing happening. Add a character or change > any character in the string and it encrypts and decrypts correctly. Needless > to say, I find it exceedingly odd that both ciphers would suffer the same > flaw, despite the same flawed developer working on both of them. I don't > know if the MD5 class suffers the same problem, since it's one way and I > don't have a good way to check it short of using someone else's > implementation to repeatedly check strings until I find a key/message pair > that produce the wrong result. > > So, the point of all of this is that I believe, after banging on this > for some time, that there must be some character that is being generated by > the cipher that Flash isn't handling properly. The encrypted string is > generated in both classes by using bitwise operators to alter character > codes, and what I think may be happening is some non-printable or otherwise > unimplemented or incorrectly implemented character code is being generated > in the cipher text, which is causing it to output garbage instead of valid > cipher text. Of course, when I try to decrypt the garbage, it only returns > garbage. > > Does anyone have any ideas on this? Has anyone experienced anything > similar? Any light you guys can shed on this would be helpful. > > ryanm > > _______________________________________________ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
