Base64 Encoding

mikemc24 has asked for the wisdom of the Perl Monks concerning the following question:

Hi I am having a problem sending encoded data via a form to a server that then decodes it.

I have a user string and a key that is XORed then encoded using base64.

I get the length of the string repeat the key to the same length and XOR the two, the length of the string adjusted key length and the resultant XOR are all the same length.

When I use base64 encoding and send that data there are additional characters appearing when the receiving server decodes the data.

Would someone please tell me where it all goes wrong and how to correct it.

my $user_string = "VendorTxCode=1298062774&Amount=43.01&Currency=GBP&D
+escription=Goods&SuccessURL=http://www.happy.com/success.html&Failure
+URL=http://www.unhappy.com/failure.html&BillingSurname=Bloggs&Billing
+Firstnames=Fred&BillingAddress1=30 Peyton Place&BillingCity=Somewhere
+&BillingPostCode=AB1 2CD&BillingCountry=UK&DeliverySurname=Bloggs&Del
+iveryFirstnames=Bill&DeliveryAddress1=30 Peyton Place&DeliveryCity=So
+mewhere&DeliveryPostCode=AB1 2CD&DeliveryCountry=UK";

my $key = "TuDQUBZVA4kPfeM7";

my $size = length($user_string);
my $encode = $key x $size;

my $portion = substr($encode, 0, $size); 

my $result = $user_string ^ $portion;


my $base_encoded = encode_base64($result,'');
my $base_key = encode_base64($key,'');
[download]

Comment on Base64 Encoding Download Code

Replies are listed 'Best First'.
Re: Base64 Encoding by jethro (Monsignor) on Feb 18, 2011 at 23:32 UTC
This part of the code looks correct. You construct $encode much too big, but substr() corrects that You didn't show the rest of your code, it might be that the problem is there. It might be that the problem is on the other side on the server I would suggest you try to test your code with a really short $user_string and a short key, so that you can calculate everything by hand and compare that with what your script does. You do know that the encryption you are using is horribly weak?	[reply]
Re^2: Base64 Encoding by mikemc24 (Novice) on Feb 19, 2011 at 06:04 UTC
That is all the code, $base_encoded and $base_key are whet is sent to to the remote server The $key has to be 16 chars long. So I reduced the $user_string and whatever I reduce it to after the base64 encoding the remote server produces additional characters Is there another way to base64 encode.	[reply]
Re^3: Base64 Encoding by ikegami (Patriarch) on Feb 19, 2011 at 06:51 UTC
That is not all the code. You don't show how you send it to the server, and you didn't show the code on the server. We can't tell what you actually sent, and if you sent the correct string, we can't tell you where the algorithm on the client differs from the one on the server if we only see one. We may also be able to deduce the difference if we knew the exact output of the server's decode. (The "additional characters" you mentioned.)	[reply]
Re^4: Base64 Encoding by mikemc24 (Novice) on Feb 19, 2011 at 20:06 UTC
Re^5: Base64 Encoding by ikegami (Patriarch) on Feb 20, 2011 at 00:13 UTC
Re^4: Base64 Encoding by mikemc24 (Novice) on Feb 19, 2011 at 20:12 UTC
Re^3: Base64 Encoding by jethro (Monsignor) on Feb 20, 2011 at 03:50 UTC
To state the obvious, this can't be all the code, there must be code where the data is sent to the server. Why should that necessarily be error free? What about the remote server, is there some convincing evidence that that code is correct? Since you also encode the key, do you send the key as well? Maybe you appended it wrongly (or just the wrong way) and that gets sent back as additional characters. I notice that the number of additional characters is about what you would expect if you got sent back the base64_decoded cleartext password. But the characters themselves don't look like base64_decoded, so my guess is probably wrong, but might give you a hint in the right direction PS: AFAIK MIME::Base64 is a very old and well-tested module, the chance to find the bug there are pretty slim	[reply]
Re^4: Base64 Encoding by mikemc24 (Novice) on Feb 20, 2011 at 06:37 UTC