I never thought I'd see a browser support list that specifically includes "Dilo" or, in the last few years, "Internet Explorer", but apparently you're comprehensive.
I went to look for unauthenticated CBC mode like every time I see this sort of thing but it's actually GCM mode so, well consider me surprised.
I built something similar, but mine used asymetric encryption.
It allowed people encrypt files and then the only person that can decrypt is the person with the private key, which may or may not be the person the encrypted the file.
It's about as idiot-proof as you can get IMO. In my decades of IT roles, I have come across a shocking amount of people that cannot operate a ZIP file to save their life.
Remember, these are people that cannot even find the files they have already downloaded, and then you check their downloads folder and there's 12 copies of it in there.
Note for browser UX people: The default flow for most browsers saving files doesn't actually tell you what is happening, it just... disappears into the ether as far as non-tech users are concerned. Can we fix this somehow?
Author here. For the main use case that motivated my building this (securely sharing sensitive-ish data with non-technical people), yes, a ZIP file may have been preferable. That is what I was using before making this.
ZIP files can use two types of encryption, ZipCrypto or AES. As the sibling comment points out, ZipCrypto is pretty broken. IIRC the AES encryption is OK or mostly OK, but it's not universally supported, so your recipient may or may not be able to open the file you send them. Notably, the Windows built-in ZIP implementation didn't support ZipCrypto (this may have changed now that Windows ships with bsdtar / libarchive).
Subjectively, I feel this can be simpler to use (mostly for the recipient). You can host it at some server, share the link and the password and the recipient can access it like a regular website and get a plaintext download file. Compare that with a ZIP file, which with the same flow give you a ZIP download: if they don't immediately extract it, then they may have to hunt for the password later.
That being said, I can see this being useful for a similar use case where encrypted ZIPs are useful. When malware testing, you sometimes want to avoid accidentally running the malware or exposing it to antivirus software until briefly before testing begins. Encrypted zips (as well as simple transformations like ROT13 or reversing the bytes in the file) can help control the moment the malware is unleashed. This HTML based tool could be useful for doing this in network sandboxed systems, with the specific property that it's testing the antivirus behavior when the file is marked as browser downloaded.
Yeah, I was inspired by self-extracting archives. I wanted to share files with basically no dependencies.
The goal was:
1. Something that didn't require any installation (assuming a web browser)
2. Have a single file with no network that could self-decrypt
3. Be fully auditable
The second point is done by having (sort of(*)) reproducible builds and embedded OpenPGP signatures.
The first point is made by cleverly manipulating the HTML structure so that it can decrypt without breaking the PGP signature. It can even decrypt using bare openssl (which was a design goal too, though getting the exact structure right took some work and bug reports).
The third point is accomplished by the first two, and by the source being freely available.
Isnt use of typescript, svelte etc unnecessary.
Been using a bookmarklet for decade for this purpose sharing encrypted text or files. Keep the bookmarklet hosted in git.
I mean, basing this on HTML arguably mitigates the portability and vulnerability concerns, but the problem of trusting the decrypted contents still remains.
Good article, thanks for sharing! I agree with the claims it makes _and_ the reasoning behind them.
This was motivated for situations where using GPG just isn't practical. The issue is that there are very limited options to share a file securely without needing to install additional software (ZIP files come close to this, with some important caveats).
As I was making this, I tried to mitigate many of the concerns raised in that article. For example:
> ask for an file that can be decrypted with an ordinary standalone decryption tool
You don't need to run the self-decryption code at all. You can use 'ordinary' tools like `openssl` to decrypt the contents (note to self, add the `openssl` instructions to the `<noscript>` rendering).
> People who publish decryption tools expend effort to ensure that recipients can trust the actual decryption tools themselves before running them.
You _can_ verify the integrity of the tool itself using gpg. Since you can't verify the entire HTML file (otherwise, you wouldn't be able to inject the encrypted payload), there's ways a malicious actor could add additional scripts and still pass the integrity check. However, if you're diligent enough to be using gpg to check this, you'd likely also be diligent enough to spot such additions, or you'd be using the openssl route.
I never thought I'd see a browser support list that specifically includes "Dilo" or, in the last few years, "Internet Explorer", but apparently you're comprehensive.
I went to look for unauthenticated CBC mode like every time I see this sort of thing but it's actually GCM mode so, well consider me surprised.
It does say Dillo is unsupported, though! Which is a shame. No mention of Mothra…
Mothra intentionally does not support this
I assume the "air gapped" part is merely indicating no internet required?
Offline would be a better word.
A version of this that supported PKE would be cool. So you don't have to share a password in a side channel
I built something similar, but mine used asymetric encryption.
It allowed people encrypt files and then the only person that can decrypt is the person with the private key, which may or may not be the person the encrypted the file.
Came up with something similar a for myself: https://mprimi.github.io/portable-secret/ it was well liked by HN: https://news.ycombinator.com/item?id=34083366
cool project!
also does everyone have to enable js to vote, or did i troll too hard? (sorry!)
Is there a scenario where this solution would be preferable to an encrypted zip archive?
My guess is some heavily locked down systems. But perhaps there is more?
It's about as idiot-proof as you can get IMO. In my decades of IT roles, I have come across a shocking amount of people that cannot operate a ZIP file to save their life.
Remember, these are people that cannot even find the files they have already downloaded, and then you check their downloads folder and there's 12 copies of it in there.
Note for browser UX people: The default flow for most browsers saving files doesn't actually tell you what is happening, it just... disappears into the ether as far as non-tech users are concerned. Can we fix this somehow?
Author here. For the main use case that motivated my building this (securely sharing sensitive-ish data with non-technical people), yes, a ZIP file may have been preferable. That is what I was using before making this.
ZIP files can use two types of encryption, ZipCrypto or AES. As the sibling comment points out, ZipCrypto is pretty broken. IIRC the AES encryption is OK or mostly OK, but it's not universally supported, so your recipient may or may not be able to open the file you send them. Notably, the Windows built-in ZIP implementation didn't support ZipCrypto (this may have changed now that Windows ships with bsdtar / libarchive).
Subjectively, I feel this can be simpler to use (mostly for the recipient). You can host it at some server, share the link and the password and the recipient can access it like a regular website and get a plaintext download file. Compare that with a ZIP file, which with the same flow give you a ZIP download: if they don't immediately extract it, then they may have to hunt for the password later.
ZIP encryption is quite flawed.
That being said, I can see this being useful for a similar use case where encrypted ZIPs are useful. When malware testing, you sometimes want to avoid accidentally running the malware or exposing it to antivirus software until briefly before testing begins. Encrypted zips (as well as simple transformations like ROT13 or reversing the bytes in the file) can help control the moment the malware is unleashed. This HTML based tool could be useful for doing this in network sandboxed systems, with the specific property that it's testing the antivirus behavior when the file is marked as browser downloaded.
Wonder if there's a scenario where this also works for PQC ML-KEM
This is brilliant. Keen to try it out.
Great idea :)
Self-decrypting HTML? That's an innovative approach.
Yeah, I was inspired by self-extracting archives. I wanted to share files with basically no dependencies.
The goal was:
1. Something that didn't require any installation (assuming a web browser)
2. Have a single file with no network that could self-decrypt
3. Be fully auditable
The second point is done by having (sort of(*)) reproducible builds and embedded OpenPGP signatures.
The first point is made by cleverly manipulating the HTML structure so that it can decrypt without breaking the PGP signature. It can even decrypt using bare openssl (which was a design goal too, though getting the exact structure right took some work and bug reports).
The third point is accomplished by the first two, and by the source being freely available.
(*) Depends on the OS at the moment.
I'm going to move this description to the top and re-up the post - I hope that's ok!
Somebody already has copied this innovative approach and travelled to past apparently: https://acme.com/software/securepage/
Methods like these go way further back than 2010... I recall one that had a reward promised if you could break it.
EDIT: Here's a patent from 2006 [0]
[0] https://image-ppubs.uspto.gov/dirsearch-public/print/downloa...
Here's one I remember: http://jgae.de/sdaeng.htm
From here: https://pajhome.org.uk/crypt/md5/uses.html#sdp
I used this many years ago, like literally 20 years ago. And it appears to have had a bounty! Maybe it is what you recall as well!
Once upon a time, 1password (macOS pwd manager) vault files could be opened standalone in a browser, which was extremely nifty.
Isnt use of typescript, svelte etc unnecessary. Been using a bookmarklet for decade for this purpose sharing encrypted text or files. Keep the bookmarklet hosted in git.
I never expected to find a circumstance in which this article would be relevant, but here I am.
https://jdebp.uk/FGA/dont-use-self-decrypting-files.html
I mean, basing this on HTML arguably mitigates the portability and vulnerability concerns, but the problem of trusting the decrypted contents still remains.
Good article, thanks for sharing! I agree with the claims it makes _and_ the reasoning behind them.
This was motivated for situations where using GPG just isn't practical. The issue is that there are very limited options to share a file securely without needing to install additional software (ZIP files come close to this, with some important caveats).
As I was making this, I tried to mitigate many of the concerns raised in that article. For example:
> ask for an file that can be decrypted with an ordinary standalone decryption tool
You don't need to run the self-decryption code at all. You can use 'ordinary' tools like `openssl` to decrypt the contents (note to self, add the `openssl` instructions to the `<noscript>` rendering).
> People who publish decryption tools expend effort to ensure that recipients can trust the actual decryption tools themselves before running them.
You _can_ verify the integrity of the tool itself using gpg. Since you can't verify the entire HTML file (otherwise, you wouldn't be able to inject the encrypted payload), there's ways a malicious actor could add additional scripts and still pass the integrity check. However, if you're diligent enough to be using gpg to check this, you'd likely also be diligent enough to spot such additions, or you'd be using the openssl route.
Good to know. Thank you for sharing this!
This is great!
Lol @ "airgapped".
Maybe this is the source?
https://github.com/ApelegHQ/ts-cms-ep-sfx
Added above. Thanks!
Correct
Cool!