You should try to make this into a module that can be
used. perlnewmod has some instructions on how to do this
(in your case, you probably should just ignore the upload-to-CPAN part for now.)

You could write your code to have a lot less variables
that are used twice and then thrown away.

On purpose:

CPAN has many modules for en/decryption.
These modules implement algorithms that are better then
yours, in terms of how easy breaking a message is likely
to be.
(It looks to me like yours has signifigant vunerablities,
mainly deriving from the join("1", @key3)
and possibly also deriving from mathematically properties
of the result of an xor'ing data, uuencoding it, and then xor'ing it the same way. Your algorithm is probably also
vunerable to a brute-force attack.)

Don't use an obfuscated version of RSA, whatever you do. There are all kinds of issues like blocking, padding, and key management that are likely to get swept under the rug if someone's trying to cram RSA into three lines. If you need public key encryption, you can grab Crypt::RSA -- it's pretty nice, once you manage to get Math::Pari to install... There are plenty of other good crypto modules out there, too.

I agree with wog's comments. UUencode is a bad idea; it adds extra redundancy to the message (for instance, setting the first character to a value determined by the length of the message), which helps a cryptanalyst. Another problem is that only the first 2*length($key)-1 bytes of the message are protected by the key in any way. If someone tries to put a larger message into it, part of the message will be obscured but easily recoverable.

Also, your tr/// replacement string contains the letter c twice, so you won't always be able to decrypt the message properly.

Don't print the results. Returning them instead is a much better idea. What if the caller doesn't want the encrypted / decrypted string printed, but instead wants to do something else with it? Sure, they could do something obfuscated like tie STDOUT so its output goes into a variable, but the idea here (assuming this is not for obfuscation) is to not require the caller to do things like that.

well; then you just have to change print $result; with $_ = $result; I suppose... But i don't know how the $_ variable is handled with packages (yeah it's my first one) so, if you could tell me if it's the right way to re use the encrypted string...

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other