# Standard serialization format for libsodium-based messages

Does anyone know of a standardized serialization format which can be (or already is) widely used for encrypted messages? For a variety of reasons (mostly complexity, age and poor support across a lot of languages) we don't want to use OpenPGP for this case.

The use case is fairly simple, we want to create "stateless" (from the server's perspective) authorization token across a wide variety of our web-based applications, without having to implement an OAUTH-handshake as users transition from application to application. The applications are written in a variety of languages, some .NET, some Java, some Node.js, and Python.

It seems a reasonable, modern solution to this problem is to use libsodium's crypto_secretbox_easy to authenticate a user and then encrypt a message of the form:

{identity: 'someuser@example.com', expires: '2015-02-27T09:45:35.886Z'}


...and send it to the client for cookie storage. Assuming secure configuration of keys in all the various applications, we could use the libsodium variants for each platform to authenticate a user based on this encrypted and authenticated token.

The problem, of course, is how to format the message? I need to transmit the nonce as well, but that isn't part of the output of crypto_secretbox_easy, and nothing I've found during research seems to indicate there is a standard serialized message format for use with libsodium. Lots of people are rolling their own.

So, is it safe to use a general cross-platform message serialization library such as MessagePack to transmit a message of the form:

{nonce_value: 0x44ec53c1235daa22d3e0322931ce2d2c47ece2a5ae46a00e,
secretbox_message: 0xa3ce9f0edb35a058eaf90d87f871ecdf6fb7f88ec547f377fdb27780716e1904ab8663dbce724d1bfcc7ee1f40108400}


I know enough about crypto to know "there be dragons" when inventing your own protocols, and assembling crypto primitives naively has repeatedly shown to be disaster. So if there is a standardized and secure way of doing this sort of encrypted and authenticated messaging (other than OpenPGP) I would of course like to use that. If there isn't a modern standard for this task, I ask:

• do you think my proposed construction is secure?
• are there any reasons that general structured serialization libraries are unsuitable for use in cryptographic protocols? Looking at various PGP, TLS, and PKCS specifications, it seems this wheel gets re-invented quite a lot, and I don't quite understand why.
• I'd simply concatenate nonce and ciphertext. – CodesInChaos Feb 27 '15 at 11:26
• @CodesInChaos, that certainly would keep things simple, but the point of using a structured, self-describing serialization library is future-proofing. If other items are added to this "auth cookie" data structure in the future, the amount of code change required is negligible and backwards compatibility is mostly taken care of by the library. I'd hate to have to code every app to start looking for magic strings and/or version numbers in this structure somewhere down the line. – rmalayter Feb 27 '15 at 15:22
• I'd use a simple version number and concatenation outside the box and a serialization library to produce the plaintext on the inside. Since you send this for every request, I'd use some compact encoding for the message (messagepack works if the keys are short) and I'd use (urlsafe) Base64 instead of hex. Finally I'd consider HMAC, since it doesn't require a nonce. – CodesInChaos Feb 27 '15 at 15:25
• I'm voting to close this question as off-topic because it is more about software development and security in general, while it merely borders cryptography as we handle it here. Like our help center states: If your question is about … implementation and practical usage considerations, you probably are looking for Security.SE.. I’ld say that fits in this case as you’re looking to practically implement things. – e-sushi Mar 7 '15 at 20:13
• I'm voting to leave this question open because it is to a large extent about choosing the right kind of cryptographic primitive and passing it appropriate arguments. It isn't just an implementation question but also a cryptographic protocol design question. – Gilles 'SO- stop being evil' Mar 8 '15 at 20:13