Hey Shawn

Good to hear from you!
And especially with as detailed a reply!

Both interfaces are UTF8, but I will check what the database is. I assume
that that isn't the issue, because the same data serves the number correctly
in the one interface, but not the other.

I'll take a look at the other options you mentioned.

Thanks again
Moshe


-----Original Message-----
From: active-server-pages@yahoogroups.com
[mailto:active-server-pages@yahoogroups.com] On Behalf Of Shawn K. Hall
Sent: Monday, April 20, 2009 5:49 AM
To: active-server-pages@yahoogroups.com
Subject: RE: [ASP] RC4 Encryption

Hi Moshe,

> Anyone still around here?

Yep. :)


> I have a ready-made function for RC4 encryption.
> Then it converted to Hex for storing in an SQL db (see below).
>
> The very weird thing, is that when in the order process, the
> encryption/decrypt process is perfect.
>
> But when I access the same string, using the same functions,
> with the same key, via an admin interface I built the credit
> card info that spits out - is wrong. There is some kind of a
> corruption.

Sounds like it's one of either two problems:

* The characters in the first implementation are a different charset
than in the second - the data is being received and processed as ANSI,
UTF-8, UTF-16 or Unicode, but is being stored in a different charset
that has a different binary representation for the same characters. When
you draw the data back out, it's keeping the storage charset, instead of
the original, which is damaging the reconstruction since the actual
bytes aren't the same.

* If the charsets are the same, the resulting value may have embedded
nulls, which ASP is incapable of correctly representing within strings.


You have four options as far as I can see.

* Instead of storing the data as hex, store it as a string with only
decimal values (a number) so it can be easily converted to a normalized
value (a double or decimal). That will enable you to reverse it back to
a proper string (if the resulting number is short enough to fit in these
types of variables).

* Ensure that the charsets are exactly the same within the storage
system and the front-end. This could be an issue if you don't have full
control over the database. If the charset for the field is changed back
to an unsupported charset, you're screwed.

* Edit the RC4 encryption/decryption functions to normalize the charset
(StrConv) before and after processing, without consideration for the
storage or frontend charsets. Chances are the RC4 functions stores the
data in a byte array throughout processing, which you should use to
convert to/from the hex values instead of reconverting it to string then
hex.

* Use a system that can encrypt/decrypt the data without ever converting
it to a binary. This will avoid the embedded null issues. This is
important, but not as safe as just avoiding charsets with embedded nulls
entirely.

-Shawn




------------------------------------

---------------------------------------------------------------------
Home : http://groups.yahoo.com/group/active-server-pages
---------------------------------------------------------------------
Post : active-server-pages@yahoogroups.com
Subscribe : active-server-pages-subscribe@yahoogroups.com
Unsubscribe: active-server-pages-unsubscribe@yahoogroups.com
---------------------------------------------------------------------Yahoo!
Groups Links