# Is there a standard for OpenSSL-interoperable AES encryption?

Many AES-encrypted things (files, strings, database entries, etc.) start with "Salted__" ("U2FsdGVkX1" in base64). I hear it's some sort of OpenSSL interoperability thing: a b c.

Is there some standard reference somewhere (perhaps an RFC?) that explains how such OpenSSL-inter-operable AES-encrypted things are produced and later decrypted?

Ideally, an answer would link to a standard reference for the entire process, or perhaps a brief summary list of steps with a link to a standard reference for each step, something like:

To decrypt such a thing beginning with "U2FsdGVkX1" and with a known password,

• first do base64 decoding -- see Wikipedia: base64. The result will start with "Salted__". Be careful not to use C strings, because the result may include several 0x00 bytes.
• ...
• (I guess something about salting and the IV goes here?)
• (I guess something about CBC or CTR goes here?) -- see Wikipedia: block cipher modes of operation.
• (Perhaps something about message authentication goes here?)
• ...
• AES-decrypt each block with decrypt_one_AES_block( key, block_of_128_bits ) -- see Wikipedia: AES article and A Stick Figure Guide to the Advanced Encryption Standard (AES).
• save the result of each decrypt_one_AES_block(), concatenate them all together, and that's your plaintext. If the original was human-readable text or an HTML file, it may be OK to store the result in a C string; but other kinds of things may include several 0x00 bytes incompatible with C strings.

It may sound like I'm planning to write an implementation myself. I reassure you that I plan to use one of several available libraries -- it's just that when reviewing the libraries, I'd like to know what they should be doing. What should OpenSSL libraries be doing?

Is there a standard for OpenSSL-interoperable AES encryption?

-
related: "Salting when encrypting?" – David Cary Oct 2 '12 at 16:10
– David Cary Jan 24 '14 at 3:49
A very good question, and I have been programming down this rabbit hole recently as well. @Dave correctly notes that OpenSSL does some weird things that are proprietary, but he is incorrect that "nothing else" is compatible. Today I stumbled upon a nearly complete implementation of 'openssl enc' in Java via: juliusdavies.ca/commons-ssl/pbe.html You can, with the java class org.apache.commons.ssl.OpenSSL, do the equivalent in Java of nearly any command line such as 'openssl enc -aes-128-cbc -iv foo -key bar -base64', or 'openssl enc -aes-128-cbc -pass /foo/bar'. The ciphertext is interoperable – Douglas Held Aug 7 '15 at 21:42

## 1 Answer

There's no standard for it, it's a proprietary format that OpenSSL invented. So it's interoperable with every other version of OpenSSL out there, but nothing else.

-
Slightly more information would be welcome, e.g. a reference and a very short description of what the actual format is. A pointer to CMS containers would also be great. – Maarten Bodewes Aug 9 '15 at 10:05
OpenSSL doesn't use CMS containers, it's a proprietary format. The thing with proprietary formats is that they're, well, proprietary. You'd have to reverse-engineer the OpenSSL source code to figure out what the actual format is. – Dave Apr 28 at 16:06
Ah, so openssl pkcs7 doesn't exist? Note the final question: "Is there a standard for OpenSSL-interoperable AES encryption?" – Maarten Bodewes Apr 28 at 16:39
You can use PKCS #7/CMS, but the original question was about OpenSSL's base64 format. If it was CMS it'd be either raw binary or denoted with "----- BEGIN PKCS7 MESSAGE -----" or something similar. There is a standard for CMS-based AES encryption (and PGP-based AES encryption), but not for whatever format OpenSSL uses with its base64 format. – Dave Apr 28 at 16:49