hardbin

It's not my API, it's the standard IPFS writable gateway API, documented here: https://discuss.ipfs.io/t/writeable-http-gateways/210 And there's an example usage here: https://github.com/jes/hardbin/blob/master/js/hardbin.js#L25 There is currently a bug which means you first need to DELETE the filename (in my case "content") that you are trying to replace if it already exists, but apart from that it is straightforward. I started fixing the bug here https://github.com/ipfs/go-ipfs/pull/3931 but ran out of steam - hopefully I'll continue soon.

I'm not deeply familiar with IPFS, but on a cursory look it appears to be accurate that it optionally[1] offers authentication via HMAC for file objects. Can you indicate how this works in hardbin? I don't see any mention of it in the GitHub readme - is it activated by default or is it assumed that a user has it activated in their own copy of IPFS? Also, while I have you, I recommend you use SJCL for generating random bytes in response to this: https://github.com/jes/hardbin/issues/1.[2] On a meta note, can I ask why you didn't go with something like Tahoe-Lafs[3] if you were looking for a secure, decentralized file store system? I don't immediately know that it would have been better per se, but I'm not quite sure what IPFS provides that you can't get otherwise. EDIT: I'm not trying to grief you here, but there are three people in this t

https://github.com/jes/hardbin/issues/1 You don't exactly need clairvoyance to predict this outcome.

A quick look at the source code shows the generate_key() function [0] to be insecure. It generates 32 random bytes (good, that's what you need for an AES-256 key), but then it uses those random bytes to sample from a distribution which only has 62 characters. This significantly reduces the security of the key, from 256 bits of entropy to ~190 bits (log2(62^32)). And that would be in the best case, if it were sampling uniformly from the distribution - it is not. I recommend reading Section 9.7 of Cryptography Engineering [1] to understand why choosing random elements from a set is harder than it seems. A good example of a similar bug is the nasty bug in Cryptocat's PRNG from 2013 [2]. I assume this step was done so the AES key could be included in the URL fragment, since a set of random bytes may not be url safe. I recommend feeding the ra