All work is performed by the client web-browser; the web host merely serves the files.
Warning: This is only proof-of-concept! Both base-64 encoding and encryption inflate the size of data (by ~35% each). Files larger than 1 megabyte are likely to crash your browser.
Output: Will appear between the rules:
Warning: This page will only be able to interpret Crypto-JS if you enabled Netscape Javascript in your web browser Preferences. Sorry! The author of this web front-end is not affiliated with the developers of Crypto-JS.
Obviously: when using this tool in earnest, do not prepare your URI with the shared secret as a query ¶meter=argument pair. Transmit it to the recipient by some other means.
Privacy: when using this tool, the neocities host will receive and record your search query if you supply one. Consequently, if you supply both a cyphercode and a secret, forensics will be able to decypher your payload. If you navigate to or share a URI which only contains the cypher in the &raw= parameter, and the recipient submits the shared secret into their local browser, form submission does not contact the neocities (or any other) host. The cyper is decrypted locally in the recipient's client. As evidence that the encryption is performed locally (ie, the web host is never made aware of the shared secret during decryption) one can load the page in the web browser, enter Offline Mode from the File menu, disconnect from all networks, and then Submit the form; the transition will execute successfully as there is no dependence on remote connections. As evidence that the algorithm makes no attempt to disclose the secret to third party remote hosts, configure your firewall to confirm all outgoing connection requests. As evidence that the Netscape Javascript files have not been tampered with, download the baseline archive for Crypto-JS v3.1.2, extract the files, generate a directory listing, wget those same files from this website and diff them with your locally extracted master copy. This website stores Crypto-JS at:
/script /components ... /rollups ...
As with everything in the security and privacy domain, trust changes everything. Don't do it. Don't fall into that trap. Do what you do because you have gathered empirical proof sufficient to convince yourself your confidence is well-placed; not because you have naïvely gambled your trust on some anecdotal claims. Learn from a consensus of reputable sources how the algorithm works; download open-source implementations and verify they do what they claim to; encrypt your own user-supplied test string and then come here to validate that this site produces matching output for matching input. No amount of this website claiming it passes unit-testing checks on the specific values I have carefully selected can convince you the algorithm is authentic. Do it yourself.
This site is transported to you via HTTPS. HTTPS is almost always a bad idea because the traffic conveyed is opaque to intermediaries which prevents the entire web caching proxy infrastructure integral to their ISP, your ISP, your router, and your local browser from being able to optimise repeat requests by re-serving from the cache. If you quit your browser, fire it up again and navigate back to this URI, the page will need to be re-transmitted all the way from the origin host. Even though you just had it up a moment ago locally and nothing's changed. That's horribly inefficient. If you ever see websites obstructing access to content with banners and pop-ups justifying the webadmin's choice to spam all their visitors with promotional advertising just to cover the fees for bandwidth service, now you know why. The other problem with HTTPS is that many hosts recently transitioned from SSL to TLS. When this happened, all the embedded devices running a web browser from firmware that cannot be upgraded abruptly lost the ability to communicate with those sites, and due to heavy HTTPS Everywhere promotion, that's just about every site these days. It's a disempowering precedent to set; handing over the keys to an entire generation of smart devices to industry giants to remotely obsolete the moment they have a new line-up to sell.
People blithely talk about "the Web two-point-oh" as if someone "out there" is in charge of revision control over the entire world-wide-web and at some epic epoch hit the big red button which deployed a new, updated version of the heterogeneous web in a state which breaks backward compatibility so substantially that it earnt an entirely fresh major version number. (This isn't what happened; despite the rise of DHTML, Netscape Javascript, CSS and Shockwave Flash, you can navigate and interact with almost all websites these days with JS disabled and no Flash installed; those sites which fail to even load under barebones conditions aren't competently maintained or worthwhile visiting. The web is all about platform independence; authoring sites that only operate viably when rendered by Windows 98 SE running Netscape 4.7 or Internet Exploder 6.1 with Macromedia Flash installed on Tuesday afternoons from timezones with "Q" in their name are antithetical and ought to be boycotted.) That being said, the recent obsession with deploying HTTPS Everywhere is a breaking change (at the API layer; it changes the transport protocol without changing the payload content) of the magnitude that would warrant a major version number increment... if it were ever possible to version control the entire web.
Be that as it may, the fact that HTTPS obstructs any optimising mechanisms attempting to cache content is a perk in this specific circumstance because cyphers decrypted within the page are likewise opaque to caching mechanisms. The user can of course right-click the decrypted content and Save Link As or Save Image As to persist a non-volatile copy of the content. But the browser is unlikely to do that all by itself. Of course, you never know what closed-source software is doing behind the closed doors of its black box implementation. It could be doing anything in parallel with the main effect you expect. Electing to trust intentionally opaque algorithms is entirely optional.