Fri 19 May 2017
Over the past week I've been working on hardbin. Hardbin is an encrypted pastebin, with the decryption key passed in the URL fragment, and the code and data served securely with IPFS. (IPFS is a distributed content-addressable storage system that is web-compatible; it's basically bittorrent for the web).
You can play with hardbin on the hardbin.com public IPFS gateway here.
If you like, you can view a paste via the ipfs.io public gateway at https://ipfs.io/ipfs/QmWaHbpkokQvEN7ScqGDZFLDepY3ZsoCk3omg7fvHXinRq/#EkyreKl72W0hStVIQ07qsKb6nVNH23GP.
You can read a bit more in README.md on the github repo..
IPFS is a protocol that, given a content hash, can retrieve the corresponding content from any node on the network, and verify that it got the correct content (because the hash is correct). Nodes can "pin" content to make sure it stays around, and nodes cache any content that they retrieve. In this manner it is analogous to bittorrent.
Unlike traditional web URLs, IPFS content is retrieved by specifying the content hash, rather than the location at which the content can be found. This has some interesting trade-offs: you can't change content after-the-fact, but nobody else can change content after-the-fact either, content can still be reachable even if the original hoster goes offline, and high-traffic content doesn't need a CDN as the entire network acts as a CDN.
Hardbin is a single-page web app implementing an encrypted pastebin. There is no server component, it relies entirely on IPFS for content delivery and storage. The hardbin code and data are both stored in IPFS.
To publish a new paste, hardbin publishes a new copy of itself, bundled with the encrypted paste data. The decryption key is passed in the URL fragment so that it never hits the network.
An IPFS gateway is a web server that provides an interface to the IPFS network for web browsers (and other HTTP(S) clients) to use.
A writable IPFS gateway also provides a mechanism to publish new content to the network.
No IPFS gateway has any more authority than any other, but you need to make sure not to use a gateway you don't trust as the gateway is able to modify the content it is returning.
A local gateway means you're not trusting a remote server to correctly return IPFS content. It is super easy to run a local gateway. Start with the IPFS Getting Started guide.
Hardbin.com is a public writable IPFS gateway. I am operating it to make the hardbin user experience smoother, but there is no reason it can't be used as a generic IPFS gateway for any application.
I'm not sure how robust it is so it might keel over if people actually start using it. You should all be using a local gateway anyway though :).
The root URL on hardbin.com redirects to the current latest IPFS hash for the hardbin application.
Most public IPFS gateways are not writable, although there is little reason for this to be the case and I expect it to change in the future.
By leveraging IPFS, hardbin gets cryptographic verification of code and data for free. As long as a correct hash is used, and the gateway is not compromised, the code and data are delivered correctly.
Hardbin uses the writable gateway API to store content.
All of the rest of the code runs client-side.
This also means there is no maintenance burden associated with running the server (unless you opt to operate your own public gateway). And it means even if the original server operator disappears, the users can continue using the software uninterrupted.
There is nothing stopping you from making improvements to hardbin, pinning your version on an IPFS node (or with IPFSstore), and then sharing pastes using your custom version of hardbin. You can even use the hardbin.com public gateway.
When used on a local gateway, hardbin has very strong security properties. Even though the code could be served from anywhere in the world, you can trust it just as much as if you were running it locally.
When used on a non-local gateway, hardbin still works perfectly fine, but the trust model degrades to be the same as that of a traditional encrypted pastebin (you have to trust the server operator).
When viewing pastes on a non-writable gateway, hardbin works perfectly fine. When you try to create a new paste, hardbin checks whether the gateway is writable, and pops up a message with instructions if it is not writable.
Due to the nature of IPFS paths, the URLs are long. There's no getting around this. They're made even longer by incorporating a decryption key at the end. The key is 32 characters long and provides approximately 190 bits of keyspace. This could probably be reduced with little ill effect, but the length of the IPFS hash dominates anyway so the improvement would be minimal.
The flip-side of being able to publish arbitrary modifications is that there is nothing visible to distinguish malicious versions of the code from legitimate ones.
To mitigate this sort of attack, make sure you are using a known-good IPFS hash (the path in the URL). Ideally, write down the hash the first time you use it, audit the code to make sure you're happy with it, and only use that hash. Certainly do not trust arbitrary hashes you receive from people you don't trust.
Please also get in touch to report any issues or confusion you have. I want this stuff to be as easy to understand as possible, and I want to find out which parts are hard to understand.
Thanks for reading.If you like my blog, please consider subscribing to the RSS feed or the mailing list: