HelloZeroNet / HelloZeroNet/ZeroNet

Content Encryption

Offen
#252 14 Kommentare 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
JavaScript
Sterne
18.8k
Forks
2.3k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

Would it be possible to store the content being served by peers in encrypted form and decrypted on the fly when it is served?

Potential scenario:

Peers situated in a country that favours censorship are serving up HTTP content over SSL to other clients: transmission is protected over the wire. But what happens in the case where a peer unit (laptop, PC etc - i.e. publishers) are subject to physical seizure by hostile or state actors? For example, A Zeronet site is created to share pictures of the Tiananmen square demonstrations, curated and served by Chinese nodes. Peers are identified by IP, traced through their ISP, and the equipment used to serve the content subsequently confiscated by censors.

In this case, it's highly likely that peers would be incriminated as _publishers_ of material (more severely punishable and increasingly risky), - rather than just viewers - , if identified by IP. The Tiananmen problem given above is provocative enough that even a static JPG could put a peer at risk of a criminal offence in that jurisdiction, and the recording of the IP on the network would be incriminating.

However, if those actors managed to isolate a machine, but were unable to access the locally-stored files being served upon physical seizure, - as they were encrypted - , it would make the process harder to show what they were publishing in the first place (save for being forced to provide their private key). The HTTP server itself would need to decrypt on the fly to serve them out, obviously, but little software exists to do it.

The solution suggested here...
http://stackoverflow.com/questions/4418588/webserver-on-the-fly-decrypting

...is the AES provision within G-Wan:
http://gwan.com/api#crypto

Or would it be wiser to take a longer-form approach like Protonmail, and serve the material for decryption exclusively on the client, to avoid the possibility of compromising the private key as part of the machine seizure?

Is this a realistically achievable goal that could be included on the software's roadmap at some point?

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.