Re: reduce the length of encrypted text
Friday, December 21, 2007 09:00 AM
I didn't get through your whole question because you are using some wrong terminology, which makes things a little confusing to try to read any further. Nowhere are you "encrypting" anything. Early on, you are computing a "hash" (a message digest) for some string. That is not encryption, as encryption carries the implication the operation can be reversed. (A message digest cannot be.) Later on, you are simply base64-encoding some material. This is likewise not encryption: it is a simple scheme that ensures all the material can be displayed in a limited-bit-count character set (6-bit, IIRC) so it can be safely transferred as plain text, which us old-timers needed back when e-mail's effectiveness was limited to the displayable screen characters. That is also not encryption. Please be careful with the terminology. Note that, regardless, there will a proportional relationship between the length of encoded (or encrypted) material and the source material. So if you want the encoded values to be shorter, you'll have to start with shorter values. message digests, OTOH, tend to have a fixed length for any source material. What this comes down to, then, is that you might want to store information in a database table instead of in a set of encoded URL query string parameters. The database table entry should probably have some sort of a unique key applied to it, and this key should be what is sent to the user. Thus the URL will have a fixed and reasonable length to it regardless of the amount of material in the database that is "hidden" behind this key value. In your case, the primary key should probably *NOT* be sequential, just to keep curious people from phishing around for other people's info. This being said, what *may* work for the primary key is to compute a message digest for the info in the database table, and use this digest for the primary key (and in the URL query string parameter set).