Free Haven - Revision history

Jaekel: /* System Design */

2007-07-17T14:48:10Z

System Design

← Older revision		Revision as of 14:48, 17 July 2007
Line 13:		Line 13:

	==System Design==		==System Design==
	[[Image:Schema1.PNG]]		[[Image:Schema1.PNG\|thumb\|450px]]
	*Kommunikationskanal		*Kommunikationskanal
	**Für anonyme und vertrauliche Kommunikation		**Für anonyme und vertrauliche Kommunikation

Jaekel: /* Robustheit / Verantwortung */

2007-07-17T14:46:06Z

Robustheit / Verantwortung

← Older revision		Revision as of 14:46, 17 July 2007
Line 53:		Line 53:
	Nachdem wir den Public Key des gewünschten Dokuments besitzen (Listen,Fore, etc.), schicken wir eine Anfrage mit dem Key und unserem ReplyBlock an einen Servenet Server. Der Servenet-Server schickt die Anfrage an alle bekannten Nodes etwa in folgender Art: ('request', PK_file, PK_client, ReplyBlock) Jeder Server der die Anfrage bekommt schickt die shares, so vorhanden, per ReplyBlock raus. Sind dann genügend shares eingetroffen kann das Dokument wieder zusammengefügt werden.		Nachdem wir den Public Key des gewünschten Dokuments besitzen (Listen,Fore, etc.), schicken wir eine Anfrage mit dem Key und unserem ReplyBlock an einen Servenet Server. Der Servenet-Server schickt die Anfrage an alle bekannten Nodes etwa in folgender Art: ('request', PK_file, PK_client, ReplyBlock) Jeder Server der die Anfrage bekommt schickt die shares, so vorhanden, per ReplyBlock raus. Sind dann genügend shares eingetroffen kann das Dokument wieder zusammengefügt werden.


	===Robustheit / Verantwortung===
	*Maßnahmen zur Identifizierung von bösartigen Servern

	===Handel von „shares“===		===Handel von „shares“===

Jaekel: /* Handel von „shares“ */

2007-07-17T14:45:30Z

Handel von „shares“

← Older revision		Revision as of 14:45, 17 July 2007
Line 57:		Line 57:

	===Handel von „shares“===		===Handel von „shares“===
			Shares werden aufgrund der Währung "Größe*Lebensdauer" gehandelt. durch den Handel sind erstens Anonymität, Dynamik und Sicherheit gewährleistet. Ausserdem ist dadurch einfach eine längere Lebensdauer der shares möglich. Will Server A nun also handlen passiert folgendes:
	*Ablauf
			*Sucht er sich einen Server B aus seiner Liste bekannter Server raus (basierend auf „Trust“ und bisherigen Handelsaktionen)
	*Ablauf
			*Bietet B einen share Фi an, sowie Informationen was A gerne für shares haben möchte
			*Ist B einverstanden bietet es einen share λk zurück
			*Die Verhandlung ist mit einer Zustimmung beider Seiten beendet (inklusive einer Quittung)
			*Anschliessend werden die shares ausgetauscht
			Das ganze wird wie gesagt quitiert. Dabei ist dies jedoch nicht direkt als Beweis für Transaktionen zu sehen, vielmehr als Indiz für die Verpflichtung einen gewissen share zur Verfügung zu halten, damit das „Trust“-System bei Fehlverhalten darauf reagieren kann.

	==Schlussbetrachtungen==		==Schlussbetrachtungen==

Jaekel: /* Quittungen für Aktionen */

2007-07-17T14:40:24Z

Quittungen für Aktionen

← Older revision		Revision as of 14:40, 17 July 2007
Line 58:		Line 58:
	===Handel von „shares“===		===Handel von „shares“===
	*Ablauf		*Ablauf
	===Quittungen für Aktionen===
	*Ablauf		*Ablauf

Jaekel: /* Schlussbetrachtungen */

2007-07-17T14:37:54Z

Schlussbetrachtungen

← Older revision		Revision as of 14:37, 17 July 2007
Line 66:		Line 66:
	#Das Reputationssystem ist kompliziert, schlecht anwendungsfähig und müsste durch ein besseres und robusteres ersetzt werden		#Das Reputationssystem ist kompliziert, schlecht anwendungsfähig und müsste durch ein besseres und robusteres ersetzt werden
	#Datenrückgewinnung läuft momentan durch Broadcasts was so nicht tragbar ist. Gehashte Adressen wäre zB eine Möglichkeit		#Datenrückgewinnung läuft momentan durch Broadcasts was so nicht tragbar ist. Gehashte Adressen wäre zB eine Möglichkeit
	#Es gibt keine anonymen Kommunikationsstrukturen. Auf diesem Gebiet wird immer ~~ncoh~~ geforscht.		#Es gibt keine anonymen Kommunikationsstrukturen. Auf diesem Gebiet wird immer noch geforscht.

	==Referenz==		==Referenz==

Jaekel: /* Schlussbetrachtungen */

2007-07-17T14:37:31Z

Schlussbetrachtungen

← Older revision		Revision as of 14:37, 17 July 2007
Line 62:		Line 62:

	==Schlussbetrachtungen==		==Schlussbetrachtungen==
			Die Weiterentwicklung wurde wie schon erwähnt aufgrund einger grosser Probleme auf Eis gelegt.

			#Das Reputationssystem ist kompliziert, schlecht anwendungsfähig und müsste durch ein besseres und robusteres ersetzt werden
			#Datenrückgewinnung läuft momentan durch Broadcasts was so nicht tragbar ist. Gehashte Adressen wäre zB eine Möglichkeit
			#Es gibt keine anonymen Kommunikationsstrukturen. Auf diesem Gebiet wird immer ncoh geforscht.

	==Referenz==		==Referenz==
	*[http://www.freehaven.net Free Haven's site]		*[http://www.freehaven.net Free Haven's site]

Jaekel: /* Robustheit / Verantwortung */

2007-07-17T14:31:17Z

Robustheit / Verantwortung

← Older revision		Revision as of 14:31, 17 July 2007
Line 55:		Line 55:
	===Robustheit / Verantwortung===		===Robustheit / Verantwortung===
	*Maßnahmen zur Identifizierung von bösartigen Servern		*Maßnahmen zur Identifizierung von bösartigen Servern


	===Handel von „shares“===		===Handel von „shares“===

Jaekel: /* Bestandteile einzelner “shares” */

2007-07-17T14:30:50Z

Bestandteile einzelner “shares”

← Older revision		Revision as of 14:30, 17 July 2007
Line 55:		Line 55:
	===Robustheit / Verantwortung===		===Robustheit / Verantwortung===
	*Maßnahmen zur Identifizierung von bösartigen Servern		*Maßnahmen zur Identifizierung von bösartigen Servern

	===Bestandteile einzelner “shares”===

	*Zerstreungsalgorithmus
	*Aufbau
	===Handel von „shares“===		===Handel von „shares“===
	*Ablauf		*Ablauf

Jaekel: /* Referenz */

2007-07-17T14:30:26Z

Referenz

← Older revision		Revision as of 14:30, 17 July 2007
Line 67:		Line 67:
	*[http://www.freehaven.net Free Haven's site]		*[http://www.freehaven.net Free Haven's site]
	*[http://tor.eff.org Tor]		*[http://tor.eff.org Tor]
			;Roger Dingledine.
			:The Free Haven Project: Design and Deployment of an Anonymous Secure Data Haven.
			:MIT Master's Thesis, June 2000.
			;Michael O. Rabin
			:Efficent dispersal of information for security, load balancing and fault tolerance,
			:April 1989

Jaekel: /* Operationen */

2007-07-17T14:27:08Z

Operationen

← Older revision		Revision as of 14:27, 17 July 2007
Line 48:		Line 48:
	Die zwei wichtigsten operationen im netzwerk sollen kurz vorgestellt werden.		Die zwei wichtigsten operationen im netzwerk sollen kurz vorgestellt werden.
	* Hinzufügen von Dokumenten		* Hinzufügen von Dokumenten
	Zuallererst brauchen wir einen Node der die Datei speichern will. Das sind entweder wir selber oder wir finden einen Node über gespeicherte ReplyBlocks aus Listen im Internet. Dann verschicken wir das Dokument zB. über einen anonymen Remailer. Der Server teilt dieses dann in einzelne shares auf und fängt an sie mit anderen Servern zu handeln. (~~Dsa~~ ~~gnaze~~ natürlich noch über private/public Keys - genaueres dazu im Paper)		Zuallererst brauchen wir einen Node der die Datei speichern will. Das sind entweder wir selber oder wir finden einen Node über gespeicherte ReplyBlocks aus Listen im Internet. Dann verschicken wir das Dokument zB. über einen anonymen Remailer. Der Server teilt dieses dann in einzelne shares auf und fängt an sie mit anderen Servern zu handeln. (Das ganze natürlich noch über private/public Keys - genaueres dazu im Paper)

	* Abrufen von Dokumenten		* Abrufen von Dokumenten
			Nachdem wir den Public Key des gewünschten Dokuments besitzen (Listen,Fore, etc.), schicken wir eine Anfrage mit dem Key und unserem ReplyBlock an einen Servenet Server. Der Servenet-Server schickt die Anfrage an alle bekannten Nodes etwa in folgender Art: ('request', PK_file, PK_client, ReplyBlock) Jeder Server der die Anfrage bekommt schickt die shares, so vorhanden, per ReplyBlock raus. Sind dann genügend shares eingetroffen kann das Dokument wieder zusammengefügt werden.

	===Robustheit / Verantwortung===		===Robustheit / Verantwortung===