Is there a standard format for storing/exchanging encrypted data along with the key needed to decrypt it (data is encrypted with a single use symmetric key and the symmetric key itself is encrypted with asymmetric key for the receiver)?

We are trying to build an interoperable protocol to exchange large messages between two parties that may not agree on much else besides using asymmetric keys. The best way seems to be using a symmetric single use key to encrypt the data and then encrypt the symmetric key with the asymmetric key and pass along the whole thing as a package (e.g. RSA wrapped AES). So is there any widely used standard for sharing the encrypted text along with its key, preferably along with some information about the symmetric algorithm used.

The only work that I found in that direction is OpenPGP which I feel is somewhat too email focused. I was wondering if there is anything else that has more metadata along with it to describe the alogs and the keys.

Update: my application uses JSON to store some additional meta outside of the envelope.

  • 1
    You're trying to send encrypted data together with the key? What for?
    – user163495
    Jun 16, 2020 at 7:01
  • One comonly used standard is ASN.1, but it is designed for predefined data format so it is not best for interoperability. Second option is to just put it into JSON, which can contain heaps of metadata and is very interoperable but is inefficient for storing the ciphertext. You can also make some hybrid such as ASN.1 containing the ciphertext and a json. Then have any metadata in the json. But it is unlikely any other solution will be compatible with such hybrid out of the box. Jun 16, 2020 at 9:20
  • 1
    @MechMK1 the message is larger and the best way to encrypt large messages seems to be symmetric key algo like AES and encrypt the symmetric key with the public key of the receiver - a compromise between speed and convenience. Jun 17, 2020 at 11:14
  • @PeterHarmann Thanks. I'll take a look at ASN.1. And, yes for now we are leaning to just storing the data as separate properties in a JSON. Jun 17, 2020 at 11:17

3 Answers 3


One of standards is WSSEncryption. A message can be encrypted with symmetric algorithm e.g. AES-128 or AES-256. The encryption key itself can be encrypted with RSA.

Many software products support it out of the box. For instance, if you prefer Java EE, you may want to use WildFly or WebSphere Application Server. If you prefer C#, use WCF.

The web service standards WSSEncryption, WS-Security and SOAP in general are widely used and provide very good interoperability. Every party can use any platform it prefers. E.g. one party can use WildFly, the other WCF, and client on one one platform can consume web service implemented on another platform and vice versa.

  • Thanks. I did look into WS-Sec and it does capture what we want to do although I was hoping for something that I don't have to layer the whole SOAP stack on top of. But we might still end up using it if there is nothing more suitable. Jun 17, 2020 at 11:19
  • @ГеоргиКременлиев: It may seem easy, that if one understands the idea of particular encryption scheme, also the implementation can be easy. But actually a proper implementation of encryption is never a simple and easy task. For instance, what if one party supports AES-128, AES-192 and AES-256, where as the other only AES-128? You would need some protocol to agree that. Other thing: Certificate revocation. Etc. That's why SOAP stack implementations can reduce the amount of needed work. But you decide of course what is better in your case.
    – mentallurg
    Jun 17, 2020 at 11:28

It appears that JWE (RFC 7516) defines exactly that - meta + symmetric key + ciphertext format.


I don't understand why you think OpenPGP is 'implementation specific' -- it is the opened specification of what started out long ago as a single product, and there are now numerous implementations that interoperate fine precisely because the spec is open. Howsoever, ...

The classic solution to this problem started out as part of Public Key Cryptography Standard #7 from then-RSA Labs, later republished as rfc2315 -- specifically the EnvelopedData type (structure) in section 10. PKCS7 was turned over to IETF which renamed it Cryptographic Message Syntax and progressively enhanced it (rfc2630, rfc3369, rfc28562, and rfc5652) while remaining mostly compatible, in much the same way Netscape SSL became IETF TLS. These are based on ASN.1, itself a somewhat complicated standard that some people have had difficulty implementing; just google "ASN.1 vulnerability". And they normally manage keys using X.509 certificates (or at least PKIX, which is the Internet 'version' of X.509), which have also proven difficult for some people, although it is possible to use PKCS7/CMS without certs if you work at it.

Although CMS can be used by itself, it is also used as the basis for S/MIME -- a format for encrypted and/or signed email. MIME (Multipurpose Internet Mail Extensions) was created originally to handle non-textual material in email (like pictures, sounds, and video) but has evolved to handle almost any type or format of data, and S/MIME consists essentially of using CMS messages as the content for MIME emails. Because of the popularity of email, you might more easily find or get access to software doing S/MIME than raw CMS, even though in terms of security functionality they are identical.

  • thanks for the answer. after a bit more searching I found that indeed there are plenty of standards for this problem: OpenPGP, WSSec, XmlEnc, JWE, S/MIME, CMS. Precisely because there are many such standards it is not 100% clear which one is applicable in which case. Jul 23, 2020 at 11:59
  • I see your concern with PGP was really application (email) not implementation. Yes PGP was motivated by email (as were PEM and S/MIME) but it is technically fine for other things. For example, PGP signatures are widely used to protect code in most Linux distros and much other free software. I don't know any similarly widespread use of PGP encryption, but there are dozens of Qs on several Stacks by people who want to use openssl enc for encrypting backups etc and are told "openssl enc is terrible horrendous awful for security, if you want commandline use gpg". Jul 28, 2020 at 2:03
  • That said, JWE is fine too, and if you're already using JSON that makes it more convenient. Jul 28, 2020 at 2:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .