Role of IV in Perl's Crypt::Rijndael

Sorry in advance if I'm asking a stupid question:

I thought the role of "IV" in encryption is to avoid having identical ciphertext for identical plaintext. So one could use some random IV.

Writing some Perl code I'm confused, however. Consider this test code:

use Crypt::Rijndael;
my $cipher = Crypt::Rijndael->new('x' x 16, Crypt::Rijndael::MODE_CBC());
$cipher->set_iv('IV' x 8);
my $data = 'old grey fox 123';
my $c = $cipher->encrypt($data);
$cipher = Crypt::Rijndael->new('x' x 16, Crypt::Rijndael::MODE_CBC());
$cipher->set_iv('IV' x 8);
die "bad" unless ($cipher->decrypt($c) eq $data);

Decryption fails if I don't set the IV before encryption.

That confuses me: I thought I don't need the IV after encryption any more and that the IV should be secret. However when I "comment out" the second set_iv, the program dies with bad.

But when I need it for decryption, should the IV be treated as part of the encryption key? Currently my application only stores the key, not the IV.

Are these facts correct, or did I use the algorithm in a wrong way? My application for encryption is protecting rather short secret information like authentication keys...

I thought the role of "IV" in encryption is to avoid having identical ciphertext for identical plaintext. So one could use some random IV.

Well, yes, but in case of CBC it also needs to be fully unpredictable by an adversary.

$cipher->set_iv('IV' x 8);

Absolutely doesn't cut it unless the key is never reused. Usually that means that the IV is created using a cryptographically secure random number generator. There are of course other ways to get an unpredictable IV, such as encryption of a counter with another key, but those are very uncommon.

Decryption fails if I don't set the IV before encryption.

Well yes. Let's take a look at CBC mode encryption (decryption is similar of course, except that the XOR with the IV or previous ciphertext is performed after the block cipher has been applied):

Obviously it always requires an IV. If you set it to a block of all-zero bytes then the XOR with the plaintext block will simply result in the same plaintext block, so that's probably as close as you can get to "no IV". Most modes of operation require an IV or nonce as input.

That confuses me: I thought I don't need the IV after encryption any more and that the IV should be secret.

No, the key is the secret part. Storing the key with the IV makes no sense, as the key / IV combination should be unique. The IV can be send in the plain. Quite often it is prefixed to the ciphertext.

Are these facts correct, or did I use the algorithm in a wrong way? My application for encryption is protecting rather short secret information like authentication keys...

If you do not store or cannot derive the key for the ciphertext then you're doing something wrong, yes. If you're storing keys you would generally use a mode like AES-SIV or key wrapping (or you'd use a key derivation function, a ratchet, etc.).

The IV randomizes the ciphertext, and must be unique for each message. For CBC mode, it MUST be unpredictable. It need not be secret, it's usually prepended to the ciphertext. It MUST NOT repeat for a given key, and you MUST use a Message Authentication Code (MAC) over the ciphertext and IV for CBC to be secure against common attacks. The recipient MUST validate the MAC before attempting decryption, and MUST NOT continue to decrypt if the validation fails.

If the IV is predictable or repeated, CBC is insecure against passive attack. If the MAC isn't used, active attacks can break the encryption.