Which cryptographic message standards are recommended to ensure cryptographic agility in the future and have good adoption trough different programming languages such as .NET and Go?

The standard should be a hybrid cryptosystem using a Public Key Infrastructure as well as authenticated symmetric encryption.

I don't want handle to cryptographic primitives myself, but rather I want to handle facade which protects more or less from small mistakes.

I found these different Standards, in which my experience varies:

  • PKCS #7 (Old standard, suitable for the future?)
  • NaCl crypto_box (Fixed primitives and limited message size)
  • JSON Web Encryption (JWE) (JWS is very well established, but not JWE)
  • XML Encryption Syntax and Processing Version 1.1 (Large overhead trough use of XML)

Are some worth mentioning missing? Which would be recommend for a future proof application?


Application: is local installed and sends encrypted data over HTTPS with TLS authentication. to a service in the cloud, but data will be encrypted locally on-premise and not in cloud. One message is around 5kb-2MB and around 100-2.000 messages per day. Crypt primitives should be fast, around ~50ms.

Constraints: Must be compatible with BSI TR-02102 and should be compatible with BSI recommendations (written in German) for the migration to post-quantum cryptography.

  • 3
    $\begingroup$ You haven't said much about the application itself: what are your goals? requirements? constraints? ... and an observation: you are implementing the interface, so you are in control of the specification, therefore, you can re-implement when your chosen primitive or core dependency needs to change, and increment your binary version ident, rather than add cryptographic malleability into your protocol up-front... there are sound technical reasons to fix the primitives and limit the message size. $\endgroup$
    – brynk
    Oct 31, 2020 at 20:47
  • $\begingroup$ PKCS7 is now CMS (and S/MIME), and PGP is another option; see security.stackexchange.com/questions/233290/… . $\endgroup$ Nov 5, 2020 at 1:04
  • $\begingroup$ BSI TR-02102-1 (Rec's and Key Lengths) narrows your search by specifying the block cipher as aes256, and modes of operation to gcm/ ccm/ cbc/ ctr (see s2.1), and be aware of the constraints around nonces, specifically: 2^32 "at most" per key (p23) if it is random, or guaranteed never to repeat for the life of the key if deterministic. Also, on post-quantum resistance, (p31) notes: "may be strengthened by the use of a pre-shared symmetric secret ... using such a secret as part of a key exchange" which avoids the provisions in s3.2 Q: can you provide key material on a separate channel? $\endgroup$
    – brynk
    Nov 6, 2020 at 6:48
  • $\begingroup$ @brynk a pre-shared symmetric secret could be possible, because customer has a cert for mTLS. So I could add a psk to this customer related file. $\endgroup$
    – hdev
    Nov 9, 2020 at 8:45
  • 1
    $\begingroup$ @dhcgn the pre-shared key might allow you to avoid s3.2 in TR-02102-1, but only if you exchanged the storage key over this channel after it was established; if you could assert this, then this opens up any number of options for you wrt. wrappers for encrypted data-at-rest, but outside my experience - afaik NaCl/ libsodium's cryptobox constructs both rely on salsa20/ chacha20, which are precluded by (s2.1) if you wish to stick to recc's - this could interest as a format-specification: github.com/awslabs/aws-encryption-sdk-specification (unfortunately no go-lang or .net impl yet) $\endgroup$
    – brynk
    Nov 9, 2020 at 21:07

1 Answer 1


All but NaCl allow you to specify algorithms, but none of them would allow you to specify an algorithm that is part of the Post Quantum Cryptography initiatives yet (which, although unmentioned in the question, would be a very good reason to have crypto-agility).

For classic cryptography and a relatively high resistance against quantum computers, all those allow for RSA key encapsulation (including RSA-OAEP) and 256 bit AES as primitives. So using an RSA key pair of, say 4096 bits, will allow you to have a pretty good resistance against anything but a full featured quantum computer with more than 8192 logical qubits.

Otherwise I'd make sure that I would use a standard that is practical for you, that has a mature, well maintained library and is checked for e.g. side channel attacks. That's also something that's a good property of CMS; it may be old, but there is little wrong with maturity when it comes to choosing a library.

  • $\begingroup$ Is there a suitable format which isn't mentioned yet? $\endgroup$
    – hdev
    Nov 4, 2020 at 12:47

Your Answer

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

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