Why is there no standard encryption file format?

Question

When encrypting strings or files, application developers have to make choices about what cipher/mode to use, where to store the IV and how to represent all of that in the database or on disk. This is annoying at best, but also leads to errors.I've searched for RFCs but I couldn't find any standard, and not even a defacto standard. Why does this not exist? Am I missing something?If we had such a format, libraries could define a simple "encrypt()" function that would pick today's suggested cipher spec (e.g. AES128/GCM), but could provide backwards compatibility for the corresponding "decrypt()" function -- similar to hash mechanisms supporting the crypt syntax ($2y$...) such as PHP's password_hash().I've defined such a format before for an open source project I worked on years ago [1], so I don't think it would be hard to define a standard like this. Am I overlooking something here?[1] scroll down to "crypto file format" - https://syncany.readthedocs.io/en/latest/security.html#encrypting-new-files

badrabbit · Accepted Answer

Been down this road. GPG exists for that purpose. Although not intednded for disk files,s/mime has cross platform support as well.
To answer your question,interoperability with other applications is neither expected nor desired for most apps that store encrypted data in a file. Quite often there are additional implementation details to be included (for which AEAD supportig cipher modes account for).
Let's say I encrypt outputs of my program and store them in a file,I will most likely serialize it,encrypt it and store it only caring about my app being able to read and deserialize it. There is mostly no need for interoperability for data-at-rest encryption since there are a lot of interoperable protocols for data-in-transit encryption. I do think it would not hurt to have something like .gpg but more srandardized and easy to implement.

verdverm · Answer

Implementation matters and the same cipher may be good in one language and broken in another.What happens when I cipher becomes exploitable? How would you re-encrypt with only a single en/decrypt functions? Which cipher was originally used?

binwiederhier · Answer

This is obviously not a spec, but it's as close as it gets to the API that I would like. And it's got Daniel Bleichenbacher listed as author so it's got my vote. I couldn't find any on disk spec though at all though which is a little odd: https://github.com/google/tinkVery cool project.

jolmg · Answer

> I've searched for RFCs but I couldn't find any standard, and not even a defacto standard.How about RFC 4880 - OpenPGP Message Format[1]?[1] https://tools.ietf.org/html/rfc4880

Why is there no standard encryption file format?

Implementation matters and the same cipher may be good in one language and broken in another.
What happens when I cipher becomes exploitable? How would you re-encrypt with only a single en/decrypt functions? Which cipher was originally used?

This is obviously not a spec, but it's as close as it gets to the API that I would like. And it's got Daniel Bleichenbacher listed as author so it's got my vote. I couldn't find any on disk spec though at all though which is a little odd: https://github.com/google/tink
Very cool project.

> I've searched for RFCs but I couldn't find any standard, and not even a defacto standard.
How about RFC 4880 - OpenPGP Message Format[1]?
[1] https://tools.ietf.org/html/rfc4880