in reply to Crypt CBC using IDEA - output differs btwn systems

Took a quick look using the latest Crypt::CBC and Crypt::IDEA off CPAN. they return a 48 hex char string for encrypting '300'. which is the string 'RandomIV<8byteIV><8byteCipherText>'

At a guess you upgraded Crypt::CBC from something pre 1.22 to something greater than 1.22 which is when the readme says they added random IV's. And so it's probably the IV that's changing the length. According to the docs it should still work however I took a quick gander at the source and it appears to use a random IV unless one is specified in the encrypted string. If this is in fact the problem you are having you'll have to figure out what IV you were using before and use that specifically.

Tedrek

  • Comment on Re: Crypt CBC using IDEA - output differs btwn systems

Replies are listed 'Best First'.
Re: Re: Crypt CBC using IDEA - output differs btwn systems
by ewitch (Initiate) on May 13, 2003 at 11:01 UTC
    Thanks for your replies. The Crypt::CBC on the old server was 2.02, with Crypt::IDEA 1.01. On the new server I have Crypt::CBC 2.08 installed and Crypt::IDEA 1.02. I did try to "downgrade" both modules on the new server, and the CBC compiled OK but i get errors with the older IDEA:
    [root@ Crypt-IDEA-1.01]# perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for Crypt::IDEA [root@ Crypt-IDEA-1.01]# make cp IDEA.pod blib/lib/Crypt/IDEA.pod cp IDEA.pm blib/lib/Crypt/IDEA.pm /usr/local/bin/perl /usr/local/lib/perl5/5.8.0/ExtUtils/xsubpp -typem +ap /usr/local/lib/perl5/5.8.0/ExtUtils/typemap -typemap typemap IDEA +.xs > IDEA.xsc && mv IDEA.xsc IDEA.c Please specify prototyping behavior for IDEA.xs (see perlxs manual) cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE +-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -DVERSION=\"1.01\" - +DXS_VERSION=\"1.01\" -fpic "-I/usr/local/lib/perl5/5.8.0/i686-linux/C +ORE" IDEA.c IDEA.xs: In function `XS_Crypt__IDEA_crypt': IDEA.xs:66: `sv_undef' undeclared (first use in this function) IDEA.xs:66: (Each undeclared identifier is reported only once IDEA.xs:66: for each function it appears in.) make: *** [IDEA.o] Error 1
    I agree it would be ideal to have the newer modules running on both servers -- I am just not sure the best way to ensure backward compatibility with data that is stored encrypted via the "old method". I guess I could create a copy of the table in question with unencrypted data, and then re-encrypt with the new method. Any other suggestions?
      The Crypt::CBC on the old server was 2.02... On the new server I have Crypt::CBC 2.08

      Are you absolutely sure that 2.02 is really the version that's being used on the old server? Maybe there's an older version installed somewhere that's getting loaded instead. Because the default behavior of 2.02 is to prepend the IV and produce a 48-digit output for a one-block input. Or maybe someone upgraded Crypt::CBC on the old server a long time ago, and your old data has been broken for a while without being noticed.

      IDEA.xs: In function `XS_Crypt__IDEA_crypt': IDEA.xs:66: `sv_undef' undeclared (first use in this function)

      I don't know if this is the best solution, but you can get Crypt::IDEA 1.01 to compile by adding this to the .xs file:

      #define sv_undef PL_sv_undef
        Well, things are getting weirder.. I double-checked on the old server, looking for all files named CBC.pm - and the only one I found in my @INC does have "version 2.02" in the source. But I did notice that I upgraded the module earlier this year from version 1.20. The perl program I use for encryption runs as a daemon and hasn't been restarted since I upgraded Crypt CBC on that server. Is it possible that the daemon perl script could be using the older CBC module, ignoring the upgraded one? I did try installing CBC version 1.20 on the new server, and the older IDEA as well, and now the output length is 16 like in the old system. (btw it was 48, not 50 chars; I ++'d where I should have --'d)