3 ms·

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 yo

• jstanley 9y ago
  There is no HMAC used in Hardbin. You have to trust that the IPFS path you are accessing is correct, otherwise all bets are off. The code and data are served out of the same place. Anybody who can modify the data can modify the code. There is no benefit whatsoever from trying to do any more authentication. I'll have a look at SJCL, thanks. I've not played with Tahoe-LAFS, I don't know anything about it. I fully intend to fix the non-uniform key generation. That is a bug. I'm yet to hear a convincing argument that the unauthenticated encryption is a problem.
  • dsacco 9y ago
    Ah, I understand, thanks for clearing that up. So each IPFS node in your connection path must support data authentication. I have two suggestions, then: 1. Implement data integrity and authentication directly in Hardbin, instead of offloading it to IPFS, such that it can be used with both confidentiality and integrity even if assumed-hostile nodes are part of the connection path. To do this I'd recommend using HMAC-SHA256 for authentication, and AES-CBC is probably fine for the encryption. You could combine the authentication and encryption with something like AES-GCM or AES-OCB, but I personally wouldn't do that. 2. Explicitly state upfront and center in the readme that Hardbin is currently abstracting the duty of authentication and integrity to IPFS using that sort of terminology. Now it's clear to me why you're saying that an untrusted IPFS path shouldn't be used, but if you used that sort of language it would be more "formally" expressed cryptographically speaking. The fact that you're mentioning that attackers cannot manipulate files but not explicitly describing how authentication works (e.g. as you do with encryption) is an antipattern. There's a bit of a runaround here - Hardbin is designed to be an "encrypted, secure pastebin", but Pastebin is inherently an antagonistic medium for file authentication, which you'll really need for file integrity. It's designed to be fairly anonymous, which you have to trade off in some way if you want real file integrity. The difficulty in this is that "encryption" on its own only offers confidentiality, and in modern cryptography that level of assurance is relatively rarely used in complete cryptosystems. It's not necessarily helpful to have confidentiality across a connection without also having integrity. So you can add decentralized components and encryption to it via Hardbin, but (in my opinion), you're not significantly adding a ton of value to it because I'm not really clear what the use case is where you want to securely share files in a decentralized manner, but you also don't really mind if the files are not protected against manipulation.
    • jstanley 9y ago
      > Ah, I understand, thanks for clearing that up. So each IPFS node in your connection path must support data authentication. No, I still think you don't understand. You only need to trust your local node. If another node on the path modifies the data, your local node will reject it because it won't match the hash. Content is addressed in IPFS by its content hash. The Hardbin "URLs" are content hashes. EDIT: I see the confusion! When I said you need to trust the "IPFS path", I was talking about a path like "/ipfs/QmXyE...". Not a connection path. You need to trust the IPFS path (i.e. content hash), and your local node, but nothing else.
      • dsacco 9y ago
        Ahhh...so basically, this is a system where you inherently trust the integrity only of your own computer. Yes, sorry about that I misunderstood what you meant when you used "connection"...in my head I'm thinking of stateful networks, not a filesystem.
        • jstanley 9y ago
          That's it, yes.