Block cyphers like Rijndael work with fixed length blocks, usually with block length = key length.

If you want to use CBC, you should take care that all but the last block have a length that is a multiple of the key length (actually I don't know if that's really a requirement, but I can imagine a hundred reasons why it might blow up if you don't honor that constraint).

It seems that you start the CBC mode anew for every line that you write (in the encryption), but try to decrypt the whole file at once in CBC mode. That won't work, you have to take the exact steps in reverse (in this case reset the cypher block chain after each encrypted line. Which kinda defeats the CBC idea). But since the encrypted text may contain newlines, you can't rely on line logic anymore - you'll have to invent a binary format for that.

As for the potential permission issue: just test the encryption/decryption part on the command line, preferably first in memory, i.e. without writing the data to the file.

Update: a bit more about CBC: symmetric, block based cyphers suffer from the weakness that if you encrypt large amounts of data, a potential attacker can gather much data that is all encrypted with the same key. Additionally if a block of identical data recurs multiple times, it will result in identical encrypted blocks, thus revealing information on an eavesdropper.

To circumvent these problems the "Cypher Block Chaining" was invented. That's a protocol that defines a way that the encryption is changed based on prior encoded blocks.

More exactly: the plain text of the current block is XOR'ed with the cypher text of the previous block.

Which means that for every block (except the first one) you not only need the key to encrypt it, but also the preceding block.

So if you want to decrypt CBC data you need reverse the encryption process exactly.

(The fine print: I'm not a crypto guru, so please all correct me if I wrote bullshit ;)

If you want to use CBC, you should take care that all but the last block have a length that is a multiple of the key length

No. The blocks passed to crypt have no relation to cypher blocks. The extra bytes will be buffered until the next call to crypt.

The start/crypt/finish mode allows you encrypt and decrypt arbitrary segments of the message (file) at a time, as long as you process the entire message from the start.

In fact, encrypt and decrypt are just thin wrappers around start/crypt/finish.

To circumvent these problems the "Cypher Block Chaining" was invented. [...] Which means that for every block (except the first one) you not only need the key to encrypt it, but also the preceding block.

Right, although Crypt::CBC normally uses a special value for the first block too: the salt.
Crypt::CBC uses salting to ensure that every message is encrypted with a different key.
Crypt::CBC uses chaining to ensure that every block is encrypted with a different key.

So if you want to decrypt CBC data you need reverse the encryption process exactly.

Aye, and he doesn't do that. If he really did want to add a line at a time, he'd file would have to look like

length-of-encrypted-line, encrypted-line, length-of-encrypted-line, en
+crypted-line, ...
[download]

Each line would be a message that would be encrypted, and then decrypted individually (using encrypt and decrypt).

I wrote the code you need.

Some utility functions

sub read_bytes {
   my ($fh, $to_read) = @_;
   my $buf = '';
   while ($to_read) {
      my $bytes_read = read($fh, $buf, $to_read, length($buf));
      die("$!\n") if !defined($bytes_read);
      die("Unexpected end of file\n") if !$bytes_read;
      $to_read -= $bytes_read;
   }
   return $buf;
}

sub read_uint32 {
   my ($fh) = @_;
   return (unpack('N', read_bytes($fh, 4)));
}

sub read_str {
   my ($fh) = @_;
   my $length = read_uint32($fh);
   return read_bytes($fh, $length);
}

sub write_uint32 {
   my ($fh, $n) = @_;
   print $fh (pack('N', $n));
}

sub write_str {
   my ($fh, $str) = @_;
   print $fh (pack('N', length($str)), $str);
}
[download]

The line-by-line encrypter:

sub writeSubmissions {
   my ($cipher, $log_file, $str) = @_;

   open(my $FH_encrypted, '>>', $log_file)
      or die;
   binmode $FH_encrypted;
   flock $FH_encrypted, LOCK_EX;

   write_str($FH_encrypted, $cipher->encrypt($str));
}

my $key_file = 'key_file.txt';
my $act_log_file = "pem.enc";
my $pem_log_file = "act_encrypted.enc";

my $my_key = `openssl enc -bf-cbc -d -in \Q$key_file\E -k encrypt`;
my $cipher = Crypt::CBC->new({ key => $my_key, cipher => 'Rijndael' })
+;

writeSubmissions($cipher, ..., ...);
[download]

The line-by-line decrypter:

my $key_file = 'key_file.txt';
my $encrypted = '...';
my $decrypted = '...';

my $my_key = `openssl enc -bf-cbc -d -in \Q$key_file\E -k encrypt`;
my $cipher = Crypt::CBC->new({ key => $my_key, cipher => 'Rijndael' })
+;

open(my $FH_decrypted, '>', $decrypted)
   or die("Unable to create decrypted file \"$decrypted\": $!\n");
binmode $FH_decrypted;
flock $FH_decrypted, LOCK_EX;

open(my $FH_encrypted, '<', $encrypted)
   or die("Unable to open encrypted file \"$encrypted\": $!\n");
binmode $FH_encrypted;
flock $FH_encrypted, LOCK_SH;

while (!eof($FH_encrypted)) {
   print $FH_decrypted $cipher->decrypt(read_str($FH_encrypted));
}
[download]

Update: Fixed bugs mentioned in replies.
Update: Tested (minus the openssl bit). Fixed other bugs.

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)

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!)

We had seen that ominous note and we have version 2.24 of Crypt::CBC.

The reason I'm using Crypt::CBC is because it was suggested to me somewhere previously when I was pondering encryption. I honestly don't understand this stuff as much as I should. We originally looked at openSSL, but then I was told I had to use the AES standard which, after investigation, we thought was the Rijndael implementation.

I'm going to take the fairly large aspirin now...

---

I learn more and more about less and less until eventually I know everything about nothing.

You could use openssl enc -aes-256-cbc. That's probably the best compliance with the notion of "standard" that you could find.

Be careful not to pass the encryption key as an environment variable, since the environment variables can be visible in ps in most Unix-like operating systems. And do double check that you have a usable /dev/urandom.

In both programs, you should binmode on the fh from which you read and on the fh to which you write. It makes a difference on some platforms, and won't harm anything on the others.

Also, flock FH_crypted, LOCK_EX; is useless unless you also use flock FH_crypted, LOCK_SH; in the decryptor.

I attempted to use the readmore tags, but I had them placed incorrectly. I have fixed this.

---

I learn more and more about less and less until eventually I know everything about nothing.