6
$\begingroup$

As far as I understood, a secret key (same length as CBC block size) and an initialization vector (IV) are needed to decrypt a AES-256-CBC encrypted string. As the IV should better be random, it has be distributed in plaintext along with the encrypted text.

Is there a standard or at least "commonly used" format to format the result?

E.g. /usr/bin/openssl seems to concatenate "Salted___" + IV + cyphertext and then base64 encode everything. Would this be a recommended way? I want to store the encrypted text and still be able to decrypt it in 10 years with any PHP/Python/Java library.

$\endgroup$
  • $\begingroup$ Most libraries accept IV and ciphertext (please write ciphertext and not cipher as this corresponds to the algorithm usually) as different inputs. I'm not aware of any standard describing how to store the IV together with ciphertext, but maybe some else is.... My suggestion: If you're not sure wether the libraries will be able to decode the format, just store the format description alongside your encrypted data. $\endgroup$ – SEJPM Aug 12 '15 at 13:33
  • $\begingroup$ The most common format I've seen is just prepend the IV, that is, store the IV as the first 16 bytes of the ciphertext (and the actual ciphertext as the rest). BTW: AES-256 does not have the same length key as the CBC mode size; instead, it has 32 byte (256 bit key, that's what the -256 in AES-256 means) key, and a 16 byte (128 bit) block size. $\endgroup$ – poncho Aug 12 '15 at 14:13
  • $\begingroup$ The 'enc' command, one of about 50 in the openssl program (whose location varies on different systems), uses that format. Base64 encoding is optional, only if you specify -a. $\endgroup$ – dave_thompson_085 Aug 14 '15 at 1:55
2
$\begingroup$

Is there a standard or at least "commonly used" format to format the result?

PKCS #7 (and CMS which is a further development) describes a standard format for encrypted data. While it's mainly meant for public key encrypted data, it also has options for symmetric keys. It's rather complex due to all the features it supports, however, so unless you can find a library that does all the encoding and parsing for you, you may want to do something simpler if you only need the format for your own use.

Another "format" that's probably quite commonly used is simply to concatenate the IV and the encrypted message (and then MAC, if applicable). However, that's not very discoverable.

E.g. /usr/bin/openssl seems to concatenate "Salted___" + IV + cyphertext and then base64 encode everything. Would this be a recommended way?

Actually, "Salted___" in OpenSSL indicates password-based encryption, and the value that follows is not an IV for the cipher, but a salt for deriving the key and IV from a password. If you are using a key directly, rather than a password, you shouldn't reuse that format, or it'll just cause confusion.

I want to store the encrypted text and still be able to decrypt it in 10 years with any PHP/Python/Java library.

Other than PKCS #7 or CMS, I would suggest using just plain ASCII to describe the format, cipher and mode and then concatenating the binary IV + data. It will expand the data, but space if usually cheap, and ASCII will always be readable.

$\endgroup$
  • 1
    $\begingroup$ PKCS#7 evolved into and is functionally replaced by the IETF version Cryptographic Message Syntax CMS, rfcs 2630 3369/3370 and 3852, much like Netscape SSL became IETF TLS. CMS, not PKCS#7, has the options suitable for the OP's case: symmetric-wrap KEKRecipientInfo in EnvelopedData and plain-symmetric EncryptedData. OpenSSL commandline 'cms' does support these. $\endgroup$ – dave_thompson_085 Aug 14 '15 at 2:02
  • $\begingroup$ @dave_thompson_085, both PKCS#7 and CMS have an Encrypted-Data content type that would work here, but CMS is the newer, so I'll add that recommendation to the answer. $\endgroup$ – otus Aug 14 '15 at 6:28
  • $\begingroup$ Gak! You're right; the cheatsheet I used had that point wrong. Sorry. $\endgroup$ – dave_thompson_085 Aug 15 '15 at 6:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.