You will have to restart the decryption process for each block of data. The encrypted data consists of the constant "Salted__" followed by an eight byte salt value. You can't concatenate separately encrypted blocks together because those headers are treated very differently than regular data.

But in fact, it's only if you are on a fairly recent version of Crypt::CBC that you will have headers that start with "Salted__". Otherwise...

... otherwise take a large aspirin and ponder this ominous note in the documentation for Crypt::CBC version 2.22:

IMPORTANT NOTE: Versions of this module prior to 2.17 were incorrectly using 8-byte IVs when generating the "randomiv" style of header, even when the chosen cipher's blocksize was greater than 8 bytes. This primarily affects the Rijndael algorithm. Such encrypted data streams were not secure. (emphasis the author's)

My humble opinion is that openssl would be a somewhat safer choice in terms of maturity and the number of eyes on the code. Crypto modules in general are notorious for subtle lurking exotic bugs that have no effect on anything, other than making your data much easier to steal than you would like to think. That was true centuries ago, it was true when the Enigma was invented, and it still seems to be true today.

If you think that Crypt::CBC is a good choice, consider this: Crypt::CBC with Rijndael is supposed to be the same as openssl enc -aes-128-cbc. Or is is -aes-192-cbc? Or -aes-256-cbc? (I checked and it's actually -aes-256-cbc, but I couldn't actually find anywhere that said that in the documentation.)

If you really want to use Crypt::CBC you at least want to go with the very latest version. Be positive that /dev/urandom exists and is known to work on your kernel. (If it doesn't Crypt::CBC will fall back on the Perl built-in random number generator, which is a Very Bad Thing cryptologically.) And keep a sharp eye out for later releases that might have more bug reports in them....

(and ditto on the disclaimer: I'm not a crypto guru either!)