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

Im working on some SOAP code that authenticates by passing a nonce between the two processes. Each side encrypts with a shared PW and compares.

Issue: I can encrypt/decrypt successfully from Perl to Perl and Java to Java but not between the two. (Im using Crypt::TEA). The Perl version outputs ASCII whereas the Java outputs HEX. Im assuming that both are int[] on the back (I have the Java source) but I don't know how the Perl conversion into ASCII is being done so I can't duplicate it with my Java code.

Any notions on how to proceed?

EDIT: good ole' source code. Am reading - hoping to gain some understanding.

Replies are listed 'Best First'.
Re: Encryption between Java and Perl
by almut (Canon) on Aug 14, 2007 at 19:56 UTC

    Looking at the Crypt::Tea source you'll find the following line at the end of the encrypt routine:

    return &str2ascii( &binary2str(@cblocks) );

    @cblocks seems to be an array of 32-bit ints, which binary2str packs into a string, which in turn is converted into some pseudo-base64 format by str2ascii.  Assuming the string before the str2ascii conversion is what you're interested in (i.e. that this is the same string that Java is dumping as hex), you should be able to retrieve it using the complementary function ascii2str:

    use Crypt::Tea qw(ascii2str); my $encrypted_ascii = ...; my $str = ascii2str($encrypted_ascii); # now convert to hex: my $hex = unpack "H*", $str;

    Of course, this is making a couple of assumptions, so some corresponding example hex/Java and ascii/Perl output would help in verifying those...

      I ended up having to bag out on Crypt::Tea. The first thing it does is some crazy munging of the key. I don't have enough faith in my Java coding to even attempt it.

      Im going to make a stab with Crypt::CBC now. The Java 'blowfish' interpretation looks pretty straightforward.
Re: Encryption between Java and Perl
by andreas1234567 (Vicar) on Aug 15, 2007 at 05:49 UTC
      I ended up using an MD5 hash of a 'nonce' plus a key to authenticate my client(s). This prevents random passers-by from calling my SOAP functions. Still working on incorporating SSL into the mix.
        If it's feasible for you, I've found SSL peer certificate-based authentication to be a good solution.

        I guess you can add all sorts of other authentication over the top of that (eg: passwords, session tokens, etc), but no passer-by is really going to be able to get past the SSL request authentication stage.

        I use openssl + a perl script to generate my client certificates... the attributes are formated so that they're both human readable (by the customer's web-browser) and so that they contain a (secret) ID which my code can look up in the database.

        -David