Forum: Using The Website
Topic: Hint encryption faulty?
started by: Prime Suspect
Posted by Prime Suspect on Sep. 07 2003,5:38 pmTake a look at the hint at < this cache >. In particular, this string:
According to the decryption table, that should decode as:
but that is not what you get when you hit the decode button. Instead, you get:
The latter is what the poster obviously intended, which means the encryption routine is faulty when doing both encryption and decryption.
That's fine if you're only going to be using the decode button to decrypt the hint (in this case, two wrongs do make a right). But if you're trying to do it in the field, you're pretty much screwed.
Any chance of getting this fixed?
Posted by PC Medic on Sep. 07 2003,6:41 pmNow I have to admit, it has been a long day and there is a possibility I am missing something here. Try as I may I do not see the error you mention in the decryption table that caused you to obtain a "6tg" string in the middle of the correct decrypted string. Whether using the Decrypt button or the manual table I arrive at the same result which is ' xxxxxxxx.htm '. For one thing, the decryption table is exchanging character for character, so even if there were an error it would not lead to an error wher you received 14 characters from an original 12.
You mention doing this in the field. Is the table you are looking at on the monitor or a printout? If a printout, does it match what you see on your screen on this cache page?
Posted by Scout on Sep. 07 2003,8:22 pmThe problem is apparently with the source for the HTML. That ">" in the encrypted clue appears as "& g t" (without blanks) in the HTML source for the page.
If you just print out the page and use the printout in the field, you shouldn't have a problem. But if you have somehow downloaded the source for the page (I'm not sure what process Prime Suspect is using to save pages), then he might end up with that "& g t" in the encrypted clue.
I'm not sure what the best solution is to maximize the chances of getting a clean text no matter how you are downloading the cache pages for use in the field.
P.S. I've edited this four or five times trying to find a way to have HTML source appear uninterpreted and failed. There's a comment telling me that posting HTML code is allowed, but I don't see the switch to turn it off. Maybe it's in my profile or something, and not on the posting form itself.
Posted by Prime Suspect on Sep. 07 2003,11:12 pm
I never said their was a problem with the decryption table. I said there was a problem with the automatic en/decryption routine.
The probable reason you don't see the problem is that you're using Microsoft Internet Exploder - a browser that's notorious for being out of compliance with web standards. A browser that's in compliance wouldn't have translated the characters "& g t" (excuse the blanks, but they're necessary) to a ">" sign. The correct html code for a right angle bracket has a ";" after it.
The problem is that the decoder is translating the "." to a ">". Then, to prevent other problems, the ">" is translated to "& g t", which is wrong, because when a browser written to correct standards views the text, it will not translate the malformed code into a ">". It remains "& g t". Oddly enough, in other places, the angle bracket is translated to the correct code. It appears to be working right only when the original "." (which is encoded to a ">") is followed by a blank space. If it's followed by a non-blank character, it's not using the correct html sequence for a right-angle.
This means it's going to be wrong to anyone using Mozilla, Firebird, Netscape, Opera, or just about anything that's not Microsoft.
Here's what it looks like in a proper browser. The text string referred to is circled.
Posted by Scout on Sep. 08 2003,7:02 amThe period needs to be encoded as a ">". The Navicache encrypter seems to be doing that OK, but the problem arises when that is turned into the HTML code "& g t" (excuse the blanks), whereas proper HTML should be "& g t ;". Internet Explorer is forgiving, but other browsers are stricter.
Posted by PC Medic on Sep. 08 2003,8:26 amMy apologies for misunderstanding you were referring to the script and not the actual table. I should have caught this when you mentiond the ">" as that is as we all know the html code for the character in question. And as you suspected (though I do have the other browsers available, I did in fact just take a quick look with IE last night.
Not sure how this got by us (or has never been mentioned before) as we test with all browsers before releasing the scripts to the server. Now that it is clear what you are referring to I will have a look at the script and thank you for pointing this out.
Posted by Prime Suspect on Sep. 08 2003,9:59 am
That always seems to be the way. I've worked weeks on software that I thought was ironclad, only to have the first beta tester find a problem in the first 5 minutes.
The reason I noticed this was that I had a little stand-alone ROT13 converter, and I was adding an option to it for Navicache style en/decrypting as well. The cache listed above was the first one I picked to test on. Had it not had a URL in it, I probably would never have discovered the problem.
I do like this hint encoding better than simply ROT13. I've often wanted to included numbers or coordinates in a clue, but i knew they would be displayed in plaintext. So you either skip it, or spell the numbers out, which is a pain for the decoder. You're system's pretty slick. Just need to get that ">" problem ironed out. (I knew there was a wayt to get it to show up in the post )
Posted by Scout on Sep. 08 2003,11:06 am> :-)
Posted by PC Medic on Sep. 08 2003,4:28 pmIt should be fixed now.
Please let me know if you still are experiencing the same problem.
Posted by Prime Suspect on Sep. 09 2003,1:08 pmLooks great! Thanks!
Posted by PC Medic on Sep. 09 2003,3:19 pmNot a problem.
Thank you for catching the bug ... err I mean feature