are there any multiple encryption standards?

I'm looking to encrypt some data using multiple ciphers (ie, AES, Serpent, Twofish...), and I want the user to be able to choose which ciphers are used and in what order. Are there any standards available for defining the metadata? My understanding is that what I dont want to do is prefix each layer with a magic number indicating the type of cipher and parameters used in the next layer because it will expose me to a plaintext attack. I took a peak at the PKCS #8 RFC, and it appears that only a single layer of encryption is supported here:

  EncryptedPrivateKeyInfo ::= SEQUENCE {
    encryptionAlgorithm  EncryptionAlgorithmIdentifier,
    encryptedData        EncryptedData }

I suppose I could just define the encr开发者_如何学JAVAyptionAlgorithm to be an array of values, but I want to make sure there isnt already a standard defined somewhere that I have missed.

PKCS#7 and its successor CMS allows for multiple layers. The EncryptedData contains an EncryptedContentInfo that when decrypted can contain another EncryptedData. This is usually used to combine encryption and signing, but there is no reason that it cannot be used for multiple layers of encryption (though support in other implementations may vary).

XML Encryption is another common standard for cryptographic metadata. It has no direct support for nesting encryption layers, but since it relies on the specification of the enclosing schema to specify the expected format of the encrypted data, there is no reason it could not specify multiple layers.

The OpenPGP Message Format is the final standardized format I can think of. Like CMS it supports nested layers of encryption (in theory - implementations might or might not support it).

Neither of the formats supports specifying nested encryption-layers upfront: the metadata for the nested layers will be encrypted, so you do not avoid the known-plaintext weakness. However, since you should always choose an algorithm that is safe against known-plaintext attacks anyway, I do not see that as a big problem.

Not that I'm aware of, because this isn't a cryptographic best-practice. Select a single, well known and peer reviewed cipher, and use that. Build your code so that you (or your users, rather) can easily swap out existing ciphers for a new one if a compromise is found, but don't expect to nest ciphers.