If I have to encrypt something on an outside machine and decrypt it at my end (using the encrypter and decrypter above), do they both have to be the same endian?

If you store 0x11223344 into the file, you'd rather not read 0x44332211 from the file.

Thank you very much for your help. I changed the pack/unpack to little-endian order and that worked

I used 'N', which produces the same encoding on all systems. Why did you change it?

Could I use your recommendation above to encrypt and decrypt large files (about 3 million records) or would you have any suggestions or reference points you could guide me to?

The format is efficient for appending records semi-frequently, but it's quite wasteful otherwise. Your 300MB might very well take up 600MB, and it could take a while to decode.

If you have a write-once-read-often scenario, you'd be better off converting the record file into a normal (single encryption session) file before doing your reading.

An alternative to the entire approach would be to have a persistent deamon which handles writting to the file (as a single encryption session). This would definitely be better if you had a near-constant stream of records to write.

my entire charset on the terminal gets funky.

Programs control the terminal by sending special character sequences in-band. The encrypted data can contain any characters, including some that resemble terminal control sequences.

more and/or less replace "dangerous" characters with representative glyphs. There's also od.

I used 'N', which produces the same encoding on all systems. Why did you change it?

On one server I couldn't use 'N' or 'Q'. It gave me an invalid-type error. I can understand 'Q' not working, but I am not sure why 'N' did not work. It worked everywhere else.

I am now trying to decrypt a file that is encrypted using the BlowfishNET 2.1.2 library from http://www.hotpixel.net/software.html using the BlowfishSimple class. (The people encrypting the file don't use PERL, but I do.) The README for the above-mentioned says:

"For efficiency the given string will be UTF-8 encoded and padded to the next 8byte block border. The CBC IV plus the encrypted data will then be BASE64 encoded and returned as the final encryption result."

Based upon my understanding so-far I am trying to use the following approach to decrypt the data without success:

• Decode using MIME::Base64::decode. I am unsure here as to whether I have to decode the entire file or 57 bytes at a time. Would you have any suggestions?
• Read 8 bytes at a time and decode the string using utf8::decode($string). In your read_uint32, I'm changing return (unpack('N', read_bytes($fh, 4))); to return utf8::decode(read_bytes($fh, 4));

Thank you very much for your help and comments.

First, could you confirm that you really need to ability to append record to an existing encrypted file?

Using my appendable format (which means you undid the Base64 encoding before storing the data):

utf8::decode( my $s = $cipher->decrypt( read_str($fh) ) );
[download]

Using my appendable format, but left the data Base64-endoded:

utf8::decode( my $s = $cipher->decrypt( decode_base64 ( read_str($fh) 
+) ) );
[download]

If you just dumped the return value of your encrypter to a file:

local $/;
utf8::decode( my $s = $cipher->decrypt( decode_base64 ( <$fh> ) ) );
[download]