4

My home server runs OpenBSD 5.3 with Samba serving files to several Windows machines. I wrote a script to backup video files by encrypting each file with openssl enc -aes-256-cbc and uploading it to Amazon S3. To test one possible restore scenario, I tried running the script on a file, downloading the file to one of the Windows machines, and decrypting it using several programs advertised as decrypting AES-encrypted files, but they weren't able to decrypt it. Can a file encrypted by OpenSSL be decrypted only by OpenSSL? Can a file encrypted by OpenSSL on OpenBSD be decrypted only by OpenSSL on OpenBSD?

For the record, I had no problem downloading the file to my server and decrypting it using OpenSSL. However, I'm interested in knowing if my videos on S3 (quickly archived to Glacier) can remain accessible regardless of my choice of server setup.

Improve this question
1
  • Make sure you read the fine print on the applications you are using to decrypt on windows. They may not be actually decrypting a raw stream, as OpenSSL generates, rather a packaged stream, such as AES encrypted ZIP or PGP with an AES scheme. Commented Aug 5, 2013 at 2:59

2 Answers 2

Reset to default
3

AES-CBC-256 fully specifies an encryption algorithm and a decryption algorithm. Given a plaintext, a key and an IV, two implementations of AES-256-CBC encryption will produce the same ciphertext. Given a ciphertext, a key and an IV, two implementations of AES-256-CBC will produce the same plaintext.

The IV is a random string that is generated when you encrypt a messsage. If you encrypt the same data twice, you'll get different ciphertexts because the IV will be different. This is in part so that someone who can only see two ciphertexts with the same length cannot detect whether the ciphertexts are equal. Most tools prepend the IV to the ciphertext, so that all the data needed for decryption is in one place (except the key, of course).

The OpenSSL command line tool generates a file containing a 16-byte header, the IV, and the ciphertext. This format is specific to OpenSSL but does not depend on the platform.

OpenSSL's command line is intended more as a demo of the possibilities of the library than a production-grade command line tool. I don't recommend using it, it's too easy to make a mistake and either end up with non-recoverable data or insecure data. Also OpenSSL won't help you with key management.

Instead, use a tool that is intended to encrypt file. GPG is designed for this purpose. Generate a key pair, and then encrypt files with gpg -e [email protected] /path/to/file.

Improve this answer
2
  • "I don't recommend using it, it's too easy to make a mistake and either end up with non-recoverable data or insecure data." Can you elaborate on that? Commented Aug 6, 2013 at 15:51
  • 1
    For example: You have to match the key with the encrypted data. Where are you going to store your key? Or rather, most likely, your keys? How do you know which key is which? So you have some data lying around… which key is it encrypted with? With gpg, these questions are easy to answer. With the openssl utility, they aren't. Also, do you care about data integrity, or only confidentiality? (CBC doesn't provide integrity.) Commented Aug 6, 2013 at 16:53
0

AES encryption and formatting is governed by NIST specifications. It should be safe to assume that so long as the implementations are compliant, your files will be accessible across platforms.

Improve this answer
2

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.