# Which Cryptographic Standard ensures cryptographic agility and good adapotion

Which Cryptographic Message Standards are recommended to ensure cryptographic agility in the future and good adapotion trough different programming languages (.NET and Go)? (PublicKey with authenticated symetric encryption)

I doesn'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?

### Update

Application: is local installed and sends encrypted data over HTTPS with TLS Auth. to a service in the cloud, but data will be encrypted locally on-prem and not in cloud. One message is around 5kb-2MB and around 100-2.000 messeages 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.

• 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. – brynk Oct 31 '20 at 20:47
• PKCS7 is now CMS (and S/MIME), and PGP is another option; see security.stackexchange.com/questions/233290/… . – dave_thompson_085 Nov 5 '20 at 1:04
• 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? – brynk Nov 6 '20 at 6:48
• @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. – hdev Nov 9 '20 at 8:45
• @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) – brynk Nov 9 '20 at 21:07