Hardbin: The World's Most Secure Encrypted Pastebin
Fri 19 May 2017Tagged: ipfs, cryptography, software
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.
The current IPFS path is /ipfs/QmUGFZAWzWEaHjC1dHAUQ8aKCuKupKsX9vLzhGZV9PLknu/ (liable to become out of date: check on the github repo or hardbin.com if reading this in the future).
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..
Background and overview
IPFS
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
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.
IPFS gateways
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.
Browser extensions like IPFS Gateway Redirect for Firefox and IPFS Station for Chrome can automatically redirect IPFS paths to a local gateway.
hardbin.com
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.
Advantages of hardbin
Cryptographic verification
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.
No server-side code required
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.
Custom modifications are first-class citizens
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.
Graceful degradation
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.
Disadvantages of hardbin
Long URLs
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.
Custom modifications are first-class citizens
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.
Learn more
Other than reading the README.md on github, you can learn more about hardbin by emailing me: james@incoherency.co.uk.
You can learn more about IPFS by following the Getting Started guide, or by emailing me: james@incoherency.co.uk.
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: