Good Morning Guys, I'm currently looking into the Project Maelstorm (BitTorrent Peer-To-Peer Web Browser Project), and a question popped up in mind.

When on a P2P network, users share the file which originated from a single source, once the first user has downloaded the source, a hash check can be used to assure the file being transmitted by that user is not a modified one (With more users, this also blocks MITM attacks, because you can compare a big amount of hashes and see if they match before trusting anyone).

Now comes my question(s):

  • 1: What about server-side scripts? For instance, let's say I have a website with a login page, how would my login-password info be checked? If that required a main server, we are no longer on a peer-to-peer web, if the database files were also transferred with the main website structure, wouldn't that be:

    • A: Insecure? Passwords can be hashed, but what about personal information? (Which is needed on the website, for instance, your address on facebook?).
    • B: Slow? Since a database can get constant updates (Let's think about 1.5k users updating their profiles constantly), that would need constant file hash re-check, consuming a lot of data on both ends.
  • 2: DDoSes and Takedowns would be sent against what? The essence of P2P is to block both of these, if there was still a server-client way for data transferring, wouldn't that be easy for somone to DDOS the database server? And for govnt/isps to send takedown notices to database server hosts?

Thank you and have a good day. - Fabricio20

  • You can do quite a lot with just static files and distributed hash table. Look at Freenet, which I think Project Maelstrom is trying to reinvent. – Lie Ryan Jan 4 '16 at 0:34
up vote 6 down vote accepted

I've given a lot of thought to this area over the past couple of years, and the simplest answer to both of your questions is that a wholly peer-to-peer web would introduce new ways of handling those processes which would traditionally reside on a server. Peer-to-peer websites would most likely not be served with the data inline. Sort of like Meteor, you would probably work with one version of the static website files, and those files would include scripts that run on the client side to populate the page with data and send commands/requests to an external "server" as needed. In a peer-to-peer web, the server would be more like an entire public network of users.

Think about a website like Facebook. What do you achieve by logging in and holding a session? Firstly, you gain access to all the private information that you are authorized to see. Traditionally, your session cookie is all the authentication needed in a request to access private data.

But in a true peer-to-peer infrastructure, who holds this private data to begin with? Well, it should be other peers like you. Even if you can prove your identity to a peer, they shouldn't be handling any of your private data in plaintext. Thus, encryption should be a huge part of any secure peer-to-peer web. When data is encrypted properly and keys are handled with care, proof of identity is less essential: if you can decrypt the data, you are implicitly authorized to access it.

Back to the Facebook example, sharing private information could be done by transmitting the decryption key to contacts whom you wish to authorize. The closest measure to revoking access would then be to either remove the data altogether, or re-encrypt and transmit a new key to all remaining contacts who are authorized. To encrypt data for a particular contact, the peer-to-peer network would probably utilize public-key cryptography: pull the public key of a contact, then use it to encrypt any private transmissions. With thoughtful crypto, the messages could be stored in a peer-to-peer network without any concern about tampering or eavesdropping.

Of course, authentication goes beyond access rights. On the real and traditional Facebook, your valid session enables you to act under your own identity: if you post something on your wall, any other user will implicitly trust that it was your doing. You can replicate this sort of thing, and with considerably greater certainty, using digital signatures for message authentication on the fly. The process of authenticating any information on the site as valid would occur on the client side, and no unsigned posts would be shown because there would be no valid information about the author.

Because information would move about the network indiscriminately, any distributed file sharing system should make for a fine foundation on which to implement an infrastructure like this. Denial of service should, in theory, be a tall order. There are a lot of pros and cons to governing privacy with cryptography alone, but it is far more true to life at the end of the day. There would be no one to subpoena for relinquishment or cessation except the users themselves (might be anonymous), and it comes with more integrity at every corner.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.