7
$\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.

Improve this question
$\endgroup$
3
  • $\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, 2015 at 13:33
  • 1
    $\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, 2015 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, 2015 at 1:55

1 Answer 1

Reset to default
4
$\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.

Improve this answer
$\endgroup$
3
  • 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, 2015 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, 2015 at 6:28
  • $\begingroup$ Gak! You're right; the cheatsheet I used had that point wrong. Sorry. $\endgroup$
    – dave_thompson_085
    Aug 15, 2015 at 6:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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