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
