That's a very interesting concept of a cross-platform self-unpacking archive. Unfortunately it requires the C compiler binary which is missing on the Windows platform out of the box. Perhaps some kind of tiny C compiler or interpreter windows binary might be bundled along for 99% compatibility.
I know that the RAR format, for one, effectively embeds the compensating decompression program for whatever it did into the archive, in the form of some bytecode for a VM with an ABI that has been stable since RAR was created. So RAR has actually been a bunch of different algorithms over time, but unrar(1) doesn't need to care; it just runs the embedded program in its VM. (Most exciting fact: this means that older versions of the program can decompress archives created by newer versions, using algorithms that didn't exist at the time the older version shipped!)
It would definitely be possible to do the equivalent for encryption. The main problem† being that while compression algorithms get outmoded, encryption algorithms break. This is true of all encryption, but it's especially scary when you can just scan a disk and signature-identify crackable files by the embedded algorithm.
So, if you were going to do something like this, you'd probably want a higher-level abstraction than "self-describing encrypted file"; maybe something more like a "self-describing encrypted mutable volume." Mutable so that it would (hopefully) get an update() operation called on it at least every so often (even if just from a fsck-during-mount), letting it start a background process to change out an old-and-broken backing-store encryption algorithm for a new-and-trusted one (think of how bcrypt handles strength changes.)
---
† There's also the performance problem: if you have a stable ABI, and it was frozen 20 years ago, how would you ever do something like elliptic-curve operations efficiently? Heck, doesn't using a frozen ABI mean you couldn't make use of a modern processor's native instructions for RSA ciphering et al?
The answer to this, I think, is VM-runtime instruction-level pattern-recognition ala urbit's "jets". The new version of the encryption program would prepend a program for the stable ABI, that tells the old version how to (inefficiently) implement elliptic-curve decryption in terms of things it understands. However, running this program against a new version of the decryption VM would recognize the signature/pattern of "what elliptic-curve decryption instructions encoded in [this VM]'s ABI" looks like, and execute a native procedure with the same preconditions and postconditions as that instruction-sequence instead. Sort of like typehints for a JIT, but where the instruction-sequences themselves are the hints, since they have canonical forms.
